Getting my head around generics.

[HK]

Arrays already have fully type-safe types.
<typename>[ ] <ID> = new <typename>[ <arrayLen> ];

Not sure I follow. I want to implement a parameterized stack
with an array so that the client can write cast-free code [...]
This is possible with generics, but the implementation of
ArrayStack seems to require a cast somewhere.

The code of java.util.HashMap contains the equivalent of this:

public class Bla<T> {

Entry[] table; // raw type used as array element

public void do() {
// assignment from (raw) array element to fully typed variable
Entry<T> e = table[0];
}
// type entry class used to hold elements
static class Entry<Q> {
Q value;
}
}

This seems to indicate that even java.util.HashMap does not
compile without a warning. Is that true?

Harald.

 

[Roedy Green]

enums, annotations, signatures, varargs, and probably a couple more. The
following document will tell you:

http://java.sun.com/docs/books/vmspec/2nd-edition/ClassFileFormat-Java5.pdf

having a quick look over that document suggests you did not use a
feature the class file would be the same, except for the version
numbers and those changes to the JVM definitions you mentioned.Sun
just added some new legal values for existing fields.

In other words, an old byte class disassembler would have little
trouble with the new class file structure.

--
Bush crime family lost/embezzled $3 trillion from Pentagon.
Complicit Bush-friendly media keeps mum. Rumsfeld confesses on video.
http://www.infowars.com/articles/us/mckinney_grills_rumsfeld.htm

Canadian Mind Products, Roedy Green.
See http://mindprod.com/iraq.html photos of Bush's war crimes

 

[googmeister]

This seems to indicate that even java.util.HashMap does not

compile without a warning. Is that true?

Yes!

 

[Thomas G. Marshall]

Thomas Weidenfeller coughed up:

enums, annotations, signatures, varargs, and probably a couple more.
The following document will tell you:

http://java.sun.com/docs/books/vmspec/2nd-edition/ClassFileFormat-Java5.pdf


BTW, as I just learned, Sun did not only change the file format, they
also changed the instruction set of the VM. The ldc, putfield and
putstatic instructions were changed.

http://java.sun.com/docs/books/vmspec/2nd-edition/Java5-Instructions2.pdf

That makes it even more strange why Sun didn't dare to change the
instruction set to support generics, but instead just bolted them
somehow onto the language.

/Thomas

I have to wonder then if sun or someone else will someday adopt a compiler
and jvm that /does/ manage generics during runtime, foregoing erasure, and
saying words to the effect of "screw backward compatibility". Seems like it
would be tempting for many to try.

Speaking of cranky splinter groups , how does Nice manage Generics? Do
they already have a dynamic (?) version of it, and/or do they attempt
compatibility still with the 1.5 class files ?

 

[Thomas G. Marshall]

Chris Uppal coughed up:

That's probably misleading. It's much more nearly true to say that
the classfile format doesn't change -- in the sense that the format
is extensible, and nothing has been added to it over the years that
doesn't use that extensibility in ways that are completely
transparent to parsers that only know about the previous formats.

HOWEVER. Sun have made yet another of their ghastly botches in 1.5.
There's a completely unecessary extension to the semantics of a few
bytecodes

Is it possible that this is with some future alteration in mind?

 

[Roedy Green]

Yes!

Can you imagine the debates at Sun about how to do generics when
somebody pointed out that the syntax was so rinky dink it was
impossible to write HashMap or ArrayList in it?


--
Bush crime family lost/embezzled $3 trillion from Pentagon.
Complicit Bush-friendly media keeps mum. Rumsfeld confesses on video.
http://www.infowars.com/articles/us/mckinney_grills_rumsfeld.htm

Canadian Mind Products, Roedy Green.
See http://mindprod.com/iraq.html photos of Bush's war crimes

 

[Thomas G. Marshall]

Roedy Green coughed up:

Can you imagine the debates at Sun about how to do generics when
somebody pointed out that the syntax was so rinky dink it was
impossible to write HashMap or ArrayList in it?

I imagine it is something like usenet, but only louder.

When you start dealing with OO language design, you get a lot of very strong
emotions.

 

[Dale King]

You could try to get that thing to work:

http://retroweaver.sourceforge.net/

Sorry, I don't see your point. I've already explained how retroweaver is
not the solution to the problem.

 

[Thomas Weidenfeller]

