JSR 270: J2SE 6.0 ("Mustang") Release Contents


News: JSR 270: J2SE 6.0 ("Mustang") Release Contents

  1. JSR 270: J2SE 6.0 ("Mustang") Release Contents (15 messages)

    The Umbrella JSR for the J2SE 6.0 ("Mustang") release has a review ballot. The themes for this release are: Compatibility and Stability, Diagnosability, Monitoring, and Management, Ease of Development, Enterprise Desktop, XML & Web Services, and Transparency. Not as drastic a release as 5.0?

    Read more: JSR 270: J2SE 6.0 ("Mustang") Release Contents

    David Flanagan on Java 6.0 sneak peak

    Threaded Messages (15)

  2. I had a look at each JSR being talked about here: http://www.magpiebrain.com/, and it seemed to lack the focus of Java 5, and be an effort to match features already in .NET - there seems to be a distinct movement away from the inital idea of what J2SE was (include what everyone needs), to more of a .NET model (include everything!).
  3. Permalink to my post should of been http://www.magpiebrain.com/archives/2005/02/16/mustang
  4. They're generally pretty inoffensive, as you say. Still, nothing *really* exciting there, but a lot of stuff that's been discussed at length already.
  5. Version 6??[ Go to top ]

    Why go up a whole version, looks more like a point release to me.
  6. Version 6??[ Go to top ]


    These changes do not justify new version number.
    I think it is a marketing move.
  7. User Interface[ Go to top ]

    While 'enterprise desktop' is one of the announced themes of Mustang, when you come to enumerating jsrs there are none about it.
    I think that also the java desktop user interface (swing) should run under community reviews (jsrs) for enhancements.

  8. I read about the new execution model of jdk1.6, that allows applicaton to run inside a single JVM but isolated one from the other. This is really an important feature if enterprise Java wants to reach server consolidation (I have in mind many Tomcat, with different configurations incompatible each other running on the same process), but it seems to be disappeared !!!
    This is the only new feature that can justify Mustang = Tiger + 0.1.
  9. Isolates[ Go to top ]

    Where did you read about new execution model? Last time I checked, Sun dropped the ball on support for Isolate API in Mustang, and spec lead Pete Soper said that it wont be in there and that simple 1:1 (new VM for each isolate) implementation may happen as java extension, developed parallel to Mustang. He said the same thing when Isolates were dropped from Tiger, but nothing happened.
  10. Isolates[ Go to top ]

    Read here lot of time ago
    is stil in the specs ?
  11. User Interface - JDNC[ Go to top ]

    Don't quote me on this, but I believe most of the Swing stuff is going to come through the JDNC project on java.net. In addition to the main aim of JDNC (to cut much of the tedium from creating front-ends to typical enterprise apps), it also has enhanced and new widgets.

  12. I hope the guys from Sun actually read all these posts in serverside.com and take some feedback. :-)

    Despite years of yearning from the community, sun seems to do nothing BIG in the Enterprise Desktop area.
  13. Isolates[ Go to top ]

    Sun should avoid a version 6 release until they get Isolates in there. To me, and many others, this would warrant a new version release.

    Looking at my desktop while I write this I have 3 java applications and 1 java application server running. Each has its own instance of the JVM. So, despite one being rather trivial, they soak up the lions share of my computers memory.

    Java on the desktop will remain doomed until this is resolved. PLEASE PLEASE PLEASE get this done.
  14. Isolates[ Go to top ]

    They have a long way to go before they can do that. The time to collect garbage is at least O(x^2) where x is the number of objects inside the JVM. Today you get garbage collection down times of a second or more even with the low pause garbage collectors. If you use one big JVM with your three applications you might get downtimes of multiple seconds. If you use e.g. Netbeans on a slow machine the editor jumps like a frog when garbage collecting. I read an IBM article about a machine with lots of memory collecting garbage for 8 minutes. Keeping your application responsive (200ms) is nearly impossible with big caches. I would always use different JVMs for different applications on big servers.
  15. GC, Isolates[ Go to top ]

    The time to collect garbage is at least O(x^2) where x is the number of objects inside the JVM.

    Generational scavenging ensures that reclamation doesn't involve the entire heap.
    I would always use different JVMs for different applications on big servers.

    Your practice might be sensible for administrative reasons. But surely throughput suffers while the JVMs compete for residency in RAM.
  16. Wish they would do something about:
    -Poor font rendering quality in Swing - no smoothing from OS settings.
    -The snail's pace of work being done on the Win L&F (that's the perception based on Tiger).
    etc. etc.