Will the new Generics mechanism still use runtime casting?

[Neal Gafter]

Neal> Yes, it will.

This is not good. You will need to do this so often that the notion of
"compile without warning and you'll be safe" is lessened. It will be
hard to compile without warning.

True. The warning is optional, and off by default, like deprecation. If you're
using generics, you'll want to enable it. If you're not, you'll want it off.

-Neal

 

[Neal Gafter]

I've seen stuff that's a few years old now, but nothing that is both recent and
complete enough for me to understand the new stuff fully*. E.g. this is the
first *I*'ve heard of the wildcard notation...

By "fully" I mean that I'd like to be able to:
- write Java code that uses the new stuff and understand
what it means (well, obviously!).
- understand the mechanisms well enough to see 'gotchas'
myself rather than be told about them by "experts".
- understand fully how the resulting code is presented
to the JVM -- I work mostly at bytecode/JNI level
so Java itself is rather less than half the story.

This is not fully written up in a public way yet. We're working on it. But we
want it out there as much as possible so people aren't taken by surprise. If
you're interested in gory details, what we're doing is close to what is
described in "Variant Parametric Types: A Flexible Subtyping Scheme for
Generics" By Atsushi Igarashi and Mirko Viroli. See
<http://www.sato.kuis.kyoto-u.ac.jp/~igarashi/papers/variance.html>. The syntax
has changed, obviously. You'll see more published about it as time goes on.
If you want to try it out and see example code written using this, download the
prototype from
<http://developer.java.sun.com/developer/earlyAccess/adding_generics/>. It will
be updated in a couple of weeks.

Like the rest of generics, this is all erased at the bytecode level. Try the
prototype and see.

Regards,
-Neal

 

[Chris Uppal]

I've seen stuff that's a few years old now, but nothing that is both
recent and complete enough for me to understand the new stuff fully*.
E.g. this is the first *I*'ve heard of the wildcard notation...
[...]

This is not fully written up in a public way yet.

Ah, OK.

We're working on it.
But we want it out there as much as possible so people aren't taken by
surprise.

Personally I'd rather have something I can read on the train than code I can
play with. Still, it would have been a mistake to try to document this before
you had an implementation, and if you've got the implementation (in progress)
then why not share it ?

If you're interested in gory details, what we're doing is
close to what is described in "Variant Parametric Types: A Flexible
Subtyping Scheme for Generics" By Atsushi Igarashi and Mirko Viroli. See
http://www.sato.kuis.kyoto-u.ac.jp/~igarashi/papers/variance.html.

Thanks for that. I don't remember seeing their work before.

If you want to try it out and see example code written using this,
download the prototype from
<http://developer.java.sun.com/developer/earlyAccess/adding_generics/>.
It will be updated in a couple of weeks.

Right. I've tried the download before but the login system wouldn't let me in
for a few months. It seems to be fixed now.

Like the rest of generics, this is all erased at the bytecode level. Try
the prototype and see.

I'm vaguely hopeful that I can ignore the existence of generics altogether in
my bytecode/JNI-level stuff. It depends on whether the compiler is doing any
name mangling. Nested classes and what-have-you have been something of a
PITA...

-- chris

 

[Neal Gafter]

I'm vaguely hopeful that I can ignore the existence of generics altogether in
my bytecode/JNI-level stuff. It depends on whether the compiler is doing any
name mangling. Nested classes and what-have-you have been something of a
PITA...

Nothing like that. You will almost certainly be able to ignore this at the byte
code level. On the other hand, if you're modifying the byte code, the stackmap
attributes required as part of JSR202 might give you a headache.

-Neal

 

[xarax]

xarax> A properly implemented JVM can perform a cast or instanceof
xarax> test in constant time, regardless of the complexity of the
xarax> inheritance graph.


Actually I don't think that it can, unless it pre-calculates a
transitive closure. Which it can't do in constant time.

/snip/

The transitive closure is pre-computed at class load time. From
then on, casting and instanceof are constant-time, for both
interfaces and class parents, and for multiple-inheritance.

 

[Neal Gafter]

The transitive closure is pre-computed at class load time. From
then on, casting and instanceof are constant-time, for both
interfaces and class parents, and for multiple-inheritance.

