RE: [ObjectWeb architecture] just an idea for (Java) native comp ilation

["Leskov, Dmitry" <dleskov@xxxxxxxxxxxxxxxxx>]

        Markus,

> 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.
> 
        Sure, I am not going to pretend that our software is bug-free or was
designed using fail-safe methodologies. Then, with Sun you have the option
to tell them about the bug, but see how many bugs have been open in their
bug parade for years... Maybe they would fix the bug you submitted if you
subscribe for some paid support service, I do not know. 

> 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. ;-))
> 
        *I* did. Moreover, the article from which I borrowed the sample
includes all this information. I have included its URL in my message instead
of pasting full explanation and workaround, just to save space. So please do
not make assumptions about my knowledge of the platform and tools. :)

> 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...
> 
        Well, suppose you have read the docs, but the author of some
third-party component that you want to use have not. You can guess the
reason of the problem, decompile the offending classes and recompile with
proper switches or try complaining to the author. But there are situations
when neither would work. A friend of mine is a Java developer for a company
that makes call center equipment. They are using some third party Java
library which does not work on 1.4, because some API has changed. The
library is obfuscated so they cannot patch it and the vendor refuses to fix
the problem since 1.4 release. The problem is that there is no other Java
library on the market that does the same thing (as far as I can recall, it
has to do with audio stream encoding/decoding and analysis), so they still
live on 1.3 and the management thinks about moving to .NET...

> 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.
> 
        If you have many (potential) clients who still use Windows 95, you
have to make sure your app works on Windows 95. That involves extra efforts,
just as if you were writing for Java 1.3 using the 1.4 tools. Otherwise, you
can just write "Windows 2000/XP" in requirements and make your app refuse to
install on 9x. With Java, you would write "1.4" in you JNLP descriptor.

        Then, Windows is not a perfect analogy, because it is only available
for one hardware platform (well, now also for IA64) and comes from one
company, whereas there are many Java vendors that have their own release
schedules. 

        The Windows 95 to 3.11 example is even more incorrect, because there
was also a big change in  hardware. Or am I so ignorant and Java 1.4 uses a
different set of bytecode instructions? :)

> 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.
> 
        Sure, but do you agree that programs compiled for 1.3 should work on
1.4 in exactly the same way? 

> Maybe what many people are upset is that WORA. Actually WORA works if the
> ISV knows what he does. 
> 
        This is exactly my point. Should not it be rephrased "Think Twice,
Write Once, Test, Uh-Oh, Think Again,..." then? :) Or would that resemble
the C++ development cycle too much? :)

> 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.
> 
        Now, why I think that downwards compatibility *is* an issue? Because
it takes vendors time to update their JDKs after Sun releases a new major
version. Can you recall how many months did it take IBM to update the Linux
JRE to 1.4? If you are developing on Windows/Linux/Solaris, you have access
to the latest stuff, but if your clients use other platforms or have some
third-party apps that only run on 1.3.x, you have to keep that in mind. 

        Well, I just wanted to provide some samples you asked for and to my
surprise it turned into an argument. I agree with you on most points
actually. The problem is that there was too much hype about WORA and it
disappoints people a lot when they hit one of such problems.

        With best regards,

        Dmitry

> -------- 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
> 
>  << File: message.footer >>