Prime Mover of Java's Port to Linux Interviewed

jg21 writes "After Java 5, what will become of Calvin Austin now that he's lead engineer - and spec lead - in charge of J2SE on Linux? This interview shows him to be Sun's most personable developer asset after James Gosling. (Gosling BTW, who famously uses Mac OS rather than a PC, has a Linux box and uses the X support on OS X to run Java 5.) Asked what feature in the new Java edition he considered coolest of all, Austin without hesitation replied "Metadata" - the spec lead for that particular feature, Austin's former colleague at Sun Joshua Bloch, was headhunted recently by Google. Now Java, Linux, and Google would be quite a combo. Maybe that's what's fueling all the recent speculation that a Google browser would probably be a browser, feed reader, blog tool, desktop search, online search, gmail, news reader, photo editing, and online photo publishing all rolled into one."

Comments

Java on Linux -- Ugly step child...

[Spoing]

OK, that's too harsh. Maybe these issues are gone with 1.5?

Complaints;

1. Must jump through hoops to at sun.com and add on other supporting tools as a seperate step to get it to work in the browser and at the shell prompt.
2. Manual dinking with scripts to run java apps; many requiring specific options. Should be seamless.
3. Version conflicts; one app requires 1.3.x, another 1.4. Java doesn't deal with the version dependencies automatically.

While these are minor annoyances, they prevent me from relying on Java being there on client systems or other servers, so I don't even put Java on unless it is necessary.

Re:Java on Linux -- Ugly step child...

[LeninZhiv]

In my experience 99 out of 100 apps are run with $ java -jar appname.jar from the command line, or else they come with an installer that sets up a launch script for you. It's not any more complicated than programs written in any other language: CLASSPATH is annoying when it doesn't 'just work' but so is libfoo.so. And actually many of the programs in /usr/bin are scripts that launch the binary with lots of command line flags and environment variables needing to be set.

I agree that some of the defaults on the command line are questionable decisions (requiring -source 1.4 instead of the other way round, -ea being off by default), but these are hidden from the end user in distributed applications.

Or to put it more succinctly: which is quicker to install, Apache or Tomcat?

Re:Java on Linux -- Ugly step child...

[Taladar]

In my experience 99 out of 100 apps are run with $ java -jar appname.jar from the command line, or else they come with an installer that sets up a launch script for you.

The last one that tried the script-setup-thing was a major pain. It used InstallNoWhere (InstallAnyWhere it is called by its makers) which needed Java 1.3 to run and brought its own JRE 1.3 with it. At first it did not run at all because the script that called it (the Java-Part of the Installer) had a workaround for some Linux-Glibc-Bug some major versions before mine and was incompatible with the fix. After googling a bit and removing the lines in the script with the workaround I tried to run it again. Now it did not run because of another issue. The JRE it insisted an using which was packaged with the Installer had not been compiled statically but dynamically with glibc (the glibc from the release of the installer) and did not run with the newer version. So I had to unpack the Installer-File by Hand and search for the Class to call to start the Installer. When I found that one the Installation ran almost fine except for one little problem. It insisted on using an 1.3 JRE for the Installed Software so I had to find an JRE 1.3 somewhere. After installing that I could then change the Start-Script for the installed Java-App to use my Systems Standard-JRE with which it run not perfect but crashed only approximately once per hour.

Now tell me how someone with normal (no) experience with such issues should install such a Java-App

Intel EM64T support!!

[nvrrobx]

Please, please, please, please make the amd64 JVM work on Intel EM64T boxes in Linux!

It's been filed on Sun's bug parade more than once and never resolved. The JVM throws a SIGILL immediately because it's calling the 3DNow! Prefetch instructions. Doesn't do this on Windows, just on Linux.

Come on, I'm willing to bet most people with EM64T and Opteron/AMD64 machines are running Linux, NOT Windows!

having trouble with jdk 1.5 generics

[zaqattack911]

As I'm just twiddling by thumbs waiting for the new Resin jsp/servlet/j2ee server to be jdk 1.5 approved (officially). I decided to try out generics on my own.

The problem is with Arrays.. you know old fashioned String[] bob = new String[13];

For testing purposed I created my own MyQueue class which supports generics:

public class MyQueue { ... }

Now, I need to use something to contain my queue elements, so naturally I want an array like:

protected Element[] myelements;

However as soon as I try and do this in my constructor: myelements = new Element[size]; I get a compile-time error claiming I can't use generics and arrays this way.

So I'm forced to either use Object[] myelements and cast everything back to (Element) when I return things, or I can use Element[] myelements, but in the constructor I need to initialize it like this: myelements (Element[]) new Object[size];

Fucking retarted.. not to mention I need to javac with the -Xlint to avoid all the warnings about casting in this way. Just to double check I wanted to see how they impletement ArrayList in java 1.5 and sure enough they were doing it the same way I was... with all the warnings and everything.

WHY?! Yes I realise I could use an ArrayList to store my queue data, but I kinda want to use lower level stuff like an array, the way java.lang api is.

Meta-data is only the beginning of the story

[descubes]

Meta-programming is much more powerful, with the ability to actually change the program, not just attach data to it. The XL programming language is designed around that idea. And open-source too. Hint: I'm always looking for contributors to help.