Java 7 Language Changes?


Looks like Joe Darcy has opened the floodgates for new language proposals in Java 7. He’s proposed an OpenJDK project to manage the process and he’ll be leading the process.

It should be interesting to see which language proposals are seeded by Sun. There was a set of small language changes jointly proposed by the BeJUG and SouJava user groups by Google (sorry, the user group proposal was the closures one) in November 2007 that specified:

It’s not clear what, if anything, happened to the original JSR proposal – it was never accepted and assigned a number to my knowledge. But I assume these proposals are potential choices as they came out of some Sun / Google folks.

Language support for BigDecimal has also been bandied about but Neal Gafter has said before that it cannot be implemented while supporting backwards compatibility so I don’t think that’s an option.

I’m also assuming that the word “small” used in this project indicates things like closures and property support are out of bounds, at least for consideration in this project.


16 Responses to “Java 7 Language Changes?”
  1. Giovanni says:

    These language changes sound terrible. Enum comparison and string-switch sound harmless, but all the others seem like big steps in the wrong direction: goofy language additions that help only very niche use cases.

    Other JDK7 improvements sound awesome: Joda-based Date/Time API and NIO2 look great. Can’t wait to hear more from Jigsaw and other enhancements.

  2. Mike Duigou says:

    I’d really like to see a loosening on the restriction of calling a super/this constructor as the first statement of a constructor. I can understand not allowing access to fields and non-static methods but it’s frequently inconvenient to not even be able to declare local variables or do calculations on the constructor parameters before having to call the other constructor. Yes, there are hacky workarounds to the current restrictions but the restrictions could be loosened without breaking bytecode compatibility.

  3. Talden says:

    I’ll second Mike Duigou’s suggestions about relaxing rules on super constructor invocation. That would be a nice convenience… Fields, methods and other constructors should be out of bounds but local analysis and manipulation of arguments shouldn’t need to be.

    I’ll take items 1, 2 and 6 as well.

    My faith in java’s forward momentum has all but evaporated… Just getting a proposal for this pissy little list hardly seems worth waiting until halfway through ’09 for.

    Hopefully Py3k will succeed showing that compatibility breaks can be worthwhile, can be weathered by the industry and that the costs can be minimised with tool assistance. Maybe then Sun might let Java27 trim some fat…

    or succ(java) == ?…

  4. Do you know the status on the liklihood that tail call optimization will make it into Java 7?

  5. Dave Feltenberger says:

    Why on earth aren’t the Java folks jumping on real enhancements to the language — e.g. closures — but instead doing simple little syntax candy things like “improved catch syntax”. Sure, it’ll be nice to catch multiple exceptions explicitly in a single block, but while we’re twiddling our thumbs doing silly things like that, the C#.NET people at Microsoft are starting to really pull away. They quite simply have a more powerful language, point blank.

  6. Alex says:

    @Giovanni: Project Jigsaw is post-Java 7.

    @Mike, @Talden – I don’t think this is possible due to how objects are constructed in an inheritance hierarchy.

    @Mark: I don’t know. That would be under the guise of JSR 292 though (as it is a JVM change) not this project about Java the language. A good place to ask would be the jvm-languages Google group.

  7. Frz says:

    Out of these I believe Type inference, Chained invocation and Improved catch/rethrow are useful. The Other 3 only create inconsistent behaviour.

    While I can still understand why String switching is a good thing will this also mean that comparing strings using == will get us equality behaviour? That would be the only way to more or less stay consistent.

    I don’t see a point in Extension methods at all, why is it so hard to do sort(list)? If extension methods mean I can call the same methods in different classes on the same type that do different things I’m against it.

    Enum comparison is probably worse. From everything I’ve read I’ve never seen the proposal that compared enums have to implement Comparable?! Which would mean that
    enum Colors { RED, BLUE, GREEN } -> RED … and equals (I realize that equals is not nescessarily the same as compareTo returning 0 but in most cases it should be).

    I realize that this is probably the wrong place to rant but I had to get it off my chest ;)

  8. Itay Maman says:

    It seems that every language design discussion evolve around the issue of syntax: How many features are we willing to introduce to reduce the amount of typing by X percent. (Where the exact value of X is a mere speculation…).

    Although many people see conciseness as the most important asepct of a language, I am not sure that string switch, for example, will improve conciseness to a degree that will really matter to a programmer when she chooses a language for her next project.

    The two features that seem to be making a huge difference across the full board of domains/technologies are modules and closures (and maybe Annotations on Java Types). They can really change the way people structure their code. Other features will have nearly zero impact.

    My personal opinion, of course.

  9. Frz says:

    Hm for some reason (probably using greater/lesser than symbols) some of my last comment got lost somewhere.
    The “…” part after “enum Colors { RED, BLUE, GREEN } -”
    should be:
    RED {lt} GREEN == true – which does not make sense. If the enums have to implement Comparable and can be compared using the gt/lt operators why restrict it to enums? I’d expect to be able to compare every Comparable using the operators when I can do so with enums.
    (the part after this in my original comment means to refer to compareTo returning 0 on equality but there would be no appropiate operator in java to map the check for 0 therefore .equals would have to be used which should be true when compareTo returns 0 in most cases)

    Sorry for the confusion I’ll be more careful with html characters next time.

  10. Alex says:

    @Frz: With string switching, I’m sure the intention is not to change the semantics of string equality so I’m assuming a string switch would be based on .equals(), which is a fudge in the semantics but one that I think people would intuitively understand. Of course, any String literals are interned and guaranteed to be an == match. It’s a good question in any case.

    I think extension methods are only beneficial if you see them as a way to retroactively add functionality to existing classes without breaking backwards compatibility. In particular, it’s been suggested that in tandem with closures, these could be used to retroactively add closure support to the collection library. Having written some examples for talks and stuff with them, I find they definitely make it more confusing to understand what actual method is being called. I’d rather just call the static method. Groovy’s category classes provide almost the identical idea but because they specify a scope with use(…) { } I find them much clearer as to the lookup semantics.

    Enums are already comparable. I’m not sure what your point is there. Seems like a clear win to me to maintain the beautiful little piece of syntactic sugar that enums are.

  11. Alex says:

    I went and look at the strings in switch proposal and it would still use == to compare strings but would force a String.intern() call if necessary to guarantee instance equality checks.

  12. Alex says:

    @Frz: All enums automatically implement Comparable based on the ordinal value of the enum constant. So Colors.RED.compareTo(Colors.GREEN) is already defined such that RED < GREEN. The only difference here is to map the < operator to that call.

    My only rationale for why to restrict it to enums is that they define their own very tight restrictions on what compareTo() means. Specifically,it’s based on the ordinal values and the built-in compareTo() is final to prevent you from changing that meaning. In the case of open-ended Comparable objects, they could do anything – calls to sockets or databases, blocking, etc. That would seem to be bad. Given that enums are providing their own little encapsulated ball of goodness, I’m happy to extend that a little further.

  13. Frz says:

    I was not aware that enums were Comparable, sorry about my lack of knowledge there.
    However I still think the operators should work on any Comparable when they work on Enums. People /should/ know that using the gt/lt ops triggers a method call as the operators are not defined on any Object type.

    Using intern() for String switches is intresting. I was under the impression that calling intern() on arbitary Strings is a bad idea. While I can not verify this claim right now I believe that interned Strings are always strongly references/never garbage collected – I don’t see how else the instance equality can always be guaranteed. I also remember a proffesor of mine talking about this in university – this is probably where I got this from. If this is indeed true switching arbitary strings would become dangerous.

  14. Alex says:

    @Frz: I disagree on Enums. They are syntactic sugar to be sure, but they are providing a very useful and important abstraction in the Java language and I think this cleans up some edges around that abstraction. I don’t want to have this functionality for generic Comparable objects – I suspect that starts to shade into operator overloading territory and that’s something Java has always stayed far away from.

    Calling intern() is not intrinsically bad. You should know what you’re doing of course. There’s nothing preventing interned Strings from getting garbage collected – they didn’t in very early JDKs so that may be the cause of some misconceptions. The only guarantee for two interned strings s1 and s2 is that if s1.equals(s2) then s1 == s2. If the strong references to s1 and s2 are both cut, then GC can reclaim the interned String. String literals in constant pools are a little different – they’re referenced by a Class so to get reclaimed the Class itself has to get garbage collected, which can also happen of course.

  15. leonardoavs says:

    First no closures, Second no modularity, and Third some little language changes. This is not the right way for JDK 7.

  16. Talden says:

    Agreed – it feels more like java 6.5.

    @Alex (re: super-constructors)
    That’s a shame. I don’t see why it isn’t
    1. Allocate space
    2. Constructors in sequence (most general to most specific)

    Being able to manipulate arguments and possibly even select which super constructor to call doesn’t seem like it should be a problem… Maybe it’s hard because of an internal optimisation.

    Still, I suppose as more effort goes towards promoting composition over inheritance, this will become somewhat moot.

    – Add Iterator and Enumeration as valid targets to the enhanced for.

    – Add Iterable and Iterator support everywhere that Enumeration is currently only available or the only accepted type. Deprecate appropriately.

    – Add deprecatedIn and removedIn properties to @Deprecated declare appropriate removedIn values for standard library cruft that has good replacements in common use so that there is incentive to remove the deprecated garbage EG.
    Frame.setCursor(int) could be @Deprecated(deprecatedIn = “1.1”, removedIn = “1.8”)

    The deprecation GC is very very slow…