Re-2: [ObjectWeb architecture] just an idea for (Java) native comp ilation

[<markus.karg@xxxxxxxxx>]

Dmitry,

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

That's true but still it is an argument for not 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. ;-))
> > 
>       *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. :)

As you can see by the ;-)) it was just a joke. I really appreciate your 
knowledge and enjoy this discussion with you. I do not make assumptions about 
your knowledge, it was just the answer on the more or less false example you 
posted. I will do no more jokes in future. Sorry.

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

Did you find any GOOD third party components actually? No joke: We didn't.

> You can guess the
> reason of the problem, decompile the offending classes and recompile with
> proper switches or try complaining to the author.

Are you really doing that? We don't. Instead we post bugs and try to get 
vendor support. It's not my job to seek other's failures (as long as it is no 
open source, where I don't need to decompile).

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

So don't use that library.

> The
> library is obfuscated so they cannot patch it and the vendor refuses to fix
> the problem since 1.4 release.

What about looking for another vendor? If a vendor is dull enough not to move 
on to a new java generation eighteen months past its first release, he has to 
encounter some loss of customers.

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

Hm... Can't believe that there is really only one company that provides this. 
There is are good APIs (media API, sound API) already in the platform kernel, 
so there should be librarys which are using these. IBM and Sun would not 
invent APIs without any use. Other idea: Seems to be a golden field. Why not 
getting up and writing one and lateron selling it?

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

Correct, just what I said. No one should be silly enough to exchange "1.4" in 
JNLP by "1.3" when he is using 1.4 APIs or when he didn't use the target and 
bootclasspath parameters at compile time.

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

This is not true. Windows exists for IA64 as you wrote, and months ago it 
existed for Alpha.
Also, the version numbers are not vendor specific as one might think. The 
numbers are given by the JCP and designate the standard not the product. A 
product that implements the "Tiger" standard might be called "MyVM 36.7", but 
actually it implements "J2EE 1.5". This is a difference.

>       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? :)

In part it does. AFAIK there is a difference in the JAR format (what is EXE 
in the Windows analogy). Also AFAIK in Tiger there really is changed 
bytecode. In addition the main difference in the APIs of Win95 and Win311 was 
not the hardware change 16 to 32 bit, but a lot of new APIs and changed API 
models (driver model).

> > 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? :)

Well, this is no joke, but we do not have that problems that you talk about. 
:-)
Maybe you are writing device drivers in Java? ;-))

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

Again, we do not act when Sun acts. We act when the JCP acts. This is a 
difference. Actually the JCP publishes a new J2SE platform standard only 
every eighteen to twenty four months. Is this too fast? I don't think so. It 
was easy for us switching from 1.3 to 1.4, took us just one month. Actually 
it was not necessary but we liked the new features.

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

According to the schedule I saw on IBM's homepage, it took them less than a 
half year for the Linux version, and less than one year for the AS/400 
version! Since they are a main stakeholder in the J2SE JSR, they have the 
same chance as Sun to release as soon as possible. I think half a year is not 
much time, since we need internal testing, documentation and so on with new 
version. So we only need to wait about one or two months after our own switch 
to a new J2SE version to ensure our customers can drive it. Sure on Compaq 
Himalaya servers or on a Playstation this is not true.

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

Actually in 75% we have the same opinion. For the WORA hype: I am not fond of 
hyping anything. That hypers should first read a spec and think over the real 
idea behind it. ;-)

Have Lots of Fun
Markus