Musings on JDK development

  • Java
    December 23, 2008

Criteria for desirable small language changes

The two primary goals of making small language changes in JDK 7 is to:

  1. Make the things programmers do everyday easier.

  2. Support other platform changes in JDK 7.

Over the years, certain common coding patterns have been recognized as needlessly verbose including:

  • if-equals-X-else-if-equals-Y testing chains on strings

  • duplicated catch blocks for different exception types

  • repeated type parameters when declaring and initializing a variable of parameterized type

These patterns can be replaced with new constructs that are more concise and more clear without fundamentally altering the language. Besides improvements to support existing Java programs, language changes should also be made to allow appropriate access to new JVM capabilities, such as those being enabled by the Da Vinci Machine project.

While language changes can fundamentally improve the modes of expression in a language, language changes have a number of drawbacks as solutions to programming problems:

  • Slow availability: Language changes occur in platform releases, which typically only occur every few years.

  • Heavyweight: The full extent of a language changes can affect multiple components of the platform.

  • Changes may be needed at multiple points in the toolchain: Even after a language change is fully available in the JDK, independent libraries and tools may need to be updated as well before the changes can be fully utilized.

Therefore, language changes are rarely the preferred solution if other workable solutions are available. Since IDEs are now commonly used for Java development, mitigating or solving problems using IDE tooling is one possibility. As of Java SE 6, compliant compilers are required to support annotation processing as standardized by JSR 269, see
Annotation processing provides a general meta-programming framework; beyond processing annotations directly, annotation processors can be used to implement many currently extra-lingual checks based on a program's structure. Checks which previously would have required language changes can now be implemented by developers and just used by convention.
JSR 308, Annotations on Java Types, would enable more detailed checking by allowing annotations in more program locations.

When judging whether or not any change to the platform is worthwhile, a useful notion is estimating the feature's "thrust to weight ratio," that is estimating whether the benefits of making the change exceed the full cost of implementing the change. For language changes, this metric is improved by having a larger fraction of programs potentially benefiting from the change. For example, it would be roughly the same amount of engineering to add numerical operator overloading support for classes like BigInteger and BigDecimal as to add support for bracket, "[]", syntax for Lists and Maps. Besides complications with the == operator in the numerical case, bracket syntax for Maps and Lists has much higher utility since many more Java programs use Collections than large numbers.

Especially with the maturity of the Java platform, the onus is on the proposer to convince that a language change should go in; the onus is not to prove the change should stay out.

Given the upcoming holidays, the language change proposal form and the seeding proposals will both be coming in January 2009.

Join the discussion