Sorry, I don't see your point. I've already explained how retroweaver is
not the solution to the problem.

Sorry, I don't keep records about what you did say in the past.

/Thomas

 

[Thomas Weidenfeller]

I have to wonder then if sun or someone else will someday adopt a compiler
and jvm that /does/ manage generics during runtime, foregoing erasure, and
saying words to the effect of "screw backward compatibility". Seems like it
would be tempting for many to try.

I remember some old discussion about why it is harder than necessary to
build Java microprocessors. Something about that the bytecode hadn't
been chosen for easy decoding in hardware. So that would be another
reason to completely overhaul the bytecode. On the other hand, Sun had
ten year to do it, but didn't. And if they want to stick to the JCP,
they will probably not get it done at all.

/Thomas

 

[Tim Tyler]

Thomas G. Marshall wrote:

I remember some old discussion about why it is harder than necessary to
build Java microprocessors. Something about that the bytecode hadn't
been chosen for easy decoding in hardware. So that would be another
reason to completely overhaul the bytecode. On the other hand, Sun had
ten year to do it, but didn't. And if they want to stick to the JCP,
they will probably not get it done at all.

Direct execution of bytecode only makes sense in embedded systems.

Anywhere else you should use a Transmeta-style approach - and
transform the bytecode into a different sort of instruction
stream before executing it.

You can't really optimise for embedded hardware and execution on
high-performance hardware at the same time - since the space/speed
tradeoffs are so different.

Java bytecode looks like it's targetted at embedded systems. That
makes sense to me - since it's the high performance systems that are
the ones that can afford to transform and cache a JITted version of
the program.

 

[Tim Tyler]

If they were going to bother with this at all, they really should have
done it correctly, even if it broke things here and there and made
people temporarily miserable. It's better to be very miserable for a
short time than slightly miserable for /ever/.

It's not forever:

Java-the-language now has a distinctly limited shelf life.

It only has to keep going until something much better comes alone.

The chance of Java morphing into its replacement now seems to be
practically nil.

 

[Roedy Green]

Java-the-language now has a distinctly limited shelf life.

It only has to keep going until something much better comes alone.

The chance of Java morphing into its replacement now seems to be
practically nil.

Every little compromise shortens the life expectancy forcing an
eventual complete redesign.

I suspect though that it will be much easier to port Java to some new
language than it was to port C or C++ to Java.

The next phase of "language" evolution might be quite different. What
we call the language will be used only for import/export. The actual
thing people code in will be defined much more by the IDE. It will be
a matter of filling in dialog boxes, and graphical displays. Hardly
anyone will write raw code, just generate it.

--
Bush crime family lost/embezzled $3 trillion from Pentagon.
Complicit Bush-friendly media keeps mum. Rumsfeld confesses on video.
http://www.infowars.com/articles/us/mckinney_grills_rumsfeld.htm

Canadian Mind Products, Roedy Green.
See http://mindprod.com/iraq.html photos of Bush's war crimes

 

[Dale King]

Sorry, I don't keep records about what you did say in the past.

Sorry, I thought I said that in this thread. The issue is third party
libraries like Jakarta Commons for example. They cannot adopt generics
because they need to support 1.4 and earlier users. They would have to
maintain two source trees and two separate binar distributions. They are
not going to use Retroweaver because it requires a runtime library.

 

[Adam P. Jenkins]

I thought all along that we were going to have this ability to run
generics in 1.4 and thought the limitations in Java generics were a
valid limitation. But since we don't have that ability the limitations
make no sense. Why come up with a scheme to do a limited form of
generics without requiring JVM changes when you require a new JVM anyway
to run them? Why not go ahead and do a complete implementation of
generics with JVM changes to fully support it?

A bit late but.. While it's true that we can't run 1.5 bytecode under
pre-1.5 JVMs, type erasure does allow pre-1.5 bytecode to run under 1.5
JVMs. There would be no chance of 1.5 being accepted if we suddenly
couldn't use any pre-1.5 jars or class files which used containers.
That is, Sun's choice to use type erasure allows this to work:

public class CompiledWith1_4 {
public static void takesAList(java.util.List foo) { }
}

public class CompiledWith1_5 {
public static void main(String[] args) {
CompiledWith1_4.takesAList(
new java.util.ArrayList<Integer>() );
}
}

Adam

 

[Adam P. Jenkins]

