Adam said:
I'm not sure why you say that. Retroweaver solves the problem in
question for me; allows me to write code using 1.5 features, and emit
compiled code that runs under earlier JVMs. Of course it would be nicer
if Sun provided the option in their JDK, but adding a "retroweave" step
to your build really is equivalent to saying -source 1.5 -target 1.4,
except that you also need to distribute the retroweaver runtime jar with
your program. However I think the runtime jar would be unavoidable even
if Sun had a -target 1.4 option, because you have to provide some
equivalent of java.lang.Enum when running under older VMs.
The reason I say that and the reason that I think this is a big issues
is for those developers that develop libraries for use by others. Take
for example something like Jakarta Commons Collections. Let's say they
like generics and want to make their library support generics so that
those using 1.5 have generic versions of their classes. But they still
want to support users of 1.3 and 1.4.
Retroweaver is not really a solution because it would require users of
the library to also use the retroweaver library. That is too much of a
burden on users of the library.
They would basically be forced to maintain two different versions of the
source, one that is generic and one that is not. They would also have
two seperate library distributions leading to some confusion.
But why do we have to put up with this hassle? After all generics is a
compile time only thing.
Enums do not figure in because I am only talking about generics. What
they should have is something like -source 1.4-generics which would
imply -target 1.4. It would accept code with generics, but not Enums and
foreach which require runtime libary support (You could include static
import if you wanted). It would generate class files that would run and
could be used for compiling in a 1.4 system. The classes would also have
the attributes for accessing the generic features in a 1.5 compiler.
If this were the case then something like Jakarta Commons could be
generified without requiring maintaining two separate source and binary
distributions.
This is the model that was used long ago when inner classes were
introduced. Why not do the same thing for a major feature like generics.
Without it people like Jakarta Commons will delay moving to generics for
years slowing the overall adoption rate of generics. With it you would
see widespread adoption of generics since you don't lose that compatibility.
