Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
HomeAnnouncementsWhite Papers
Discussion GroupsFirst AidDatabasesJavaBeansGUIJava 3DVirtual MachineCORBASecurityToolsGeneral
Java DirectoryOpen Source ProjectsSample Book ChaptersUser GroupsWeb Resources
Related Topics
Databases.NETMore Topics ...

Java Forum / General / November 2007

Tip: Looking for answers? Try searching our database.

Compiling 5.0 syntax java files

Thread view: 
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 Magazines

Get 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 ...

Oracle MagazineNetwork ComputingComputer WorldBio-IT WorldeWeekInformation WeekInfosecurity
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2008 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.