Can you imagine the debates at Sun about how to do generics when
somebody pointed out that the syntax was so rinky dink it was
impossible to write HashMap or ArrayList in it?

But you can write them, you just get a compile time warning. I think
they just need to provide a way to shut the warning up once you the
programmer have verified that the warning doesn't apply in a specific case.

 

[Thomas Hawtin]

A bit late but.. While it's true that we can't run 1.5 bytecode under
pre-1.5 JVMs, type erasure does allow pre-1.5 bytecode to run under 1.5
JVMs. There would be no chance of 1.5 being accepted if we suddenly
couldn't use any pre-1.5 jars or class files which used containers. That
is, Sun's choice to use type erasure allows this to work:

The 1.5 erasure solution is not the only way to do it.

Suppose when a generic class is instantiated the generic arguments are
recorded. Old style code would just have nulls. The types can then be
checked on any cast. C could still be cast to C<String>, but if we cast
C<Integer> to C to C<String> that could be caught at runtime. We can now
allow non-generic classes to override generic methods, but not erase any
information from the object runtime types. C<T> can make an array of T
coping with either new or old code as T.class==null ? (T[])new Object[n]
: new T[n]. Although obviously this makes the runtime more complicated.

Tom Hawtin

 

[Thomas G. Marshall]

Thomas Hawtin coughed up:

A bit late but.. While it's true that we can't run 1.5 bytecode under
pre-1.5 JVMs, type erasure does allow pre-1.5 bytecode to run under
1.5 JVMs. There would be no chance of 1.5 being accepted if we
suddenly couldn't use any pre-1.5 jars or class files which used
containers. That is, Sun's choice to use type erasure allows this to
work:

The 1.5 erasure solution is not the only way to do it.

Suppose when a generic class is instantiated the generic arguments are
recorded. Old style code would just have nulls. The types can then be
checked on any cast. C could still be cast to C<String>, but if we
cast C<Integer> to C to C<String> that could be caught at runtime. We
can now allow non-generic classes to override generic methods, but
not erase any information from the object runtime types. C<T> can
make an array of T coping with either new or old code as
T.class==null ? (T[])new Object[n] new T[n]. Although obviously this makes
the runtime more complicated.

It's not at all clear to me that even this level of worry was needed.

If I have 1.4 bytecodes and am attempting to run it on a 1.5 JVM, the 1.5JVM
could certainly be made to know about it. Once the 1.5 JVM knows that it is
dealing with 1.4 bytecodes, it could execute them accordingly.

There must be something that I just don't understand about this---it seems
far too straightforward a problem for sun to solve.

 

[Mark Thornton]

Thomas Hawtin coughed up:

A bit late but.. While it's true that we can't run 1.5 bytecode under
pre-1.5 JVMs, type erasure does allow pre-1.5 bytecode to run under
1.5 JVMs. There would be no chance of 1.5 being accepted if we
suddenly couldn't use any pre-1.5 jars or class files which used
containers. That is, Sun's choice to use type erasure allows this to
work:

The 1.5 erasure solution is not the only way to do it.

Suppose when a generic class is instantiated the generic arguments are
recorded. Old style code would just have nulls. The types can then be
checked on any cast. C could still be cast to C<String>, but if we
cast C<Integer> to C to C<String> that could be caught at runtime. We
can now allow non-generic classes to override generic methods, but
not erase any information from the object runtime types. C<T> can
make an array of T coping with either new or old code as
T.class==null ? (T[])new Object[n] new T[n]. Although obviously this makes
the runtime more complicated.

It's not at all clear to me that even this level of worry was needed.

If I have 1.4 bytecodes and am attempting to run it on a 1.5 JVM, the 1.5JVM
could certainly be made to know about it. Once the 1.5 JVM knows that it is
dealing with 1.4 bytecodes, it could execute them accordingly.

There must be something that I just don't understand about this---it seems
far too straightforward a problem for sun to solve.

Consider a 3rd party library compiled for 1.4, which needs to create an
object of the same type as a value passed to it. It will create a new
object that in general has different type arguments (just the default
Object) to that of the object supplied. The 1.5 client of this code
would then observe a difference if it 'saw' this new object --- it would
be different from that a proper generic enabled 1.5 library would produce.
Then what about comparing classes. If the type arguments are retained,
then they should be part of the comparison. Err, except when the code is
'non generic' (compiled for 1.4). Oh dear this is getting messy.

Mark Thornton