Comments ( 17 )
  • Patrick Tuesday, December 23, 2008

    One note, with current static analysis tools, and given that there is an enormous codebase in Java which is open source, you might also be able to perform some statistical analysis on how much reach a certain feature/change might have.

    A separate point to have in mind is that languages designed for operator overloading (or an equivalent feature, like the operator-as-method-name in Scala) may be a useful alternative to extending Java. That is, one reasonable option for people using BD and BI extensively would be to write those calculations in another JVM language like Scala (for nicer syntax) but leave the bulk of their code in Java.



  • Andy Tripp Wednesday, December 24, 2008

    > the benefits of making the change exceed the full cost of implementing the change

    In the "thrust to weight" equation, I think the "weight" should be the drawbacks of having the new feature, not the cost of implementing it.

    For example, there do exist programs that could benefit from the addition of "goto". But adding "goto" is still a bad idea, not because it would be difficult to implement, but because of its potential for misuse.

    You make a great point about the onus being on those who want the addition. And the argument needs to go far beyond showing that use cases exist where the new feature would be a benefit (again, anyone could come up with a good use case for "goto").

    Take any real-world application of size, say, 100,000 lines. You could find real cases in that app where each of the 1.5 features (generics, foreach, etc) would help. Those cases would be clear and compelling, without any clear drawback.

    New features such as closures need to be just as compelling.

    > Given the upcoming holidays, the language change proposal form and the seeding proposals will both be coming in January 2009.

    What's that? Is there a new form being created for language changes?

  • Joe Darcy Wednesday, December 24, 2008


    Yes, naturally the benefits of a language change need to be considered too, but the implementation cost is a necessary factor as well, especially since these changes are supposed to be small :-)

    Prototyping converting a code base to use a new language feature could lend strong evidence that the proposed feature is as useful as expected.

    Yes, coming in January I'll be publishing a standardized form for those with language change proposals to fill out. This will provide a common basis for discussion and help ensure no major factor is omitted; the form will include a guided condensation of the points raised in:


  • Lasu -Marek Kozieł- Sunday, December 28, 2008


    Could u look at:


    and give u's opinion?


  • Joe Darcy Sunday, December 28, 2008


    I'm doubtful null handling will make its way into JDK 7. The form to submit language request proposals will be available in January.

    Happy new year.

  • Lasu -Marek Kozieł- Monday, December 29, 2008
  • Mike Duigou Thursday, January 1, 2009

    Any special advice for a change which doesn't alter syntax or bytecode but does change the grammar slightly?

    I'd like to see the restriction on calling super() and this() in constructors loosened so that it's possible to declare local variables and assign to static variables before making the call to the other constructor.

    I can understand the current restrictions on calling non-static methods and accessing fields before calling this() or super(), but it sure would be convenient to be able to do transformations upon constructor parameters or other calculations before having to call the super() or this() constructor.

    It's not uncommon to see custom static functions who's purpose is solely to do some transformation upon a constructor parameter before calling the super() or this() constructor. Indeed you can call any static method or methods on parameters or static field members for every parameter passed to the other constructor. It gets gross when this is done for every passed parameter, or the transformations are done inline or extra work has to get done. For example, imagine a decimal fraction constructor parameter which has to be transformed into a separate numerator and denominator parameters before calling the super() constructor. There's no clean way to do this now.

    The current restriction appears to me to be mostly a Java Language restriction and not a restriction of the JVM bytecode.

    Would this even qualify as a "small language change" or would it be something different?

  • Joe Darcy Friday, January 2, 2009


    The Sun Contributor Agreement (SCA) is needed for code contributions to go back into the JDK so if someone wanted to help with the implementation of a language change, the SCA would need to be signed.

  • Joe Darcy Friday, January 2, 2009


    Yes, I've also been annoyed by those pesky, if well intentioned, rules about having to call super() or this() first thing in a constructor.

    Loosening such rules would be a small language change, but I don't think working through this change would have a high utility relative to other changes we'd want to get in.

  • ben Monday, January 5, 2009


    The majority of code I and all other developers I know working on apps deal with is the following:

    1. Loops

    - Closures would help here dramatically. Until it's brought into the language (especially into collections), the majority of developers won't integrate them. Pushing libraries like commons-collections Closure/Predicate et al won't help.

    Is there any way we could get this in? At all? What would you ask of the community to get neals closure spec into java7?

    2. Null checking. Enough said.

    3. String templating ( "say ${var}!")

    Exceptions won't change my development; they are usually handled in a framework, so day to day it makes no difference for the average developer.

  • ben Monday, January 5, 2009

    Small caveat:

    I wouldn't want string templating unless the code:

    "say ${var}" was equivalent to "say "+ var

    And following from that:

    "say ${var.substring(0)}" was able to be code completed (e.g. the structure of the template was introspectable at runtime).

  • bjb Tuesday, January 6, 2009

    My "small change" pick list :

    - "static parameters" : adding static keyword on parameter indicates the parameter's name should be retained by the compiler (whatever compiler option is chosen) and grantted accessible by API (the suppose introduction of new method on the reflection API). This one is the key to "boiler plate" and "annotation junk" removal because we can simply say, the name of the parameter is part of the contract and should not be changed without impacting the contract !

    - conditional dot "?." to prevent NPE

    My "not so" small change pick list :

    - reified generics (yes we can !)

    - operator overloading (why did we brought static import and not this one at the same time ?)

    - extendable enums (should be able to use extends on enum)

    - non-contiouous valuated enum at this time "value" is "index" and continuous, to use value

    as "constants" in real world conditions we need to be able to specify the value assigned at the same time to the enum (overriding the default=index one).

  • Joe Darcy Wednesday, January 7, 2009


    A few comments.

    As previously explained, since BGGA closures is considerably larger than a small language change it is thus out of bounds for inclusion in this effort:


    Neal's current implementation of BGGA is described a prototype and there is a non-negligible list of open issues. A sizable amount of additional work would be needed to refine the prototype and specification to prepare it for inclusion in the platform; while much progress has been made, the project is not complete. Continuing this work could be done by the community, more specifically by some particular individuals of the community, without prompting from me or others at Sun. However, the set of individuals with the right skill set is small, language design and implementation are distinct skills from general programming.

  • sboulay Friday, January 9, 2009

    Joe - there's a simple solution for the closures problem. Why don't you guys just hire Neil back :-) . Also, I see some draft proposals to prevent NPE (http://www.jroller.com/scolebourne/entry/java_7_null_default_and#comments). You say that your "doubtful null handling will make its way into JDK 7" .. why is that?

  • Joe Darcy Monday, January 12, 2009


    At this stage of Java's evolution, adding an operator to deal with null seems to me to be a drastic solution.

    Additionally, assuming JSR 308 gets incorporated into the platform as planned, one of the main checkers is to assist null handling.

  • sboulay Monday, January 12, 2009

    Unless I am mistaken, 308 does not help when deferencing (getFooMayBeNull()?.getBarMayBeNull()?.getResult()) a chain of method calls. In the case that a null is valid (in some cases) you must do a check and still have to write a bunch of nested if statements. I think 308 might prevent nulls where not appropriate but it probably won’t help with the verbosity when doing legitimate null checks. Am I missing something? I know that 308 extends far beyond @Nullable and @NotNull.

    I was under the impression that language proposals that people submitted were all under consideration - there are obviously some language changes that Sun is leaning against.

  • Joe Darcy Monday, January 12, 2009


    Using language changes to address poor API design can be a dangerous proposition. JSR 308 could help cut down on spurious null checks where an API was not supposed to return null.

    Being open to language proposals is not the same as having no opinion about what changes should be made. As discussed in this and other blog entries, we at Sun will be organizing a set of seeding proposals, using the standard yet-to-be-published form, later in January; those and other proposals will be evaluated by the sorts of criteria being discussed here, utility, cost, etc.

Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.