Become a fan of Slashdot on Facebook

 


Forgot your password?
Close
typodupeerror
×
Java Programming

Prime Mover of Java's Port to Linux Interviewed 28

Posted by michael from the no-swing-for-you dept.
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."
This discussion has been archived. No new comments can be posted.

Prime Mover of Java's Port to Linux Interviewed More

Prime Mover of Java's Port to Linux Interviewed

Comments Filter:
  • 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.

  • Text of the story (Score:5, Informative)

    by lobsterGun ( 415085 ) on Friday October 01, 2004 @10:38AM (#10404248)
    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

  • Java on Linux -- Ugly step child... (Score:5, Interesting)

    by Spoing ( 152917 ) on Friday October 01, 2004 @10:56AM (#10404431) Homepage
    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... (Score:5, Interesting)

      by LeninZhiv ( 464864 ) * on Friday October 01, 2004 @12:14PM (#10405287)
      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?

      • 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 som

    • That's why you run Debian, so it sorts all of this stuff out for you, right?
  • 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 d

  • Rube Goldberg (Score:2, Offtopic)

    by nusratt ( 751548 )
    (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 swi
    • 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.

  • Intel EM64T support!! (Score:3, Interesting)

    by nvrrobx ( 71970 ) on Friday October 01, 2004 @12:30PM (#10405476) Homepage
    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 (Score:5, Interesting)

    by zaqattack911 ( 532040 ) on Friday October 01, 2004 @03:47PM (#10407944) Journal
    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.

    • 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).

    • Re:having trouble with jdk 1.5 generics (Score:2, Informative)

      by Anonymous Coward
      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.

  • Meta-data is only the beginning of the story (Score:4, Interesting)

    by descubes ( 35093 ) on Saturday October 02, 2004 @01:07PM (#10413821) Homepage
    Meta-programming is much more powerful, with the ability to actually change the program, not just attach data to it. The XL programming language [sf.net] is designed around that idea. And open-source too. Hint: I'm always looking for contributors to help.

  • Sun losing top engineers (Score:1, Insightful)

    by Anonymous Coward
    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.

Slashdot Top Deals

He has not acquired a fortune; the fortune has acquired him. -- Bion

Close