Slashdot Mirror


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

11 of 28 comments (clear)

  1. Text of the story by lobsterGun · · Score: 4, Informative

    Firefox completely borked the formatting of the interview.

    Here is is, in case any of you actually read.

    Yakov Fain writes: I was able to catch Calvin right before the plane from San Francisco to New York where he'll be presenting the new features of the Java language to the New York Java Users Group this week.

    YF: Please tell us about yourself and your role in the Tiger project

    Calvin Austin: I'm the J2SE 5.0 Specification Lead, JSR 176 in the Java Community Process. The J2SE 5.0 expert group consists of 18 members including all the major industry partners and JVM porters.

    YF: What are the main new features of the language being introduced in J2SE 5.0?

    Austin: Four main themes ran through the release.

    1. Ease of Development. These are the first significant updates to the Java language since 1.0 was released. The main ease of development features are generics, metadata, enhanced for Loop, enums, and autoboxing.
    2. Monitoring and Manageability Monitoring a JVM using JMX and SNMP protocols, enhanced diagnostics, a low memory detector.
    3. Performance and scalability. Faster startup time using class data sharing and automatically tuned server configurations, something we call "performance ergonomics."
    4. Desktop Client. A refreshed new cross-platform look-and-feel called Ocean. OpenGL hardware acceleration for intensive graphics apps.

    YF: You probably have received lots of different suggestions from the developers community about the "missing" features of the Java language. How did you make a decision?

    Austin: Generics received the popular vote, it was one of the top 20 "Requests For Enhancements" (RFE) on the Java developer connection site. All 20 RFEs were added as potential features. For the other language features the final decision was made in the respective JSRs, like JSR 201 and JSR 14. Sun was the spec lead for both those JSRs and so also involved James Gosling and others in the initial reviews.

    YF: Large corporations usually switch to newer version of any programming language with substantial delays. What do you think is a major selling point of the new version Java?

    Austin: One of the major selling points of this release is that you'll be able to slot in a 5.0 JRE to your application and benefit from the improved performance, monitoring, diagnostic tools, and reliability without changing a line of code. However there are also benefits in also recompiling and updating your source code. Using Generics, the compiler can alert you to runtime class cast exceptions, the concurrency API gives you the flexibility to re-write code to have improved thread safety.

    YF: Did you run into any compatibility issues between Java 1.4 and Java 5.0?

    Austin: Running applications should be fine. The one thing developers need to watch for is that enum is now a keyword as the javac compiler language is 5.0 by default. This applies to the assert keyword that was added in 1.4

    YF: Are there any performance improvements in the new version?

    Austin: Startup time is improved even though Tiger is a bigger release, server side benchmarks with performance ergonomics are greatly improved on machines with two or more CPUs.

    YF: What are the benefits for fat client Java applications?

    Austin: Improved startup time, skinnable API (synth), reduced jar file sizes for downloading when using the pack API.

    YF: Let's forget about the corporate world for a minute. What do you think is the coolest new feature of the language?

    Austin: If I just restrict myself to the language it would be metadata (JSR 175). We've only scratched the surface of its potential. For the platform, it's a bytecode insertion for profiling (JSR 163).

    YF: In some cases new features of a programming language not only improve the language, but also may change the style of programming in general. If you were a college professor or a Java trainer, would you teach your students using some new concepts of programmi

  2. Java on Linux -- Ugly step child... by Spoing · · Score: 4, Interesting
    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.

    --
    A firewall can not protect you from yourself. Turn off what you do not need. Do not use the firewall to do your work.
    1. Re:Java on Linux -- Ugly step child... by LeninZhiv · · Score: 4, Interesting

      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?

    2. Re:Java on Linux -- Ugly step child... by Taladar · · Score: 2, Interesting
      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
  3. Intel EM64T support!! by nvrrobx · · Score: 2, Interesting

    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!

    1. Re:Intel EM64T support!! by wetlettuce · · Score: 2, Informative

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

      SUN claim support on AMD64 in Linux as noted on their website.

    2. Re:Intel EM64T support!! by nvrrobx · · Score: 2, Informative

      Right, they support amd64 machines but not Intel EM64T machines. Intel implemented all of the x86_64 specifications except for two instructions (prefetch and prefetchnw, IIRC). Those two instructions are 3DNow! specific, and not supported on Intel. If you try to call them (which Sun's amd64 binaries do), you immediately crash with a SIGILL (illegal instruction).

    3. Re:Intel EM64T support!! by Skuto · · Score: 5, Funny

      You should have gotten a genuine AMD64 instead of one of them crappy Intel clones ;-)

  4. having trouble with jdk 1.5 generics by zaqattack911 · · Score: 4, Interesting

    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.

    1. Re:having trouble with jdk 1.5 generics by Anonymous Coward · · Score: 2, Informative

      Sun used type erasure to implement generics without changing the JVM. Hopefully a new compiler/JVM at some point will provide support without type erasure.

      BTW, have a look at java.util.Queue, and its implementing classes. Sun finally got around to providing a queue.

  5. Meta-data is only the beginning of the story by descubes · · Score: 3, Interesting

    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.

    --
    -- Did you try Tao3D? http://tao3d.sourceforge.net