Follow Slashdot blog updates by subscribing to our blog RSS feed

 



Forgot your password?
typodupeerror
×
Java Programming

Java 1.4.2 Released 74

peterwilm writes "Sun released Java 1.4.2 today. It includes many enhancements and changes among them the native look&feel for Win XP and GTK 2.0 as well as support for Itanium 2."
This discussion has been archived. No new comments can be posted.

Java 1.4.2 Released

Comments Filter:
  • well how fast is it?
    • Re:How fast is java? (Score:4, Interesting)

      by BrokenHalo ( 565198 ) on Friday June 27, 2003 @10:35AM (#6311622)
      I personally don't care how fast it is, if it cooperates smoothly with GTK2 then it's good enough for me.
    • by j3110 ( 193209 ) <samterrell @ g m a i l.com> on Friday June 27, 2003 @11:33AM (#6312150) Homepage
      You know, I'm usually the first man upset when people say "Java is slow" without evidence, but I think performance improvement is a valid question of any new product. It's even more of a question when the new release actually is about performance to a degree. So... I wonder who modded you flaimbait, and why.

      On topic though, I've noticed a lot of performance enhancements. If you don't load a GUI, you're program will start pretty much instantly, and will only take about 5M of RAM for a small program. GUI's will take 6M more just because. I'm sure a lot of the 6M is external to the VM and/or frame buffers.

      In any case, I'm happy that my programs keep getting faster without me having to touch them. Also, now they work on the Itanium2, I can put that in the marketing material. (All with no coding/work on my part.) Sometimes, you have to really appreciate the good sides of Java.
  • by brlewis ( 214632 ) on Friday June 27, 2003 @10:31AM (#6311588) Homepage
    From my POV, this looks like the most significant change:
    Optimizations have been made to the core libraries to reduce startup time. For a small command line application, startup time has been reduced by roughly thirty percent; for a small Swing application, by fifteen to twenty percent.
    • by melete ( 640855 ) on Friday June 27, 2003 @10:35AM (#6311619)

      Yeah, that's a HUGE improvement. But playing with the beta, the biggest speed enhancement seems to be in the networking code -- it's a lot cleaner, faster, and not nearly as buggy as 1.4.1
      • I just ran through some of the demoes -- I like! Much faster on loading.
      • by Anonymous Coward
        Garbage Collection is the enemy of NIO. You have to explicitly close everything now. And tell me why optional deterministic destruction in Java is considered a bad thing? Writing all this extra code to close stuff sucks.

        New I/O (NIO)

        The following changes have been made to java.nio functionality in J2SE 1.4.2.

        * The finalize methods of the primitive channel classes (SocketChannel, ServerSocketChannel, etc.) have been removed (4777499). Performance testing revealed that the presence of these m
        • by Anonymous Coward
          This helps explain some of the issues:
          http://developer.java.sun.com/developer/b ugParade/ bugs/4525842.html
        • yes being able to explicitly destroy on object would be nice.

          but in the mean time do you really want to use finalizers to close your sockets anyways? It might be a crutch but its basically equivalent to not closing them at all.

        • Sure, but since you've no real idea when GC's going to happen, you'd better close things anyway because otherwise you'll hit your per-process limit on the number of FD's. (You do have process accounting turned on, yes?) It's always been good style to use close() with I/O in Java, and the NIO mods just push this a tiny bit further. (Thank goodness for try{...}finally{...}!)
    • It still doesn't appear to be as fast as most scripting language interpreters. But a very good thing to improve on.

      Perhaps a memory resident component would be a better way to go, although I hate anything that saps CPU cycles. :)

      • That's because a large part of some scripting language libraries is native code and is kept as a shared library (to be faulted in as necessary).

        Java's libraries are mostly written in Java and they are loaded, verified and usually partly compiled each time. Since is not part of the "text" segment (it's probably in the heap), sharing requires using some shared memory facilities.

        I think it would be nice if there was a "javalib" utility that would load up the Java classes, compile them, and produce a

  • by scrytch ( 9198 ) <chuck@myrealbox.com> on Friday June 27, 2003 @11:13AM (#6311979)
    I found this "issue" a little mysterious:

    The Java HotSpot VM cannot expand its heap size if memory is completely allocated and no swap space is available.

  • Yesterday (Score:3, Interesting)

    by BoomerSooner ( 308737 ) on Friday June 27, 2003 @12:03PM (#6312454) Homepage Journal
    I downloaded it yesterday so I must have been lucky. I needed it for eclipse. BTW where the hell is good free online documentation on how the hell to use eclipse, swt, etc.?
  • I keep getting connection refused. How about you?
  • XP Look 'n Feel? (Score:4, Insightful)

    by digerata ( 516939 ) * on Friday June 27, 2003 @01:00PM (#6312981) Homepage
    Alright, I am a avid proponent of java. But come on guys, XP has been out for almost two year and they are just *now* releasing support for that look and feel?

    That's just one more reason why people are flocking to SWT over Swing.

    • You've GOT to be kidding. Look, if you think an LAF is reason enough to use one widget library over another, perhaps you should consider another language more to the taste of Windows programmers... Perhaps VB.NET?

      • Nope, I have to throw in a plug for SWT here too. The Java LAF's in Linux suck badly. Crappy font rendering, no anti-aliasing, totally non-native looking, etc. Eclipse, OTOH, looks completely native, and follows my GTK2 theme :)
    • WindowsLookAndFeel has been available for a long time, not too much different than XP LookAndFeel
  • by PD ( 9577 ) * <slashdotlinux@pdrap.org> on Friday June 27, 2003 @02:19PM (#6313777) Homepage Journal
    Would that be Java 1.4.2, or is it Java 2. Or is it Java 2 full speed? And when will SCO be suing the bastards?
  • by Photar ( 5491 )
    That seems like alot of improvements for such a smal point update.
    • Re:WOW (Score:3, Interesting)

      by Golthar ( 162696 )
      Yes a lot of these things were held off.
      Sun seems to be heading more toward the desktop these days, with improved start up time and less memory consumption.

      However, they tend not to make any large functionality changes between point releases
      • by Photar ( 5491 )
        On that note, I think java is a really neat technology. I'd like to see more of it. I just hope MS doesn't kill them with that .NET crap.
        • Re:WOW (Score:2, Interesting)

          by Golthar ( 162696 )
          I don't think they will.
          I for one have to still see stable version of .NET running on things like the mac, Sun hardware, HP UX, IBM Mainframes.

          Time will tell though, but I have a good feeling about Java, especialy since the last few releases
  • I literally just finished downloading the 2nd beta last night.
  • by Tetch ( 534754 ) on Saturday June 28, 2003 @05:52PM (#6321724) Journal
    Hmm. For a point release, the increase in (Windoze) download size - double - is quite astonishing.

    On my PC :

    j2re-1.4.0_01-windows-i586.exe - 9170 Kb
    j2re-1.4.1_01-windows-i586.exe - 7829 Kb
    j2re-1.4.2-windows-i586.exe - 14162 Kb

    Does anyone understand this ?
    In fact, does anyone know why the download size actually went down betwen 1.4.0 and 1.4.1 ? Not that I'm complaining about that :-) ... I just assumed the code got more efficient ... but by the same token, it just got a whole lot less efficient ... or bloated, or something. Maybe it's all those multiple environment look'n'feels.

    • by Anonymous Coward on Friday July 04, 2003 @06:49AM (#6366323)
      1.4.0 and 1.4.1 had their JREs split up into US English only and International versions. The sizes you give for the older versions are the US English only and thus smaller version.

      With 1.4.2 they seem to only offer the international version now, hence the increase.
  • I think the most interresting change ist this:

    These previously unimplemented JVMDI functions have been implemented:

    jvmdiError GetOwnedMonitorInfo(jthread thread, JVMDI_owned_monitor_info *infoPtr)

    jvmdiError GetCurrentContendedMonitor(jthread thread, jobject *monitorPtr)

    Does this mean monitor information is now reported correctly in profiler-dumps and via JPDA? That would be soooo great -- i'm waitng for that for 2 years now. Finding deadlocks using a trial-and-error aproach ist just a pa

"I'm a mean green mother from outer space" -- Audrey II, The Little Shop of Horrors

Working...