[TriLUG] Re: Managed languages (was .NET development on Linux)

[David A. Cafaro]

On Thu, 2004-06-17 at 10:56, Joseph Tate wrote:
> 
> Yes, I should clarify.  Red Hat/Fedora Linux does not have a JRE out of 
> the box.  I have yet to come across a distro that offers it.  Hopping 
> into the #Java channel on Freenode, and posing the question of which 
> distro is best for Java development I didn't get an answer.  Downloading 
> and installing the Sun JRE has been tricky at best.  Non-professionals 
> aren't going to know about blackdown/IBM/Geronimo, let alone where to 
> get it.  Well supported to me means trivial to install and use by a 
> non-professional, and easy to find.  Sun's done a better job recently, 
> with the Windows side, but Linux is still pretty substandard.
> 

As for computers that come with a JVM by default, your right almost no
Distro's do, and neither does Windows XP.  A lot of this comes from the
Sun vs MS lawsuit, and is much longer that I want to get into here.  I
would like to point out that Red Hat does provide an IBM JDK/JVM
download for their RHAS3 platforms, but not for their Fedora as you
mentioned.  I believe most of the reason for the lack of JVMs installed
with Distros has to do with licensing and Distribution rights.  I hope
that more distros may take a look at Blackdown and Apache in the future
to include these.  As of right now the first thing I have to do with any
new Machine regardless of if it is a Windows, Linux or Mac is to install
a JVM on it, since none of them come with this standard now.  

One small note, many new computers do come with a JVM pre-installed, but
that's the doing of the computer manufacturer, not MS Windows.

> Don't get me wrong: I love Java.  It's my favorite language.  It's rich, 
> and powerful, and you can do almost anything with it.  But it's got a 
> lot of baggage.  These are problems that have mostly been solved on 
> Windows.  But they are not handled out of the box on any other platform 
> but Solaris.  Gjc will compile Java code to native, and therefore your 
> Java code _will_ be just a standard executable.

Just my experience but they all have baggage including Windows.  A lot
of this just comes from trying to make a language that you can literally
write on one system and have it run on any system.  If you think about
what this is trying to accomplish it isn't so strange that it has it's
baggage, it shouldn't be hard to accomplish, but it is because of the
way the tech world has developed.  Unfortunately Gjc won't solve this,
the code may be portable, but the app won't be.  There is still room for
improvement for Java apps, but I haven't found it to be as troublesome
as you have.

> 
> If the baggage has been handled elegantly by you or some other source, 
> I'd love to hear about it.  What I want is what Mr. Merrill has 
> described.  Execute Java code as a normal app.

Easiest solution for this is have the user start the program with a
shell script that handles any of the nasty Java stuff in the
background.  It will start and act like a normal app (the user doesn't
have to type in "java -c classpath:stuff myjavaapp") just "./myjavaapp")

> 
> Also, as a kind of watermark: Occasionally I'll log into the Durham 
> County Library System's web catalog system (a Java applet deployed via 
> browser).  It's relatively quick using IE and MSJVM, but it's slower 
> than molasses on a cold day in FireFox using a Sun supplied JRE in 
> either Windows or Linux.  Could be Mozilla's fault, but it's 
> unacceptable.  Oh, and Eclipse?  The last Milestone 3.0 release doesn't 
> run with IBM's Java.  It requires the Sun JDK.  Talk about screwball.

As for MSJVM and IE vs Mozilla and Sun JVM, can't tell you why you are
having issues with it.  Could be MSJVM being better tuned, the app is
better tuned for MSJVM, or just Mozilla having issues. Again in my
experience loading a Java app is slow, but once it's started seems to
tinker along quite fine for me using Mozilla/SUN/Linux.

Just a quick look at Eclipses Reference Platform specs shows that it is
supported on Sun and IBM SDK's on Windows and Linux, MacOS X SDK for OS
X 10.3, and HP-UX 11i with HP-UX SDK.  Now given this is still not
release software (Basically Release Candidate Only) different builds
could be broken at times.  There's always a chance that a developer is
working on the 1.4.2 platform and forgets that something he/she added
isn't supported by 1.4.1 (which seems to be their target platform)

I guess I've just had better experience with it than you have, it's
unfortunate that it's like that, but that's true of all software
really.  

-- 
David A. Cafaro
dac(at)cafaro.net
Admin to User: "You did what!?!?!"