JDK 1.5 Beta and Public Review Specification is out

Discussions

News: JDK 1.5 Beta and Public Review Specification is out

Bookmark and Share Get thread feed

  1. JDK 1.5 Beta and Public Review Specification is out (47 messages)

    The official beta 1 of the J2SE 1.5 (Tiger) release is now available for download, as is the public review draft of the Tiger Release Contents specification (JSR 176). J2SE 1.5 is scheduled to be released in the Summer of 2004; the spec defines what features (out of a long list of high, medium and low priority) will be included in the summer release.

    Links:
    JDK 1.5 BETA 1 SDK Download.
    JDK 1.5 Home page.
    Specification Public Review Draft Download.
    JSR 176 Homepage.

    The spec includes a significant number of "target of opportunity" features, which the group hopes to get into the summer release if there is time. Some of notable ones for enterprise developers include:
    -Add a method to generate a UUID (Universal Unique Identifier)
    -support using dynamic proxies as RMI stubs
    -Support for standard LDAP controls
    -API to test reachability of a host
    -Improve Security Access and Control
    -HTTP client: Improve cookie support
    -HTTP client: Improve proxy server configuration and

    Which would you definitly like to see?
    Reply to this

    Threaded Messages (47)

  2. How about quick adoption?[ Go to top ]

    Which would you definitly like to see?


    What I would like to see is a quick adoption of the 1.5 platform. These changes are great and quite significant, but they will be completely wasted if they aren't used by _EVERYBODY_ as soon as possible (post beta of course).

    Seriously, we can't even code to JDK 1.4 safely yet due to a lack of adoption by key industry players and tons of major corporate customers. It's been 2 years! I don't want to wait until 2006/2007 before I can use JDK 1.5 with any confidence.

    I appreciate the usual concerns...cost, stability, blah blah (okay, maybe I don't). Perhaps JDK 1.4 wasn't worth it, but I think this one will be.

    LET'S UPGRADE PEOPLE! :-)

    Cheers,
    Clinton
    Reply to this Reply to original

  3. How about quick adoption?[ Go to top ]

    This is realy a great set of features!

    We can only hope that stability and performance would be as great as features and that stability and performance improvements would retain the same level as from 1.2 to 1.3 and from 1.3 to 1.4.

    >> Perhaps JDK 1.4 wasn't worth it.
    JDK 1.4 is certanly worth it, if not for anything else, then for performance of JDK 1.4.2

    Mileta
    Reply to this Reply to original

  4. Summary of new language features[ Go to top ]

    Does anybody know of a good summary with examples of the new language features?

    The JSR:s are a bit "wordy", having 90 pages to describe stuff that someone else could probably summarize (better) in a couple of pages...
    Reply to this Reply to original

  5. Summary of new language features[ Go to top ]

    In the JDK 1.5 Home page, you have a link to J2SE 1.5 in a nutshell, with screenshot of the new Theme (Ocean)

    http://java.sun.com/developer/technicalArticles/releases/j2se15/

    enjoy it
    Reply to this Reply to original

  6. Nice PDF[ Go to top ]

    At http://www.javasig.com/Archive/lectures/JavaSIG-Tiger.pdf

    Enjoy!
    Reply to this Reply to original

  7. Cool![ Go to top ]

    Heyyyyy!! This looks cool! JMX and all..

    Maybe by 2006 I will actually be able to use this also :)

    //ras
    Reply to this Reply to original

  8. Code samples highlighting the new features.[ Go to top ]

    zamples.com have a nice list of samples you can try online.

    http://zamples.com/JspExplorer/samples/samplesJDK1_5.html
    Reply to this Reply to original

  9. Summary of new language features[ Go to top ]

    http://java.sun.com/features/2003/05/bloch_qa.html
    Reply to this Reply to original

  10. How about quick adoption?[ Go to top ]

    Well, meta data is the death of xdoclet and a lot of other javadoc tools.

    Bravo!
    Reply to this Reply to original

  11. How about quick adoption?[ Go to top ]

    Not really. Metadata is now a standard way to markup your code so tools like xdoclet can do something with it. I bet that after JDK 1.5 goes gold xdoclet will be changed to use standard metadata attributes to do it's work instead of relying on xjavadoc.
    Reply to this Reply to original

  12. xdoclet and JSR 175[ Go to top ]

    Not really. Metadata is now a standard way to markup your code so tools like xdoclet can do something with it. I bet that after JDK 1.5 goes gold xdoclet will be changed to use standard metadata attributes to do it's work instead of relying on xjavadoc.


    This seems logical, but it's likely that it won't happen, or will take a long time if it does. Xdoclet is often used to to generate some source files that are necessary to make other source files compile (e.g. EJB interfaces, data objects). To allow this, Xdoclet implements a cleverly mangled Java parser of its own, with very relaxed parsing rules, which can extract metadata and basic structural information from classes that won't actually compile.

    The APIs for extracting Java Metadata all operate on compiled classes. Xdoclet certainly won't be able to use those APIs: to use them you need compiled classes, but to make your classes compile, you might need Xdoclet! To use JSR-175, Xdoclet would once again have to implement their own relaxed parser ... but this time, they have to deal with the much richer structure of Java metadata -- much harder to parse than key=value pairs in Javadoc tags. In any case, they certainly don't get much for free with JSR 175.

    I asked Josh Bloch about this, and he basically said that making the spec require that metadata be parsable even if the class doesn't compile would just open too large a can of worms for that JSR to deal with reasonably. And I definitely agree with him. But it does place a large burden on the Xdoclet developers.....
    Reply to this Reply to original

  13. Tasty, but it's going to be awhile[ Go to top ]

    This is really a demarcation point for Java, and its much more widespread than before.

    It's a beta, but I bet that my company won't be able to use any of these features for at least a year, if not more.

    And the big threat is simply that the community needs to move forward almost in lock step. I fear that something like JBoss will want to move forward with full vigor to 1.5, and thereby want to drag things like Hibernate with it.

    But for those who don't use JBoss and are tied to, perhaps, more conservative vendors, those users may get left in a lurch when a key sub-system moves forward.

    Much of the differences between 1.2, 1.3, and 1.4 were mostly in the class libraries, and potentialy downgradeable (like adding the Collections framework to 1.2). In fact, I don't know that I've even see the assert keyword out in the wild on a released project, for fear of breaking 1.3 environs.

    While forgoing assert is a small price to pay for compatability, dumping some of the new features in 1.5 may be less of an option for users.

    So, we shall see...
    Reply to this Reply to original

  14. What about JDO[ Go to top ]

    Are there are any plans to have JDO in there or next version?
    JDO 2.0 is coming this year.
    Reply to this Reply to original

  15. Imroved usability on the client side.[ Go to top ]

    This has been discussed many times before...

    1. Responsive and memory-friendly UI (Swing, SWT -- I don't care). SWT seems to be a real alternative to Swing in this way, so it would be cool to include it into JDK. Though not perfect, this solution is a real and viable alternative to Swing to build GUI in Java that brings satisfaction rather than irritation.

    2. When loading a Java applet, I would like to see a nice splash screen with a progress bar, something like what you can see when loading a Macromedia flash file (take a look at http://www.lamborghini.com, for example), instead of that stupid taciturn gray box.
    Reply to this Reply to original

  16. JDK 1.5 Beta and Public Review Specification is out[ Go to top ]

    And the most interesting feature is...

    http://java.sun.com/j2se/1.5.0/docs/guide/vm/class-data-sharing.html
    Reply to this Reply to original

  17. Improve (or replace) standard Swing Look-and-Feels[ Go to top ]

    The standard Swing Look-and-Feels (Windows, Metal) are far from being perfect. WindowsLookAndFeel does remind the native Windows Look and Feel, but it has to be polished - it still looks like alpha.

    The best look-and-feels I have ever seen are those from http://www.jgoodies.com. This is what Swing should look like. Sun must incorporate JGoodies into JDK 1.5(mayble refactor package names, if necessary). Whenever I use applets, I use the JGoodies look-and-feels. In this case, however, I need to download them in a separate .jar file (150-200k), which is quite a lot for an applet.

    Usability maniac.
    Reply to this Reply to original

  18. Improve (or replace) standard Swing Look-and-Feels[ Go to top ]

    The best look-and-feels I have ever seen are those from http://www.jgoodies.com. This is what Swing should look like. Sun must incorporate JGoodies into JDK 1.5(mayble refactor package names, if necessary). Whenever I use applets, I use the JGoodies look-and-feels. In this case, however, I need to download them in a separate .jar file (150-200k), which is quite a lot for an applet.

    If you like what JGoodies offers here then perhaps the last thing you want is for them to be included in the JDK. Not being there allows Karsten a certain freedom (and control) in incrementally improving them quickly as needed. So as far as I am concerned, the answer to whether or not they should be included in the JDK (aside from Karsten's own concerns), is not as simple as it may sound. I would personally vote against including them. Although if the standard JDK LNFs don't cut the mustard, then perhaps including a small subset of third party LNFs (as long as they don't stifle further development of those particular LNFs) would be wise (in an ideal world, that is).

    Thoughts?
    Reply to this Reply to original

  19. Improve (or replace) standard Swing Look-and-Feels[ Go to top ]

    C'mon, Bill!

    I DO disagree with you. The main reason I would like to see them in the JDK, like I said, is because I use them in applets often. Unfortunately, this increases the size of my applets (or the number of external .jars that my applet requires to run). Once this .jar in the JDK, my applet gets smaller and requires less external libraries. In many cases my applets are smaller than the l&f library itself...

    The JGoodies library is pretty stable and usable IMHO, and is much better than standard look&feels. By having done so, SUNW could have easily made applets much more attractive, and thus customers and, hopefully, Karsten, happier.

    Sergei Batiuk.
    Reply to this Reply to original

  20. Swing Look-and-Feels[ Go to top ]

    Hi Sergei,

    I don't think the Swing Metal look and feel is that bad. A few tweaks in the color scheme (theme) and color/border defaults can make a difference.

    JDBInsight 2.1 uses the metal look and feel but its elegance is derived from standard graphic design principals which would work across any toolkit or platform. Look and feels are only part of the solution.

    Check out: http://www.jinspired.com/products/jdbinsight/transflash.html

    The problem is not necessarily L&F's but whether programmers (and not designers) be the persons deciding the user interaction and visual style.

    I just downloaded 1.5 and was pleased to see that JDBInsight's visual design style is the same across 1.4 and 1.5.

    Kind regards,

    William Louth
    JDBInsight Product Architect

    "Tune with Ease"
    http://www.jinspired.com
    Reply to this Reply to original

  21. JDK 1.5 Beta and Public Review Specification is out[ Go to top ]

    [quote]
    Lastly, after seven years, we've made jFrame.add equivalent to jFrame.getContentPane().add().
    [/quote]

    Somebody has managed to keep a sense of humour.. =)

    http://java.sun.com/j2se/1.5.0/docs/relnotes/features.html#swing
    Reply to this Reply to original

  22. Generics[ Go to top ]

    Anyone know if if javac with source 1.5 and 1.4 targets lets generics code run on 1.4 JDKS?
    Reply to this Reply to original

  23. 1.5[ Go to top ]

    Yippppeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee. What a day :-) Thanks Sun engineers. Don't let yourselves be discouraged by the whiners and complainers.
    Reply to this Reply to original

  24. RE: Generics[ Go to top ]

    Anyone know if if javac with source 1.5 and 1.4 targets lets generics code run on 1.4 JDKS?


    Nope, just tried it.

    jgerard@DEVWORK002 ~/java/test15
    $ ~/j15bin/javac -source 1.5 -target 1.4 GenericsTest.java
    javac: source release 1.5 requires target release 1.5
    Reply to this Reply to original

  25. How about versioning Java3[ Go to top ]

    Honestly,

    these changes are very deep in the language and would normally justify a new major release. Java - used to be simple, straightforward etc. is going to be very different with generics, autoboxing etc. Also, adding monitoring to the JVM and improved GC are massive changes as well. I can't say I like all of the features, in particular generics have failed miserably most of the time in custom development projects. I would like a feature in the compiler that strips down the set of features of the language you can use - now that would be cool..

    Karl
    Reply to this Reply to original

  26. A Quantum Leap[ Go to top ]

    For the first time I can say I appreciate C# for the simple reason it lit a fire under Sun to radically enhance Java. Has there every been so many added features to a release compared to 1.5?
    Besides the obvious additions of auto boxing, enhanced for loops, generics, varargs - which enable printf functionality (see java.util.Formatter), and the memory mapped shared archive for faster startup and less memory usage for muliple JVMs:

    MetaData - The other AOP (Attribute Orientated Programming). With this we will likely see POJOs be remoted, persisted, marshalled to XML (and ?) via meta tags.

    Class File Transformation (Instrumentation: http://java.sun.com/j2se/1.5.0/docs/api/java/lang/instrument/package-summary.html). A hook for AOP implementations?

    Management, including JMX 1.2 and JMX Remoting 1.0 with various JVM related MBeans
    (http://java.sun.com/j2se/1.5.0/docs/relnotes/features.html#jmx). A built in MBeanServer and a cmd line switch to enable remote access via a RMIConnector (see $JAVA_HOME/jre/lib/management).

    JDK 1.5 will make Java dominant for at least another 5 years.
    Reply to this Reply to original

  27. A Quantum Leap[ Go to top ]

    I'm amazed to see that Java now has sizeof!
    Reply to this Reply to original

  28. swing or swt?[ Go to top ]

    Thanks sun for this great job. But they can even be better.

    All of us (almost all) believe that swing API is great but it really sticks to every thing in desktop and SWT brings performance advantage that we need (I can’t see any thing more).

    So in a closer relation between sun and eclipse’s SWT team (perhaps a free eclipse) what will happen if both sides accept swing technology (Swing API) but go in SWT way for having better performance?

    This will eliminate common problems in j2se world and certainly will be good for any one and additionally will remove common problems about eclipse plug in technology.

    I think there is enough time (until releasing stable version of tiger) for this change and making java world united.
    Reply to this Reply to original

  29. swing or swt?[ Go to top ]

    Quoting from http://java.sun.com/developer/technicalArticles/releases/j2se15/#dc

    "Linux and Solaris users who have the latest OpenGL drivers and select graphic cards can get native hardware acceleration from Java2D using the following runtime property:

    java -Dsun.java2d.opengl=true -jar Java2D."

    Did anybody tried this? Could this mean a real Swing perf boost?

    Regards,
    Horia
    Reply to this Reply to original

  30. OpenGL, swing or swt?[ Go to top ]

    "Linux and Solaris users who have the latest OpenGL drivers and select graphic cards can get native hardware acceleration from Java2D using the following runtime property: java -Dsun.java2d.opengl=true -jar Java2D."

    Did anybody tried this? Could this mean a real Swing perf boost?

    I doubt OpenGL noticeably accelerates Swing, since most stock Swing painting isn't Java2D. Maybe Apache's Batik would benefit.
    Reply to this Reply to original

  31. No Compiler API?[ Go to top ]

    Earlier versions of the Tiger JSR listed JSR-199. Now the specification says something about JSR-199 being unnessarry, and that com.sun.tools.javac.Main just needs to be documented.

    What the heck does this mean? Do we get a standard java.tools.compiler or not?

    I'm not exactly sure how the JSP implementors are even doing this right now... The best thing I can think of is to spawn a process everytime you need a compile. Is that the correct way to do it right now?
    Reply to this Reply to original

  32. 1.5 and Mac OS X?[ Go to top ]

    Does anybody know what Apple's plans are around 1.5? Will we see a concurrent or near-concurrent release of 1.5 from Sun and Apple (as Apple has said they're aiming for)? Or will we be waiting as long as we did for 1.3? Any word on the first 1.5 beta on Mac?
    Reply to this Reply to original

  33. Correcting my own typo[ Go to top ]

    Or will we be waiting as long as we did for 1.3?


    Sorry, that was a typo -- it was *1.4*, not 1.3, that Mac users ended up waiting on for ages and ages. (TSS really needs a preview button!)
    Reply to this Reply to original

  34. Why not static printf and println[ Go to top ]

    What not add static printf and println function in java.lang.System
    With static import, you can import java.lang.System.out, but you still have to use out.println. if there is a static println in System than we can use println() directly. this we make code more like C. More simple, less code type. ^_^
    Reply to this Reply to original

  35. java.util.logging enhancements?[ Go to top ]

    Does J2SE 1.5 contain any significant enhancements to java.util.logging ?
    Reply to this Reply to original

  36. java.util.logging enhancements?[ Go to top ]

    Looks like they didn't.
    That's too bad bc java.util.logging should be like log4j.
    I think it would be an exellent idea to standardize it since its log4j is used
    almost everywhere and is cleaner that java.util.logging
    Reply to this Reply to original

  37. java.util.logging enhancements?[ Go to top ]

    That's too bad bc java.util.logging should be like log4j.

    > I think it would be an exellent idea to standardize it since its log4j is used
    > almost everywhere and is cleaner that java.util.logging

    The fact that Sun's logging implementation sucks and log4j is a bloated monster forced me to write yeat another logging system for the app I'm working on.
    Reply to this Reply to original

  38. JDK 1.5 Beta and Public Review Specification is out[ Go to top ]

    D:\temp\jdk15Test>more < GTest.java
    import java.util.*;
    class GTest {
        public static void main(String[] agrv) {
            ArrayList<Integer> list = new ArrayList<Integer>();
            list.add(0, new Integer(42));
            int total = list.get(0).intValue();


        }
    }

    D:\temp\jdk15>java -version
    java version "1.5.0-beta"
    Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0-beta-b32c)
    Java HotSpot(TM) Client VM (build 1.5.0-beta-b32c, mixed mode)
    D:\temp\jdk15Test>javac GTest.java
    GTest.java:4: '(' or '[' expected
            ArrayList<Integer> list = new ArrayList<Integer>();
                                                    ^
    1 error
    ??????
    Reply to this Reply to original

  39. JDK 1.5 Beta and Public Review Specification is out[ Go to top ]

    <snip>

    > D:\temp\jdk15Test>javac GTest.java
    > GTest.java:4: '(' or '[' expected
    > ArrayList<Integer> list = new ArrayList<Integer>();
    > ^
    > 1 error
    > ??????


    RTFM ;)

    http://java.sun.com/j2se/1.5.0/relnotes.html#javac
    ===============
    The -source 1.5 option is required for compiling with the new language features.
    The -target 1.4 option is the default, which generates class files that are compatible with 1.4 or 1.5 VMs. A new option -target 1.5 is available for compatibility only with 1.5 VMs.
    ===============

    Also, your source code doesn't need the call to intValue(). Autoboxing/unboxing handles the conversion for you. Autoboxing also allows you to add the primitives directly, doing the wrapping for you in the background. Add in the enhanced for loop and you can have something like this:

    import java.util.*;

    public class Test {
    public static void main(String[] args) {
    ArrayList<Integer> list = new ArrayList<Integer>();
    list.add(42);
    list.add(37);
    int total = 0;
    for (int i : list) {
    total += i;
    }
    System.out.println(total);
    }
    }

    >javac -source 1.5 Test.java

    >java Test

    79

    Jim S.
    Reply to this Reply to original

  40. Its getting too complicated[ Go to top ]

    A lot of new stuff added to 1.5 is great, but I am concerned that some of the new features are making the language unneccessarily complicated. Generics principly come to mind here.

    One of the great features of Java is that is simple language to learn. I worry in JDK 1.5 you are going to be able to write code which is difficult understand.

    The reason Java was initially so successful, was that it was very easier to learn. Every new feature that is added will increase Java's learning curve. It should also be noted that complexity compounds itself.
    Reply to this Reply to original

  41. This Rocks[ Go to top ]

    I love this. Absolutely superb. The only thing I think Java needs is someway to compile to native code. (without breaking cross platform) If you could compile an app to class files like normal, and then be able to take the extra step and compile the class files to native. Then we could finally start killing all that COBOL code we run, programming games and OS's with Java.
    Reply to this Reply to original

  42. typedefs[ Go to top ]

    Is there an equivalent of C++ typedef? What I mean is that it is totally boring to type

       // Need a small working array just inside this method
       ArrayList<Integer> al = new ArrayList<Integer>();

    every time I need do use one. Compare it to something like

       // Allocate the object on the stack; will be promptly
       // and predictably removed. No memory fragmentation or

       ArrayListInt al(); // auto-var, allocated on the stack

    regards,
    --Val.
    Reply to this Reply to original

  43. typedefs[ Go to top ]

    Is there an equivalent of C++ typedef? What I mean is that it is totally boring to type


    public class ArrayListInt extends ArrayList<Integer> {
    }

    Thats it :)
    Reply to this Reply to original

  44. JDK 1.5 Beta and Public Review Specification is out[ Go to top ]

    Has anyone tried out swing apps? Any noticeable speed increases?
    Reply to this Reply to original

  45. Swing[ Go to top ]

    Has anyone tried out swing apps? Any noticeable speed increases?


    First time start still takes quite a long time. (IntelliJ IDEA is 25 sec if it's the first java app to run). Second time is faster as usual - 9 sec for IDEA with 1.4.2 and 8 sec for 1.5.0. The difference is that the second, different java app starts faster than it did with 1.4.2. I haven't measured the speed difference but it feels like that.

    Our server software seems to run ok with 1.5.0 beta. Small bmark/regressiontest suite (mostly XML parsing and database inserts/updates) run 29sec on 1.5.0 and 32sec on 1.4.2_03. The downside is that the 1.5.0's VM size showed 97.336 MB on -server -Xms64m -Xmx64m while the 1.4.2 managed to keep in 89,248 in same settings. This was on windows, so I'll run the same test on linux later to examine the memory consumption there. (BTW: the 3sec difference advantage could be due to the better? xerces parser in 1.5?)

    I think the memory consumption increase on windows platform can be explained with this snippet from http://java.sun.com/j2se/1.5.0/docs/guide/vm/class-data-sharing.html

    The footprint cost of new JVM instances has been reduced in two ways. First, a portion of the shared archive, currently between five and six megabytes, is mapped read-only and therefore shared among multiple JVM processes. Previously this data was replicated in each JVM instance. Second, less data is loaded out of the shared archive because the metadata for unused methods remains completely untouched as opposed to being created and processed during class loading. These savings allow more applications to be run concurrently on the same machine. However, on some operating systems (in particular, Windows), the perceived footprint of the process may increase, because a larger number of pages are being mapped in to the process's address space. Reducing footprint, including perceived footprint, remains a high priority and work is ongoing in this area.
    Reply to this Reply to original

  46. JDK 1.5 Beta and Public Review Specification is out[ Go to top ]

    java.util Interface Map<K,V> :

     boolean containsKey(Object key)
     boolean containsValue(Object value)

    What the hell Object doing here?
    Reply to this Reply to original

  47. Auto update of JRE?[ Go to top ]

    I heard somewhere about a year ago that there'd be an auto update feature for the JRE. This would be really useful for Web Start apps. Anyone know anything about it..?
    Reply to this Reply to original

  48. Live code examples for JDK 1.5[ Go to top ]

    Zamples, Inc., announced today the availability of a free preview of its Web-based interactive code examples for the Java 2 Standard Edition (J2SE™) 1.5 platform. Zamples® patent pending technology increases the productivity of software developers by providing a collaborative facility in which instructional materials, including executable code examples, can be accessed by developers over the Internet or within intranets using a standard browser-based client. Zamples' products allow software developers to share interactive discussions and examples of “excellent” code and coding techniques to build skills, enhance productivity, and teach complex interfaces and techniques. They can be readily adapted to virtually any language and platform API.

    “Our mission is to enable platform providers to accelerate the adoption rate of their programming languages and APIs,” said Michael Slinn, Zamples' founder and CTO. “Software developers learn best by doing. Our products provide them with software 'sandboxes' where they can find and experiment with software examples, and share information about their results with other community members. Our products enable software vendors, enterprise IT departments, system integrators, open source communities, educators, and online publishers to improve developer learning and productivity.”

    The free preview of Zamples technology for J2SE 1.5 is available on Zamples' web site (http://zamples.com/JspExplorer/samples/index.jsp). Code examples there can be modified, compiled and executed from a web browser, without users installing any code locally on their system. The Zamples' web site also offers online code examples written in Perl, Python and bash for the Amazon Web Services API, the Google Web Services API, the PayPal API and the Java Servlet™ API.

    Zamples server-based software is available now and is licensed either for installation on customer-owned servers or as an application service operated by Zamples. Application service pricing starts at $500 per month.

    ABOUT ZAMPLES, INC.
    Zamples, Inc. is a privately held corporation based in San Mateo, California.
    Reply to this Reply to original