Java 6 and Java 7 language features


News: Java 6 and Java 7 language features

  1. Java 6 and Java 7 language features (5 messages)

    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. Felipe's list:
    Scripting 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. System Tray 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. XML Binding 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.

    Threaded Messages (5)

  2. Agreed[ Go to top ]

    Please please please don't give XML special treatment in the language.
    No kidding. Even .NET's LINQ isn't specific to XML. And what happens if lots of people decided they want JSON rather than XML? I also use Groovy, and I agree that I think they got it right on this one.
  3. My 2 cents[ Go to top ]

    I believe that closures and first-class XML citizens are bad ideas. I like most of the other Java7 proposed features though. Gili
  4. It's good to see all these features becoming part of the Java. Most of them have been available as separate downloads for a while.. Altogether this is a good strategy for Java to stay is shape.
  5. How about...[ Go to top ]

    A cool little Comp Sci concept called HereDocs...
  6. useless stuff ...[ Go to top ]

    "No More Class.forName for JDBC Driver". joking ??? what is the point in this ??? Are the java guys really losing their mind ? Everybody writing enterprise applications has thousands of lines in stupid getters and setters because nobody ever thought to a new property syntax/annotation and they are thinking to avoid (and i would like to know who is using it anymore) a couple of line for Class.forName ? there are so many bad things to work on and they think to the system tray ... it looks they are joining MS filosofy bah ...