Michal Suchanek
12/7/2007 4:08:00 AM
On 06/12/2007, Charles Oliver Nutter <charles.nutter@sun.com> wrote:
> Michal Suchanek wrote:
> > However, the one-click-jar is far from portable. It uses Sun
> > proprietary solution which runs "everywhere" (read: on the platforms
> > for which they bothered to make a binary). It runs on Windows, at
> > least the recent NT based. On OS X but it's usually a bit behind when
> > new version is out, especially for people that do not have the newest
> > OS X version as well. On Linux it runs on x86 and x86_64. It also runs
> > on Solaris, and probably HP-UX. There is some ancient and incomplete
> > port to ppc-linux by IBM, probably as a result of support for their
> > something360.
>
> OS X is one version behind, and will probably have a full Java 6 release
> soon. Java 6 versions exist for Linux 32/64, Solaris, and Windows. And
> there are at least two alternative Java 5 VMs for Linux, Solaris, and
> Windows...often many more. There's dozens of Java implementations, and
> Java 7 source is GPL and rapidly being ported to platforms that don't
> have up-to-date JVMs (the BSDs, OS X, and more).
>
> > If you did not require Swing there are alternative VMs that are free
> > (and free to compile on anything) but then you would be back to
> > distributing binary extensions because you would need something like
> > AWT which is not part of the Java standard library. Also these free
> > alternative VMs do not have complete standard library. As far as I
> > understand the issue the Java documentation license does not allow
> > implementing a library complying with the documentation which is the
> > primary reason why efforts at implementing complete alternative VMs
> > did not get very far.
>
> AWT is part of the standard library. And Sun's JVM has been free for
Free if you happen to have the right platform ..
> years, and now Free in Java 7. You are wrong about any documentation
> licenses...I'm not sure what you even mean by that. And as I mentioned
The Java 5 documentation used to have very onerous license. Have you
ever read it? Maybe the newer ones are better. I heard that Java 7
will be GPL but we are not there yet.
> before, there's dozens of JVM implementations. I'm not sure what more
> you're looking for here.
Where is a complete Java 5 implementation other than Sun JVM? With the
GUI stuff and all? Everywhere I always see "Sun JRE required". Sure
the situation would be different for server stuff or other
applications where the fancy GUI is not required.
>
> > Then there is that "write once run everywhere" thing with which Sun
> > tries to push Java. If I have never heard that I would probably not
> > get so much irritated whenever I hear about Java portability.
> >
> > Java software is *NO MORE* portable than C software. Given the
> > proprietary nature of the VM it is actually *LESS* portable. It has
> > all the common portability issues plus it won't run on platforms for
> > which there is no JVM, ever.
>
> C code would not run on platforms where there's no C compiler...but even
> worse, a given app won't run unless all libraries it uses have versions
> for that platform as well. There's certainly a "debug everywhere"
> component to Java apps, but once you compile them they're basically
> runnable on any Java implementation. C apps, not so much.
>
> But you're still thinking of JRuby in terms of Java here. JRuby is not
> Java. JRuby is Ruby on the JVM. The JVM exists in dozens of forms, free,
> proprietary, embedded, and on big iron. With the exception of some of
> the smaller embedded profiles and some of the incomplete free impls,
> JRuby allows Ruby to run on any of them...faster than Ruby 1.8.6, and
> with all the "good bits" of the Java platform available. Don't think of
> JRuby in terms of Java.
When we are talking about Swing frameworks it is something Java, and
probably even Sun JVM specific. How can you abstract Java out then?
>
> > At least the Java software you meet in practice is swamped with
> > compatibility problems. Most Java software requires specific minor
> > version of the JVM, and with this one click approach you can hardly
> > install several versions of the JVM. Yes, the JDK tools have the
> > option to compile for older runtimes. I have yet to see this working.
> > When java 1.5 came out, and our CMS software developer upgraded,
> > everybody had to upgrade their runtime. He said he is compiling with
> > the compatibility switch but it just did not work. Maybe it's just the
> > Java crowd being mostly incompetent. I don't know.
>
> I think you're just misinformed, or getting your information from bad
> sources. It's not anywhere near this difficult...no more difficult than
> apps that target a specific C library version. Except in this case, you
> know that one version numbers guarantees you a specific version of every
> core API you're going to use, from database access to GUIs.
Specifically with libc some common systems allow to install several
libc version, and the right is picked for running the application.
However, Java application for different version of JVM just breaks.
>
>
> > What's worse, I have seen a banking application that requires a
> > specific patchlevel version (yes, specific -pn suffix). This same
> > application also works only in IE, how portable. Even for applications
> > that try, I have seen subtle input event handling differences between
> > Windows and Linux, enough to break stuff. And an application that
> > would not have sound on Linux - not sure if it simply did not work or
> > it caused so much trouble they decided to turn it off.
>
> The patchlevel thing sounds like they probably hit a bug in that impl of
> the JVM and needed an updated version. That happens to any software.
>
> The IE thing is a web/UI design issue completely unrelated to Java.
>
> Sound on Linux has been a traditionally hard thing to get working for
> any application, so Java's certainly not alone here either. And the
> Linux situation has improved for all apps. You're going on really old
> information.
This is the impression that gradually built as I got into contact with
Java applications over a few years. Although some experience is quite
old I still do not see any improvement.
>
> > With these version and platform constraints you may need a quite large
> > vmware stack if you want to run a number of Java applications :->
>
> Ask anyone who's actually run a lot of Java applications recently, and
> you'll get a completely different story. You're either getting bad
> information or only looking for bad information.
Yes, if you do not need too many, and are careful about upgrading the
JVM (ie never upgrade it until you get an application that does not
work anymore) you should be usually fine. But if you dust off an older
application for managing some piece of hardware that's just getting
out of service you may need a dedicated box for it :)
>
> And again, please don't think of JRuby in terms of Java.
>
> > hmm, anyway, thanks for bringing ruby even to such a hostile
> > environment for the benefit of those stuck in there ;-)
>
> It's not just for those stuck on Java, it's for those who want a fast
> Ruby 1.8 implementation plus a whole lot of other bells and whistles.
Yes, I would trust it for something like web server. But I would yet
have to see a portable GUI application in Java.
Thanks
Michal