Re-2: WG: Re-4: [ObjectWeb architecture] just an idea for (Java) n ative comp ilation

[<markus.karg@xxxxxxxxx>]

Dmitry,

thank you for that examples. Actually what you mention are three different 
things:

1) Bugs

Every VM has bugs. I am assuming that you will not tell us that your VM is 
bug free. What sense does it make to switch from one VM to another and give 
up the bugs of one to get the bugs of the next? Also, I would prefer telling 
the vendor of a bug to receive a patch instead of just switching the VM.

2) Incompatibilities

1.4 is fully backwards compatible with 1.3 besides the API changes that are 
necessary. Nevertheless, you example (Hello World / NoSuchMethod) actually is 
false: It works well compiled with the javac 1.4 then executed on java 1.3! 
You need to know your platform, and you need to know your tools (as I ever 
told before). javac 1.4 needs to know the JRE to link against, and the JRE to 
run lateron:

The no-magic, no-trick command line

C:\j2sdk1.4.2_01\bin\javac -target 1.3 -bootclasspath 
C:\progra~1\javasoft\jre\1.3\lib\rt.jar Hello.java

uses the 1.4 javac compiler to produce a class file that has format of Java 
1.3 class files, and that is linked against the JRE 1.3 classes. RTFM. ;-))

Runs well on my local Sun JRE 1.3:

C:\progra~1\javasoft\1.3\bin\java Hello Markus

produces this output:

hello, Markus!

That class file runs on both, JRE 1.3 and 1.4, since it has 1.3 format and is 
linked with 1.3 JRE. Java is UPWARDs compatible, not DOWNWARDs. That means, 
sure if you compile it without target and bootclasspath switches, what you 
get is expected to run on JRE 1.4 and sure will not work on 1.3. But hey, Sun 
can expect one to read the docs when using their free JDK...

For the JDBC example: It is bad design to try to implement a piece of 
software that is intended to support the latest features PLUS support the old 
features. In short, JDBC 2 is something different than JDBC 3. J2SE 1.3 is 
another platform than J2SE 1.4. Again: UPWARDs compatibility, not DOWNWARDs. 
If you are writing a JDBC 2 driver on Java 1.3, it runs on JDBC 3 with Java 
1.4 without a change. Not the other way! But is a Windows 95 program running 
on Windows 3.11? The correct decision is: Every generation needs its own 
implementation if you want to support the latest features of that generation. 
You cannot write GOOD code on any platform that supports more than one 
generation in the best possible way. If you want to write JDBC drivers that 
run on J2SE 1.3, you may not include standards from J2SE 1.4. Same problem as 
the Hello example above. You need to know your platform, and that includes: 
You need to know your generation.

3) Platform Design Changes

This is the "official incompatibilities". Sometimes it is necessary to change 
the API design. Every vendor does this. Why not Java, too? Since Java 1.3 is 
not Java 1.4, it is allowed to change the platform.


Maybe what many people are upset is that WORA. Actually WORA works if the ISV 
knows what he does. WORA works inside of a generation. WORA works UPWARDs for 
the most extend (not for point 3) even with increasing platform numbers. But 
WORA is not meant to work DOWNWARDs. The idea that WORA would work DOWNWARDs 
is not promised.

Have Fun
Markus





-------- Original Message --------
Subject: RE: WG: Re-4: [ObjectWeb architecture] just an idea for (Java)  n 
ative comp ilation (07-Okt-2003 11:31)
From:    dleskov@xxxxxxxxxxxxxxxxx
To:      markus.karg@xxxxxxxxx

>       Markus,
> 
> > > The deployment aspect is ONE important aspect. We also had ENORMOUS 
> > > performance improvements compared to JDK 1.3.1 and could NOT use JDK
> > 1.4.x 
> > > for some JDK incompatibility reasons :-)
> > 
> > Even if this is off topic: What JDK incompatibility do you mean? We are
> > using 1.3 and 1.4 parallel and did not experience such. Can you give me an
> > example to prevent us trapping into the same problem?
> > 
>       From you previous postings I judge that you are developing
> complicated apps that run on many different VMs, OS, and hardware, so I am
> sure you are aware of many such incompatibilities, but have got so used to
> them that you do not consider them as such. Just a few samples:
> 
>       public class Hello
>       {
>           public static void main (String [] args)
>           {
>               StringBuffer greeting = new StringBuffer ("hello, ");
>               StringBuffer who = new StringBuffer (args [0]).append ("!");
>               greeting.append (who);
>               
>               System.out.println (greeting);
>           }
> 
>       } // End of class
> 
>       Compile this with javac from 1.4 and run on 1.3:
> 
>       >...\jdk1.3.1\bin\java Hello world
>       Exception in thread "main" java.lang.NoSuchMethodError
>               at Hello.main(Hello.java:20)
> 
>       See http://www.javaworld.com/javaqa/2003-05/02-qa-0523-version.html
> for details.
> 
>       See
> http://www.javaworld.com/javaworld/jw-09-2003/jw-0926-overcome.html for the
> discussion of workarounds for JDBC API incompatibilities.
> 
>       We have been hit by annoying incompatibilities in AWT/Swing
> ourselves. The default font has different size in pixels in 1.3 and 1.4, so
> on 1.3 some texts did not fit the respective placeholders. There is a bug 
> in
> 1.3 in the calculation of the size of the box that the given text would
> occupy (if you enable anti-aliasing.) We had to insert some logic to
> intercept keypress events on 1.4, because the events are dispatched
> differently. Custom L&Fs are just too different, and so on.
> 
>       Finally, there is an "official" list of incompatibilities at:
> 
>       http://java.sun.com/j2se/1.4/compatibility.html
> 
>       With best regards,
> 
>       Dmitry Leskov
> 
> To: markus.karg@xxxxxxxxx
>     architecture@xxxxxxxxxxxxx