Java Forum / General / November 2007
Compiling 5.0 syntax java files
Philipp - 08 Nov 2007 19:42 GMT Hello,
It's not clear for me what the relation between Java syntax version and bytecode version is.
I would like to write code using the new syntax features (generics, foreach etc) but when compiled it should run on an old JRE 1.3.
Is this possible? Is the bytecode compatible?
Thanks and best regards. Phil
Daniel Pitts - 08 Nov 2007 20:03 GMT > Hello, > [quoted text clipped - 8 lines] > Thanks and best regards. > Phil The bytecode is not compatible between even 1.5 and 1.4. I don't know the reasons, but I'm sure there are some good ones. Might have to do with assertions, generics, enums, and annotations. Might not though.
 Signature Daniel Pitts' Tech Blog: <http://virtualinfinity.net/wordpress/>
Joshua Cranmer - 08 Nov 2007 21:49 GMT >> Hello, >> [quoted text clipped - 11 lines] > the reasons, but I'm sure there are some good ones. Might have to do > with assertions, generics, enums, and annotations. Might not though. Surprisingly enough, the two incompatibilities that cannot be waved away have nothing to do with any of the new Java 5 features:
1. A new bytecode instruction was introduced (although almost definitely unused in any actual Java code).
2. The handling of 'Foo.class' was changed internally using a newly introduced version.
Asides from those two cases, merely modifying the class version number in the bytecode would probably be sufficient. If you're not trying to run on original Java ;-).
Standard javac does provide a `-target 1.3' argument, but my experience with that is non-existent.
 Signature Beware of bugs in the above code; I have only proved it correct, not tried it. -- Donald E. Knuth
junipe@gmail.com - 08 Nov 2007 20:06 GMT > Hello, > [quoted text clipped - 8 lines] > Thanks and best regards. > Phil Hi,
No, bytecode is not compatible with old versions jvm. But you can write your code with j1.5 and then these classes recompile to old bytecode with Retroweaver utility. http://retroweaver.sourceforge.net/
Best, Jakub
Roedy Green - 09 Nov 2007 00:04 GMT >It's not clear for me what the relation between Java syntax version and >bytecode version is. see http://mindprod.com/jgloss/javac.html
read up on -source and -target
 Signature Roedy Green Canadian Mind Products The Java Glossary http://mindprod.com
Lew - 09 Nov 2007 03:23 GMT >> It's not clear for me what the relation between Java syntax version and >> bytecode version is. > see http://mindprod.com/jgloss/javac.html > > read up on -source and -target and -bootclasspath.
You can cross-compile from a newer Java to an older; it will emit the older classfile format. The -bootclasspath is to prevent calling API methods that didn't used to exist.
<http://java.sun.com/javase/6/docs/technotes/tools/solaris/javac.html#crosscomp-e xample>
 Signature Lew
Philipp - 11 Nov 2007 20:09 GMT >> It's not clear for me what the relation between Java syntax version and >> bytecode version is. > see http://mindprod.com/jgloss/javac.html > > read up on -source and -target Hello and thanks for your answer.
In my eclipse project's "Properties" page on the "Java Compiler" node, if I choose ".class file compatibility 1.3" and "source compatibility 6.0" I get an error "Classfile compatibility must be greater or equal than source compatibility".
If I understood correctly your linked page, there shouldn't be any error... Where am I wrong?
Phil (by the way the correct link is http://mindprod.com/jgloss/javacexe.html)
Lew - 12 Nov 2007 00:23 GMT > In my eclipse project's "Properties" page on the "Java Compiler" node, > if I choose ".class file compatibility 1.3" and "source compatibility [quoted text clipped - 3 lines] > If I understood correctly your linked page, there shouldn't be any > error... Where am I wrong? The class file version must be at least the source version. That's because later language versions, e.g., Java 5, introduced keywords like 'enum', and changed some things about how class files load and so forth. Earlier language versions like 1.3 will not be able to deal with these new class file features.
If the source code is earlier, e.g., a version 1.3 source, then all you have watch out for is newly-illegal use of keywords like 'assert' or 'enum'. Newer Java versions can deal with the older class-file versions just fine. So Java 1.3 source is all right with Java 6 class files, but not the other way around.
You really should work with Java 5. The use of 'assert', 'enum', generics and the new for-loop syntax is worth it. You also get some lovely API upgrades like the java.util.concurrent package, and the superior semantics of the memory model and other things really help also.
 Signature Lew
Philipp - 12 Nov 2007 08:10 GMT >> In my eclipse project's "Properties" page on the "Java Compiler" node, >> if I choose ".class file compatibility 1.3" and "source compatibility [quoted text clipped - 6 lines] > just fine. So Java 1.3 source is all right with Java 6 class files, but > not the other way around. OK. Thanks.
> You really should work with Java 5. I know! :-) But I'm tied to an antiquated 1.3 JVM. That's why I was asking in the first place. I would like to develop using generics and new for-loop etc, but still run on the 1.3 JVM...
Best regards Phil
Lew - 12 Nov 2007 14:42 GMT > I know! :-) But I'm tied to an antiquated 1.3 JVM. Not only antiquated, but obsolete. Sun officially retired that version almost a year ago. Java 1.4 is already seven years old and will be retired in less than a year.
 Signature Lew
Philipp - 12 Nov 2007 16:19 GMT >> I know! :-) But I'm tied to an antiquated 1.3 JVM. > > Not only antiquated, but obsolete. Sun officially retired that version > almost a year ago. Java 1.4 is already seven years old and will be > retired in less than a year. My code is running on some embedded system and the developers of the JVM (not sun!) are... how should I put it... a bit late on the schedule.
Lew - 12 Nov 2007 16:43 GMT > My code is running on some embedded system and the developers of the JVM > (not sun!) are... how should I put it... a bit late on the schedule. JavaME is a whole different ball game. You hadn't mentioned that was the environment before.
 Signature Lew
Philipp - 12 Nov 2007 17:02 GMT > JavaME is a whole different ball game. You hadn't mentioned that was > the environment before. It's not JavaME. It's just a standard 1.3 JVM running on an embedded PC (maybe I'm misusing the term "embedded", it's a CPU (no screen, no keyboard etc.) in a box running the JVM).
Lew - 12 Nov 2007 17:17 GMT >> JavaME is a whole different ball game. You hadn't mentioned that was >> the environment before. > > It's not JavaME. It's just a standard 1.3 JVM running on an embedded PC > (maybe I'm misusing the term "embedded", it's a CPU (no screen, no > keyboard etc.) in a box running the JVM). Typically in software the term "embedded" means in a smaller, special-purpose processor, rather than in a general-purpose computer. The usage you describe is often called "headless".
How do you maintain that machine if it has no peripherals?
In any event, given that 1.3 is obsolete, nine years old and dog slow compared to modern JVMs, which themselves are free of charge and much more robust, it's hard to follow the "logic" of your client in their choice not to upgrade.
One assumes that there is no multi-threaded Java code on this dedicated machine. If there is, then you need to convince your client to upgrade to at least Java 5 to get the improved memory model.
 Signature Lew
Philipp - 12 Nov 2007 17:48 GMT >> It's not JavaME. It's just a standard 1.3 JVM running on an embedded >> PC (maybe I'm misusing the term "embedded", it's a CPU (no screen, no >> keyboard etc.) in a box running the JVM).
> How do you maintain that machine if it has no peripherals? It has a network interface and a serial port.
> In any event, given that 1.3 is obsolete <snip>
> you need to convince your client to upgrade > to at least Java 5 to get the improved memory model. Thanks for the advice. I will definitely try to convince them. Phil
Lew - 12 Nov 2007 18:06 GMT Lew wrote:
>> In any event, given that 1.3 is obsolete > <snip> >> you need to convince your client to upgrade to at least Java 5 to get >> the improved memory model. The part you snipped was the condition under which I suggested it was worth trying to convince the client to upgrade. Otherwise I'd not deem it worth the effort.
 Signature Lew
Philipp - 13 Nov 2007 07:02 GMT > Lew wrote: >>> In any event, given that 1.3 is obsolete [quoted text clipped - 5 lines] > worth trying to convince the client to upgrade. Otherwise I'd not deem > it worth the effort. It is in fact the case that the prog is multithreaded, so I will definitely speak to my boss about it. Phil
Lew - 13 Nov 2007 08:14 GMT Lew wrote:
>>>> you need to convince your client to upgrade to at least Java 5 to >>>> get the improved memory model.
> It is in fact the case that the prog is multithreaded, so I will > definitely speak to my boss about it. Just to give you some ammunition and a caution: With Java 5 there were quite a few changes. The best known are the addition of generics, enums and the "enhanced-for" loop structure. Less well known but arguably more important were the addition of the java.util.concurrent and related packages, and the cleanup of the so-called "memory model" for multi-threaded programs. These have made multi-threaded, concurrent programs much easier to craft for stability and reliability.
<http://java.sun.com/javase/6/docs/api/java/util/concurrent/package-summary.html> gives a brief overview.
The memory model in Java 1.4 and prior had some subtle issues that tended to show up more frequently in multi-processor architectures. The new memory model makes it easier to reason about and create correct concurrent programs.
The new API classes make it easier to implement concurrency and to prevent bugs like deadlock and starvation, while maintaining high performance.
Furthermore, the JVMs have improved markedly since Java 1.3. They are faster, easier to tune and better at optimizing than ever before. Current JVMs have tricks to load faster and take up less memory than before.
On top of that, the new syntactic sugar since Java 5 does enhance programmer productivity.
With all that said, it is not entirely unreasonable to maintain a Java 1.3 platform. If you aren't encountering weird concurrency bugs and your productivity is acceptable, it's understandable the boss is reticent to make a change.
One way to ease concern is to create a testbed with the new Java version (6, these days). First, make sure your code compiles correctly on the new platform. The presence of keywords like 'enum' or 'assert' in old code causes a glitch. Assuming you get through that all right, measure performance between the platforms. You should see improvement with the current JVM. (You may wish to run it with options like "--server" to enhance optimization.) Again assuming all goes well, you can then make a case for scheduling an upgrade to the production platform.
There is no free lunch. To take full advantage of the new features could well involve some re-engineering of the code base. Given that version 1.3 is seven and a half years old now, and obsolete, and that the re-engineering will generally improve the code (it probably needs it anyway - most older code does), this is likely to be a worthwhile investment of effort.
(Java 5 is already over three years old - hardly a spring chicken among software products.)
 Signature Lew
Philipp - 13 Nov 2007 16:16 GMT > Lew wrote: >>>>> you need to convince your client to upgrade to at least Java 5 to [quoted text clipped - 55 lines] > (Java 5 is already over three years old - hardly a spring chicken among > software products.) Thanks for all this detail. Phil
Sherman Pendley - 12 Nov 2007 22:24 GMT >>> I know! :-) But I'm tied to an antiquated 1.3 JVM. >> [quoted text clipped - 5 lines] > JVM (not sun!) are... how should I put it... a bit late on the > schedule. Wow - and here I was thinking Apple was behind the times...
sherm--
 Signature WV News, Blogging, and Discussion: http://wv-www.com Cocoa programming in Perl: http://camelbones.sourceforge.net
Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
|
|