Dear Neal and other Sun engineers,

We heard over and over again that people want to use new generics syntax NOW but can't because they are not in control of JDK versions their clients use.
I wish javac supported 1.4 bytecode with limited set of 1.5 of syntax so it is able to run on 1.4 JVM out of the box and prefereble without changing boot class path (if any additional classess are needed they should be in normal class path only) And so our code could be deployed to any app server running jdk 1.4

It would make adoption of new features so much easer. I would be much happier with a limited subset of 1.5 features NOW than no 1.5 features at all for another 1.5 years (when customers will finaly start adopting 1.5)

 

 

Hi Alexander-Roytman,

I'm not aware of any plans by Sun to support a 1.4 target for the 1.5 compiler, but you can compile your source code using 1.5, and then use Retroweaver to transform them to 1.4 class files.

http://retroweaver.sf.net

God bless,
-Toby Reyelts

 

 

Hi Toby,

I know - great tool. My only problem is that my customers may not approve its use and I can't use it without letting them know. In any case this kind of tool will have to have great responcibility not to introduce any problems into enhanced code as they will be very hard to trace.
BTW can enhanced code be debugged? Under which JVM?

I wish tool like this came from Sum with teir official blessings (beter yet be part of the compiler) I do not understand why Sun can't do it. They went to great lenght to ensure backward compatibility why can't they do a bit more for easy adoption?

 

 

I'm not sure why this is a problem. We use several bytecode enhancing tools here. Would your customers have problems with you using JDO?


Retroweaver is unlikely to have any difficult to trace problems.


Sure - under the same VM you are targetting.


Some things can't be dealt with totally transparently. For example, serialization changed to support enums, new APIs were added for reflection on generic types, new APIs were added for annotations. Perhaps Sun was concerned that these issues would confuse developers more than helping them. That's all just pure speculation.

Anyways, maybe if you scream loud enough, Sun will change their minds. Until then, I've already got a working solution.

God bless,
-Toby Reyelts

 

 

Toby,

We use JDO extensively but that's a very tageted enhancement with narrow scope while Retroweaver will touch virtually every class - abit scary. I guess I will try it anyway - can't resist using all this new jdk features

thanks

Alex

 

 

Unfortunately -source 1.5 does use minor enhancements to the libraries and class files. for-each loops use java.lang.Iterable. generics uses Signature attributes, Bridge attributes, and new flags on the class files. Boxing/unboxing uses new static factories on the wrapper classes. In order to support these on -source 1.4 we would need a separate but incompatible specification for how these features are supposed to work on 1.4. Moreover, this mode of the compiler would violate the JCK run rules, which state that each available mode of a Java compiler must comply with some platform specification.

 

 

Neal,

Is it possible to limit what compiler compiles to 1.4 so it can do it cleanly? Just Generics?
I would be willing not to use the rest for the features for a while. Just whatewer subset of 1.5 which can be cleanly compiled to 1.4 People already start looking for work around (retroweaver is an example) it is indicateive to the needs of the comunity

BTW -source 1.4 -target 1.4 compiles covariant return types for interface implementations just fine althought it is not part of 1.4 language specs (do not remove it please even if it is a bug :-)

 

 

Cool. Make sure to get the 1.0RC2 release, which fixes a bug in relation to StringBuilder.

God bless,
-Toby Reyelts

 

 

We cannot legally do this unless there is a platform specification that describes this version of the language. JLS2 doesn't allow generics, and JLS3 will have ALL the new language features. What would be the TCK compatibility requirements for this hybrid language?


I'm very happy to see retroweaver available!


I'm afraid I will likely be required to remove it. I've been in a number of meetings this past week about this issue. A final decision is likely to be made tomorrow.

 

 

neal,
i agree with you, but the idea is to promote features like
generics, auto-boxing ... by providing a way compile
with j2sdk 1.4 rutime.

I think the wrong way is to use the flag -version with the value
1.5, because what we want is an hybrid language.
the compiler could recognize instead the value "1.4hybrid"
that enable some features of the java 1.5 that works
with j2sdk1.4 runtime.

If i examine the java 1.5 feature list :
- for-each loops could use java.lang.Iterable,
=> use Iterator instead.

- StringBuilder
=> replace by StringBuffer

- generics uses Signature attributes,
=> only at compile time, so provide a jar
with all generics signature for compilation
in the same way that you provide it for the
"adding_generics" compiler prototype.

- bridge attributes,
=> currently works with -version 1.4

- varargs or new flags on the class files
=> Oups, this issue embarassing me,
i propose that all new flag could have their byte-code
attributes counterpart.

- auto-boxing/unboxing
use new Integer() instead of Integer.valueOf()

- enum & annotation
=> too closely linked with new java.lang classes,
no support provided.
...
yes, me too.

R?mi Forax

 

 

The problem is not and engineering problem of how to implement it - as you can see from the jsr14 prototype, we've worked out the technical issues - nor of why we should do so. We even know how to make enums work (thanks, Lubo!). The problem is a legal one in that it violates the Java platform specifications. That is not something we would allow our licensees to do, and we should not therefore do it ourselves. If we allow the hybrid language then we will need a language specification, a conformance suite, and licensing terms for the hybrid language.

 

 

CodeGuide 7 is shipping with a target 1.4 option (for source 1.5)

http://www.omnicore.com/newlanguage.htm

 

 

Yes, CodeGuide does support the jsr14 prototype. That's not

    -target 1.4

but instead, that is the undocumented

    -target jsr14

which I'd rather not talk about.

 

 

Okay, I know you just said that you'd rather not talk about it, but a lot of people are wandering around saying that CodeGuide supports 1.4. CodeGuide's own site states that they target 1.4, but they don't give any details about it whatsoever - i.e. what level of support exists, and how certain constructs are handled.

It would be nice to know have this cleared up. Anybody from CodeGuide care to respond, too?

God bless,
-Toby Reyelts

 

 

Read the CodeGude docs. They just allow you to use the jsr14 prototype. That's all.