Slashdot Mirror


Java2 SDK v. 1.4 Released

pangloss writes: "Yay: XML, built-in Perl-ish regex, jdbc 3.0, asserts, IPv6, lots of other goodies. Release notes and incompatibilities. And I think this means I can use my wheel-mouse in NetBeans without that extra module ;) Download it here." WilsonSD adds: "There are many cool new features including a New I/O package, an Assert Facility and enhanced performance." Some other random Java notes: O'Reilly has an essay about why you won't see any open source J2EE implementations, and Kodak has filed a patent-infringement claim against Sun regarding Java.

16 of 362 comments (clear)

  1. Summary of new features by LarsWestergren · · Score: 4, Informative

    A summary of all the new features is available here:
    http://java.sun.com/j2se/1.4/docs/relnotes/feature s.html

    Articles about the news APIs and how to use them available here:
    http://java.sun.com/j2se/1.4/articles.html

    --

    Being bitter is drinking poison and hoping someone else will die

  2. Re:Java2 ? by LarsWestergren · · Score: 4, Informative

    Hmm, if SDK v1.2 became "Java2", shouldn't v1.4 be called "Java4"? Oh I see, "Java2" was a "marketing trick" used in the tough year 1997 and the name has stuck.

    Perhaps,but remember that the change from 1.1 to 1.2 contained some major rehaul of APIs.

    In this 1.4 release Sun kept a carefully budgeted set of new features and emphasized quality and performance, like they said they would. You can expect more changes in 1.5 (codename Tiger) which is planned to come some time around the middle of 2003. If that will be Java3, who knows, they have just started working on it.

    --

    Being bitter is drinking poison and hoping someone else will die

  3. Security export rules by Aceticon · · Score: 4, Informative
    As usual the "import control restrictions" once again are in full force. From the release notes:

    Due to import control restrictions, the JCE jurisdiction policy files shipped with the Java 2 SDK, v 1.4 allow "strong" but limited cryptography to be used. An "unlimited" version of these files indicating no restrictions on cryptographic strengths is available.


    The JSSE implementation provided in this release includes strong cipher suites. However, due to U.S. export control restrictions, this release does not allow alternate "pluggable" SSL/TLS implementations to be used


    What seems even stranger now is that you cannot used "pluggable" implementations (in JSSE). Maybe the "nasty" europeans/asians/africans/martians would provide some unlimited strong cryptography pluggin otherwise???

    1. Re:Security export rules by JohnA · · Score: 5, Informative

      There is already a clean room, open source (BSD License) implementation of the JCE. It's called Cryptix, and simply put is one of the best libraries ever written for Java.

      I don't trust black box cryptography... especially when Sun goes the extra mile to obfuscate their default implementation of the JCE crypto modules.

  4. Re:My take on JDK 1.4 by mccalli · · Score: 4, Informative
    They did break some stuff with legacy code. If you ever named a class 'URI' your code will now fail to compile because they put this class in the java.net package which everyone imports anyway.

    Not really a 'breakage'. If you imported only what you needed (java.net.URL, java.net.Socket etc.) your code will continue to work. Only if you used the statement "import java.net.*" will it now fail, and that's down to the individual coder, not the JDK.

    Cheers,
    Ian

  5. Patent titles by jeti · · Score: 5, Informative

    The article says nothing about the nature of
    the supposedly infringed patents. Here's their
    titles:

    US05206951
    Integration of data between typed objects by mutual, direct invocation between object managers corresponding to object types

    US05421012
    Multitasking computer system for integrating the operation of different application programs which manipulate data objects of different types

    US05226161
    Integration of data between typed data structures by mutual direct invocation between data managers corresponding to data types

  6. Re:It's a big step up, but there is still distance by Wraithlyn · · Score: 4, Informative

    "I've been working on a server that takes a lot of connections in Java, and you can finally do it with the support of "select" in Java 1.4."

    I've been using NBIO (Non-Blocking IO) for quite some time, getting very good results. Been waiting for Java 1.4 to go final so I can start working with java.nio

    --
    "Mind, as manifested by the capacity to make choices, is to some extent present in every electron." -Freeman Dyson
  7. Java Secure Socket Extension by srichman · · Score: 5, Informative
    The Java Secure Socket Extension has provided TLS/SSL support to Java for a long time, and is now part of 1.4.

    ???

  8. new in 1.4: public Exception(Throwable cause) by _am99_ · · Score: 4, Informative

    My favorite thing about using 1.4 is code like this:

    public void methodA throws MyException {
    try { Driver d = Class.forName(driverClass).newInstance(); }
    catch (Exception ex) { throw new RuntimeException("problem loading driver"); }
    }

    can now be this:

    public void methodA throws MyException {
    try { Driver d = Class.forName(driverClass).newInstance(); }
    catch (Exception ex) { throw new RuntimeException("problem loading driver", ex); }
    }

    Notice the RuntimeException constructor now has the original exception passed to it. It can be retreived higher up the stack, and I believe is printed during a ex.printStackTrace(...). It lets you pass the root cause exception up the stack trace, while preserving the entire state, without having to declare it everywhere.

  9. Re:Open Source Java VM & class libraries by mlinksva · · Score: 5, Informative

    Look at the bottom of the classpath page for a list of open source VMs that work with classpath (a free core (i.e., java.* and a few others) class library). All works in progress. I expect that mono and/or portable.net will quickly outpace free java projects. The JDK is a case where the availability of good enough gratis software has seriously hampered the momentum of libre competition. Netscape 4.x is another such case.

  10. Re:Genericity? by srichman · · Score: 4, Informative

    1.5

  11. Ironic/NBIO by srichman · · Score: 5, Informative
    I used to write large-scale multithreaded network servers, where somthing like three to four hundred threads could be running at any given moment inside the server. Java's class library made this really quite easy, and it's syntax is pleasant enough to work with.
    It's kinda ironic that you should say this, since threads are the wrong way to write "large-scale" network servers, and since Java 1.4 finally gives us non-blocking IO APIs to implement things the right way. (The NBIO APIs in 1.4 are, incidentally, largely a product of the work of the fellow behind the second link I gave.)
  12. Re:My take on JDK 1.4 by Speare · · Score: 5, Informative

    They did break some stuff with legacy code. If you ever named a class 'URI' your code will now fail to compile because they put this class in the java.net package which everyone imports anyway.

    If you have a foo.bar.URI class, and the core has a java.net.URI class, you can still use yours.

    You can:

    1. specifically name the package at the usage (messy),
    2. specifically include only the java.net classes you want, one by one, rather than including java.net.* (inconvenient),
    3. or just clarify which URI class should be used in the imports specifically:
      • import foo.bar.*;
        import java.net.*;
        import foo.bar.URI; /* hides java.net.URI */

    Existing code does not need to be recompiled, since bytecode always explicitly names classes always, but existing code does potentially need to be fixed if recompiled, as the default results of the imports will change. This is a pretty small and common occurrence with a new API set.

    --
    [ .sig file not found ]
  13. Re:skeptical for the desktop by TheAJofOZ · · Score: 5, Informative
    Sun is like Microsoft - they make as many features as possible, worry about the bugs later and let hardware catch up to overcome their crippling defects caused by overzealous and misinformed OOD.

    Okay, I can't take this any more - Java is not slow or buggy and can produce applications that are indistinguishable from C/C++ applications. The proof of this is simple - rewind the clock back a year to MacWorld where WorldBook Encyclopedia was demoed as part of the keynote with everyone watching and they were all impressed. Months later I was informed by the "head Java dude" at Apple on his Australian tour that WorldBook is completely written in Java - but noone knew.

    Most people think that Java is slow, buggy and doesn't look platform native because they assume that anything that is fast, stable and looks and feels platform native wasn't written in Java. It's even cooler though, because the "write once, run everywhere" of Java actually works if you write good code). Sure there are some things that Java can't do that you need native code modules to handle but that facility is available.

    The worst thing is that young programmers are led to think that Sun's code is actually *good* which spreads their poor, inefficient form to the next generations.

    Java's not perfect, but I seriously don't think that it's Java that corrupts young programmers. You can write good code in almost any language - I see an awful lot of really bad Java code written by C programmers but I'm not about to claim that C is corrupting old programmers.

  14. Headless at last - bye bye XVfb by Taurine · · Score: 5, Informative

    My favourite new feature is that lightweight components can now be run in headless mode - see

    http://java.sun.com/j2se/1.4/docs/guide/awt/AWTC ha nges.html#headless

    You have to set a property to true:

    -Djava.awt.headless=true

    as a switch when running the VM for example. Then you can generate server-side graphics on Unix without having to run XVfb. This has been an annoyance for some time, as you had to have different deployment rules depending on your target OS, as NT always has a graphical environment taking up resources whether you want it or not, so it wasn't an issue there.

    The upshot is that you can now use java.awt.Image.BufferedImage as an image source in servlets that generate dynamic images, instead of java.awt.Frame, which always seemed wrong. It uses less resources too, as it doesn't have to do a context-switch to your X server to create images!
    Hey, there are lots of great new features in this new release, but that is the first one that made life easier for me.

  15. Re:My pet hates with Java by _underSCORE · · Score: 5, Informative

    I fail to see how a declaration "String str = null" is any safer than a declaration "String str".

    You've used this serveral times as an example. You're right, assigning a string to null is not safer than leaving it uninitialized. However, that just gets around the 'uninitialized variable' error from the compiler. You should initialize it with something meaningful, or at least "". That would be more safe, and would be what the compiler wants you to do. This error has saved my butt more times than I care to remember, so don't knock it.
    If you want to use variable arguments, pass in a vector or a list. There are ways to make java do what you want to do, they might not be like those in C or C++.

    --
    "This is not a company that appears to be bothered by ethical boundaries."
    Attorney General Mike Hatch on Microsoft