Discussions

News: Java 6 JSRs Pass

Bookmark and Share Get thread feed

  1. Java 6 JSRs Pass (10 messages)

    Java 6's component JSRs have passed, along with the Java 6 umbrella JSR, which solidifies the official release components and clears the way for Java 6 to be finalized and released. Important JSRs here include JDBC 4.0, the Compiler API, the scripting interface, and the common annotations. It's a good time to consider Java 6's future. With a new license potentially on its way, and Java 6's feature set getting finalized (along with working implementations of the feature set), Java 6 might be mature enough and open enough to have a broad impact on the industry. However, one has to consider the current installed base of older versions of Java, many of which are effectively immovable (still using 1.3 or older, or 'updated' to 1.4, for example.) What are your opinions of the Java 6 release? If you're planning on using it, what's your deployment environment? Do you see production environments updating any time soon? Why or why not?
    Reply to this

    Threaded Messages (10)

  2. Re: Java 6 JSRs Pass[ Go to top ]

    Using Java 6 will in most cases depend on support by the application server vendors and 3rd party API's. I for one would love to use the new features of Java 6 (currently we work with Java 5 in most cases) A simple reason for me is that Java 6 provides a global performance gain, which is always interesting. There are some new features that i could use but most of the features aren't realy interesting for my line of work.
    Reply to this Reply to original

  3. API-partitioning seems to be missing[ Go to top ]

    Unfortunately it seems that the API will grow again and the partioning will not be included.
    Reply to this Reply to original

  4. Re: API-partitioning seems to be missing[ Go to top ]

    That's something that i'm also missing. They put a lot of new API 'parts' in there but i'm sometimes questioning why they add it to the base of Java and not as some sort of module.
    Reply to this Reply to original

  5. Re: API-partitioning seems to be missing[ Go to top ]

    Unfortunately it seems that the API will grow again and the partioning will not be included.
    An honest question - what problem would partitioning of the JRE solve? The Java 6 beta JRE is 15MB for Windows. That is no more than a few minutes download on my broadband connection. Look at the alternatives - JRE split into a series of modules, any of which may have to be download by an end user separately from the JRE core in order to run a specific Java application. The modules may have mutual dependencies and version control will be important. What matters is not size of API, but convenience of distributing or downloading and installing the JRE. At 15MB, I really don't think this is a problem, especially considering the alternative.
    Reply to this Reply to original

  6. Re: API-partitioning seems to be missing[ Go to top ]

    An honest question - what problem would partitioning of the JRE solve?
    Well there are some things that should never be part of the JSDK ... Derby for example, but in general I agree that modularity isnt *currently* an issue. Splitting the libraries from the JVM would be worthwhile. Also having real deprecation of outdated or just plain badly implemented methods/classes. The current luddite "we'll mark that as deprecated even though we havent got the guts to remove it" attitude is a joke. Having the courage to even remove things deprecated in JDK 1.3 or earlier (which will soon be no longer supported anyway) has to be the first step.
    Reply to this Reply to original

  7. Re: API-partitioning seems to be missing[ Go to top ]

    An honest question - what problem would partitioning of the JRE solve?

    Well there are some things that should never be part of the JSDK ... Derby for example, but in general I agree that modularity isnt *currently* an issue. Splitting the libraries from the JVM would be worthwhile. Also having real deprecation of outdated or just plain badly implemented methods/classes. The current luddite "we'll mark that as deprecated even though we havent got the guts to remove it" attitude is a joke. Having the courage to even remove things deprecated in JDK 1.3 or earlier (which will soon be no longer supported anyway) has to be the first step.
    I still don't see what actual problems this is supposed to solve. Why split off libraries? What is the point of removing deprecated methods? Having them still there is not a joke for anyone still running old binaries - people are still running code compiled for Java 1.3. There is no point about taking a courageous step if there are no current issues that taking that step will deal with. Also, why should the content of the JDK be any problem? Surely size is only really important for the JRE. So, again, my question is... what are the current problems with the JDK/JRE that require such actions?
    Reply to this Reply to original

  8. Re: API-partitioning seems to be missing[ Go to top ]

    I still don't see what actual problems this is supposed to solve. What is the point of removing deprecated methods?
    You might think that looking at the javadocs for java.util.Date is all lovely when you see 90% of the methods deprecated but the vast majority dont. It's seen as "clutter" and unnecessary baggage. It's additionally the cause for additional testing overhead ... presumably the JDKs run unit tests. So JDK providers have to maintain methods that were seen as needless 8 years ago. Removal removes clutter. It focuses attention on the methods that people are *supposed* to be using. If a class was immediately (next JDK release) seen as not a good idea then it is currently left in, and has to be maintained, and open to use and abuse. Removal of deprecated methods/classes doesnt mean i'd be in favour of removal of what some see as "minority interest" parts of the JDK (retaining some magical 20% most used ... which is impossible to define anyway). Having a large API is a good thing and provides the power of the language. Hacking off cruft (removing deprecated classes/methods) does nothing to weaken the language, and in fact strengthens it because people can be more focussed on the best way of using it.
    Reply to this Reply to original

  9. Re: API-partitioning seems to be missing[ Go to top ]

    I still don't see what actual problems this is supposed to solve. What is the point of removing deprecated methods?

    You might think that looking at the javadocs for java.util.Date is all lovely when you see 90% of the methods deprecated but the vast majority dont. It's seen as "clutter" and unnecessary baggage. It's additionally the cause for additional testing overhead ... presumably the JDKs run unit tests. So JDK providers have to maintain methods that were seen as needless 8 years ago. Removal removes clutter. It focuses attention on the methods that people are *supposed* to be using. If a class was immediately (next JDK release) seen as not a good idea then it is currently left in, and has to be maintained, and open to use and abuse.

    Removal of deprecated methods/classes doesnt mean i'd be in favour of removal of what some see as "minority interest" parts of the JDK (retaining some magical 20% most used ... which is impossible to define anyway). Having a large API is a good thing and provides the power of the language.

    Hacking off cruft (removing deprecated classes/methods) does nothing to weaken the language, and in fact strengthens it because people can be more focussed on the best way of using it.
    Perhaps, but I still don't see this as anything of great importance to the user of the JDK or JRE. I mean, if you want to be focussed on the best way, just don't use deprecated methods! My feeling about this is very much to leave things alone; Java has an outstanding reputation for backwards compatibility - it would be a shame to break it just for this....
    Reply to this Reply to original

  10. java.util.logging[ Go to top ]

    Are there any enhancements in the Java Logging API?
    Reply to this Reply to original

  11. logging enhancement[ Go to top ]

    Give slf4j a try: http://www.slf4j.org It's meant as a replacement for commons-logging and is marvelous together with logback (<- meant as a replacement for log4j). It's made by the guys responsible for log4j and addresses many of it's shortcomings - i.e. parametrized logging strings are only constructed IF they are really logged (rendering .isDebugEnabled() obsolete :D). Check it out, I'm pretty happy with it ;)
    Reply to this Reply to original