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

28 comments

  1. Slashdotters actually like Java! by viiviiviivii · · Score: 1

    It is interesting to see that in the last six months the Java posts have increased on this website.

    Maybe this is a sign that the slashdot community has a large volume of closet Java Geeks.

    Or, it could be because the powers that be accept Java related posts over posts on how the Moller sky car is going to be released next week along with Duke Nukem Forever.

    --
    ....... / ........ / ....... .......
    1. Re:Slashdotters actually like Java! by alex_tibbles · · Score: 1

      it's 'cos Sun is hyping Java 5 (ie 1.5). Ergo lots of articles about Java.

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

    1. Re:Text of the story by Anonymous Coward · · Score: 0

      Firefox completely borked the formatting of the interview.

      that isnt the fault of the browser, that is some of the shittiest html I have ever seen... check it out, you will see what I mean, they have tables with no cells and all sorts of crap.

  3. 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 Anonymous Coward · · Score: 0
      Or to put it more succinctly: which is quicker to install, Apache or Tomcat?

      Apache is much easier to install:
      apt-get install apache
      Tomcat depends on Java, which doesn't integrate as well with Linux package management. Java only seems more convenient if you are stuck using a system (Solaris, Windows, OS X, some Linux distributions) with an bad package management system.
    3. 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
    4. Re:Java on Linux -- Ugly step child... by mike_sucks · · Score: 1

      That's why you run Debian, so it sorts all of this stuff out for you, right?

      --
      -- "So, what's the deal with Auntie Gerschwitz et all?"
    5. Re:Java on Linux -- Ugly step child... by lscoughlin · · Score: 1

      yeah uh... I would take issue with the app's maker/distributor, rather then with java....

      Compare the oracle installer with Eclipse....

      one sucks
      one rocks

      shrug.

      --
      Old truckers never die, they just get a new peterbilt
  4. Google Browser by jefu · · Score: 1
    It will be interesting to see if Google actually does build its own browser and how it is distributed. If it really provides information management capabilities for both networked (what is beginning to look like ubiquitous) computing and for personal computer use, it could be the application that defines computing in the future.

    Of course it might end up windows specific, in which case it will have a tough fight against MS providing the same capabilities. If it is truly multi-platform and uses a shared datastore (like gmail only for all kinds of data) it could be Really Cool and might end up shaping the way we all deal with information.

    1. Re:Google Browser by Anonymous Coward · · Score: 0

      And since they are turning into the Borg they will keep all your mail, web browsing habits, etc all in a centralized database to start selling as soon as they can figure out how... Say NO to someone else having all your information with NO restrictions!

  5. Rube Goldberg by nusratt · · Score: 1, Offtopic

    (if you don't grok the reference, google it.)

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

    which, if true, would show that Google is being sucked into the Dark Side, becoming another msft.
    After all, it probably wouldn't be an OSS effort, and the hyper-integration is reminiscent of the Win/IE integration trick.

    OTOH, if it WERE oss, how does this swiss-army-knife abomination fit oss traditions?

    1. Re:Rube Goldberg by Anonymous Coward · · Score: 0

      OTOH, if it WERE oss, how does this swiss-army-knife abomination fit oss traditions?

      One word: emacs.

    2. Re:Rube Goldberg by 0racle · · Score: 1

      Like how emacs is a simple tool that does one thing and complex jobs are done by stringing many little programs together? That's oss tradition, simple apps is Unix tradition. Many today expect an app to do everything they ever want their system to do, if it doesn't they wont use it. Googles browser would have to become emacs for anyone to really take notice.

      There's nothing wrong with close integration on its own, just that there is less room for error in each of the parts.

      --
      "I use a Mac because I'm just better than you are."
  6. 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. Re:Intel EM64T support!! by Anonymous Coward · · Score: 0

      Java works fine on an AMD64 chip.

    5. Re:Intel EM64T support!! by Bluelive · · Score: 1

      prefetch dont really sound critical, so maybe filter out these intructions out of the binary and put back some nops ?

  7. 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 zaqattack911 · · Score: 1

      aaak slashdot filter fucked me.

      my class declartion above should read:

      public class MyQueue<Element> { .. }

      and the way I had to initialize my container array in the constructor was:

      myelements (Element[]) = new Object[size];

      (it cut out my equals sign for some reason).

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

    3. Re:having trouble with jdk 1.5 generics by Anonymous Coward · · Score: 0

      This kind of flexibility works well in Python.

  8. Mac OS by Anonymous Coward · · Score: 0
    Gosling BTW, who famously uses Mac OS rather than a PC ...

    So nowadays you become famous for not using a (Windows-)PC?

  9. 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
  10. Sun losing top engineers by Anonymous Coward · · Score: 1, Insightful

    Why is Sun continuing to lose its top talent? You would think working on Java would be cool so there must be something else going on there.