Depends on your VM. For GCJ, yes (see
<http://gcc.gnu.org/ml/java-patches/1999-q4/msg00080.html>). For Sun's VMs, not
yet, as far as I know.

 

[Chris Uppal]

Nothing like that. You will almost certainly be able to ignore this at
the byte code level. On the other hand, if you're modifying the byte
code, the stackmap attributes required as part of JSR202 might give you a
headache.

Ta for that. But "required" ? Seems harsh, "optional unless new features are
required" is what I'd have expected, or compatability goes out of the window.

Presumably I don't have to generate the stack map unless I want my classfiles
to "look like" Generic-aware code to the compiler (or to runtime reflection).
Since I have (for these purposes) no intererst in Generics, I imagine that I
can just ignore the new classfile attributes ?

-- chris

 

[Roedy Green]

Ta for that. But "required" ? Seems harsh, "optional unless new features are
required" is what I'd have expected, or compatability goes out of the window.

Does a collection style class need a different declaration to use
generics or can you retrofit it onto any old collection type class
even without changing the source for the class?

 

[Dobromir Gaydarov]

I have actually tried and the program below works just fine.
Apart from the warning for

list.add( new Object() );

as promissed by the spec the program compiles well and executes normally to
the end.

The get a failure you have to try assignment like

Frame f = frameList.get( 1 );

and then you get ClassCastException at runtime.

Regards,
Dobromir

 

[Neal Gafter]

Does a collection style class need a different declaration to use
generics or can you retrofit it onto any old collection type class
even without changing the source for the class?

There are unsupported ways of retrofitting generics outside the source of the
class, but the proper way to do it is to modify the source of the class.

 

[Neal Gafter]

Neal Gafter wrote:




Ta for that. But "required" ? Seems harsh, "optional unless new features are
required" is what I'd have expected, or compatability goes out of the window.

Presumably I don't have to generate the stack map unless I want my classfiles
to "look like" Generic-aware code to the compiler (or to runtime reflection).
Since I have (for these purposes) no intererst in Generics, I imagine that I
can just ignore the new classfile attributes ?

You can translate 1.5-style classfiles into 1.4-style classfiles by discarding
the stackmaps and changing the version number. Almost. Class literals generate
a single bytecode instruction (ldc) in 1.5, and that must be translated into the
mass of code that was used in previous releases.

-Neal

 

[Chris Uppal]

You can translate 1.5-style classfiles into 1.4-style classfiles by
discarding the stackmaps and changing the version number. Almost. Class
literals generate a single bytecode instruction (ldc) in 1.5, and that
must be translated into the mass of code that was used in previous
releases.

Ah? As far as I can see the ea2.2 compiler doesn't do that -- it seems to
compile .class into the traditional "mass", presumably this is the one change
that *requires* a new version of the JVM. What kind of constant does the class
literal resolve to, a "Class_info" entry ?

-- chris

 

[Chris Uppal]

Ah? As far as I can see the ea2.2 compiler doesn't do that

Answering myself: tell the new compiler to "-target 1.5" and then it does...

(That's also necessary to get the stack map stuff which explains why I wasn't
seeing that either ;-)

-- chris

 

[Roedy Green]

Answering myself: tell the new compiler to "-target 1.5" and then it does...

in a similar way, you need to write -target 1.4 in Java 1.4.2 to make
assertions work. Otherwise they are treated as syntax errors.

 

[Chris Uppal]

in a similar way, you need to write -target 1.4 in Java 1.4.2 to make
assertions work. Otherwise they are treated as syntax errors.

True. I don't normally use the -target parameter at all (assertions ? who
needs assertions ?) because I tend to have a number of JVMs of different
vintages around, so it's much easier just to accept the
lowest-common-denominator default of javac. (And I don't let Eclipse compile
code for execution outside Eclipse -- if I use it at all.)

Actually it turns out that I was misreading my own dissassembler output,
the -target 1.5 doesn't seem to force the ea1.2 compiler to emit ldc <typename>
after all. It does make it emit stack maps, though. (And a right pain they
will be to decode -- if I decide to bother. Not *difficult*, just lots of
code, lots of small objects, for very little benefit to me).

-- chris

 

[Neal Gafter]

in a similar way, you need to write -target 1.4 in Java 1.4.2 to make
assertions work. Otherwise they are treated as syntax errors.

actually, its -source 1.5 (or 1.4)

 

[Neal Gafter]

Ah? As far as I can see the ea2.2 compiler doesn't do that -- it seems to

compile .class into the traditional "mass", presumably this is the one change
that *requires* a new version of the JVM. What kind of constant does the class
literal resolve to, a "Class_info" entry ?

yes. It will indeed require a new VM; old VMs don't know how to handle this
sequence.

 

[Roedy Green]

actually, its -source 1.5 (or 1.4)

correct. it is javac -source 1.4 -target 1.4
and
java -ea

to enable assertions. the -target 1.4 is optional I believe.

Javac -target 1.3 is to generate old style class format files with a
Java 1.4 compiler which don't understand assertions.


see http://mindprod.com/jgloss/assertions.html