Felipe Ortiz wrote up "Top Java SE 6 Features
," bringing up five features he likes most in Java 6, while Tim offers some opinions
on what Java 7 might want to consider - including addressing the possibility of handling XML directly in the language.
I was sold into scripting the JVM since back in the day when the only scripting option was Jython and BeanShell. Personally I would have preferred if Groovy was the default scripting language that came with Java SE 6. The good thing is that there are plenty of scripting languages that support the new Scripting Framework.
JDBC 4.0 Annotations
Java SE 6 introduced a BaseQuery interface that you can extend. You can sub-interface can then define get methods and associated annotation with the appropriate select prepared SQL statement. JDBC annotations are a new way of building Data Access Objects (DAO).
No More Class.forName for JDBC Driver
Java SE 6 does not require you to load the JDBC driver prior to creating a JDBC connection. This only works if the driver is packaged with a certain descriptor in the jar file. This only saves me one line of code, but I would never for the life of remember the name of driver I wanted. So in reality this saves on line of code and one Google search.
The system tray goes a long way in developing Java applications look and behave more like native applications. The system tray was part of the JDesktop Integration Components (JDIC). They system tray allows you to add a menu on the user desktop's user tray.
Java Compiler API
In the past I have had to compile Java source at runtime by invoking the the Main class for the javac command. The Java Compiler API provides a solid solution for compiling Java source files or just in-memory Java source.
I cannot stress how useful and powerful XML binding is. XML binding is basically object serialization using XML. With JAXB as part of the Java SE 6 you don't have to download additional jars and libraries.
What would your choices have been?
Tim's addressing two specific areas: property access, and XML's position in the language. On property accessors, he's apparently neutral but wants a clearer syntax:
... I understand the concern about having the dot operator be ambiguous, and the potential performance penalties that can occur, but I think those fears are being over played. To my thinking the cost of having two different member access operators is worse. Having bean->property and bean.getProperty() mean the same thing segments the development space. Some people will use one, and some people the other. If I'm using an IDE with content assist, then I have to know whether I'm looking for a method or a property before I start typing. If we really need to have a different syntax I'd prefer something like bean.getProperty() and bean.@property or bean.$property - something that makes it clear that the difference is in what sort of member you're accessing rather than what sort of operator you use to get it.
He reserves a little more energy for XML:
Please please please don't give XML special treatment in the language. If we've found that working with arbitrary dynamic object graphs is too difficult then find a way to support them, but please do not make it XML specific. XML is not that important. I've had multiple situations where I've wanted to dynamically access properties from object graphs - I'd love a neat syntax for it. Please don't make this a XML-only solution.
The Groovy programmers are probably nodding in agreement, looking at Groovy's concept of builders
, which support XML almost as afterthoughts.