Re: Ruby App Distribution

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
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
before, there's dozens of JVM implementations. I'm not sure what more
you're looking for here.

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.

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.


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.

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.

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.

- Charlie

.

Relevant Pages

  • Re: Potential new recruit to Java. Could I/Should I use Java?
    ... For which platforms is Sun's Java available? ... Sun provides versions for Windows, x86 Linux, x86 Solaris and Sparc Solaris. ...
    (comp.lang.java.programmer)
  • Linux Suns JVM needs improvements
    ... As I already pointed out in another thread, I really think the Linux ... whenever Java loads in Linux, it is such a system hog!! ... Looks as if the Linux JVM had zero garbage collection. ... Sun should really take care of thier JVM if they want to make Java ...
    (Fedora)
  • Re: Apache + tomcat + openbsd
    ... >>assume you can run any kind of production Java code on OBSD. ... Java runs well enough on Linux and FreeBSD (though the ... It is one of the reference platforms for Sun and is available as ... very Java-friendly patches to the Linux Kernel lately, ...
    (comp.unix.bsd.openbsd.misc)
  • Re: Off Topic, but need help
    ... The Net.Framework will probably become available for Linux too, and probably is working on other systems already - it's not my strong side. ... The process of making it is much the same as doing Java. ... .NET framework gains wide acceptance in Linux-land. ... from someone who is required to consider platforms in development of new software... ...
    (sci.geo.geology)
  • Re: Clear the Screen
    ... cannot be implemented in any standard way across platforms. ... Even the 'standard' C and C++ languages which, like Java, aim for platform ... do not implement such functionality. ... of a development commitment needs be made by using JNI. ...
    (comp.lang.java)