Static inner classes

[Chris Uppal]

No doubt, then, you appreciate that working at the bytecode level is as
different from working at the Java code level as working in assembly
language is from working in C. In the Java case there is a bit more
confusion (or at least potential for it) because the language was
designed to be run in a VM, and the VM specifications were designed to
support [version 1.0 of] the language.

Yes. I'd add that JVM bytecodes don't really bear the same relationship to
Java source, as (say) i86 assembler/binary does to C. The C/assembler thing is
a "high" (well, -ish) level language compiled down to a lower level language
with a simpler semantics. Whereas I'd say that (representation aside) Java and
JVM bytecodes are pretty much peer languages -- they are *both* high-level,
mostly-statically typed, GC-ed languages with OO semantics. That's part of why
I think that it would be a mistake to dismiss (as occasionally happens in this
NG) the JVM/bytecodes are a pesky implementation detail.

Nevertheless, Java bytecode is a
completely different language from "normal" Java.

It'd be interesting to put together a simple language that had all and only the
features of the JVM packaged up in a Java-like syntax. Come to that, it might
even be quite a nice language to program in -- Java proper is getting a bit
bloated IMO.

I think that is a dangerous statement. Or perhaps the dangerous part is
that there is no good language for distinguishing whether "Java" means
Java-the-language or Java-the-platform.

A good point, the lack of a good terminology (or jargon ;-) is a hindrance
here. I *try* to talk about "the JVM" or "Java", but unless the
listener/reader is already sensitised to the issue, then they tend to miss the
distinction, or at least to miss its significance.

I think a good Java-the-language programmer must have a sound
understanding of the principles of the VM and a working knowledge of
what a compiler will do with his code, but I wouldn't quite agree that
it is necessary that he be fluent in bytecode programming.

Oh, sure. I'd not expect anyone (except the few haunted souls who really need
it) to know the bytecode set -- that'd be going *way* too far.

But, just as an example, I think that too many programmers forget that the JVM
is a *dynamic* system, and that -- however many static guarantees the Java
compiler may offer -- the only guarantees you have at runtime are those made by
the JVM/verifier. (Alternatively, if one is thinking in Java-the-language
terms, the "binary compatibility" section of the Java spec)

On the other
hand, if you consider all the technologies and API that are part of
Java-the-platform (at least as Sun defines it) then I think I would be
hard pressed to find anyone proficient in all of them.

I hadn't really meant the expression in Sun's sense --
Java-the-marketing-exercise ;-)


-- chris

 

[John C. Bollinger]

Well, your terminology is half-right. When inner classes were first
introduced they used some confusing and contradictory terminology. They used
to use terms like static inner classes and nested top-level classes. When
the newer version of the JLS was introduced (about the 1.2 time frame) they
cleaned this up.

My terminology is based on the inner classes specification, which
admittedly is a bit dated. Specifically: "Classes which are static
class members and classes which are package members are both called
top-level classes. They differ from inner classes in that [...]". I
think the specification is quite clear on the definitions of the
terminology, although it is possible that the terms are not used
consistently. (I don't remember noting inconsistencies in the spec
itself, however.)

You are correct that it is no longer correct to call them static inner
classes. Nested classes come in two flavors, static or inner. Not both.

We are in agreement there, although I would in fact strengthen the
statement to say that it was _never_ correct to call any class a "static
inner class".

But it is also incorrect to refer to nested classes as "top-level". That is
a contradiction in terms.

Quoting the 2nd paragraph of chapter 8 of the JLS:

"A nested class is any class whose declaration occurs within the body of
another class or interface. A top level class is a class that is not a
nested class."

Yes, I see you're right. I think the change is unfortunate, however.
Look, for instance, at all the places in the JLS that refer to a "nested
class that is not an inner class" or similar. Static nested classes and
package member classes have sufficient logical and behavioral
similarities that there really ought to be a collective term for them.
The old distinction (between "top-level" and "inner") seems more useful
to me than the new one (between "top-level" and "nested"), which
probably explains why the new one didn't stick with me.


John Bollinger
(e-mail address removed)