Musings on JDK development

  • Java
    January 27, 2009

Project Coin: Small Language Change Proposal Form Available

The name of the OpenJDK project hosting small language changes for JDK 7 will be Project Coin. Besides a coin literally being small change, to "coin a phrase" is to create a little bit of new language.

The website for the project and its mailing lists will come into being this February. In the mean time, the initial form to use to propose a language change is listed below. If you have an idea for a change, please work on the form and post it the Project Coin mailing list once that gets started.

Small language changes I think would improve the language according to the
previously discussed criteria include (related Sun bugs in parentheses):


INSTRUCTIONS: For a proposal to be considered, this document must be complete and stand-alone in and of itself. No URLs, citations of papers, etc. can appear except for the limited supplementary information requested in the "REFERENCES" section. A new class file version number can be assumed to be available for -target 7. The proposal must not remove existing features of the language; for example, "Get rid of checked exceptions" would not be considered. As part of being stand-alone, the proposal must not rely on any other language changes that have not already been accepted.

AUTHOR(S): Who are you?


Provide a two sentence or shorter description of these five aspects of the feature:

FEATURE SUMMARY: Should be suitable as a summary in a language tutorial.

MAJOR ADVANTAGE: What makes the proposal a favorable change?

MAJOR BENEFIT: Why is the platform better if the proposal is adopted?

MAJOR DISADVANTAGE: There is always a cost.

ALTERNATIVES: Can the benefits and advantages be had some way without a language change?


Show us the code!

SIMPLE EXAMPLE: Show the simplest possible program utilizing the new feature.

ADVANCED EXAMPLE: Show advanced usage(s) of the feature.


SPECIFICATION: Describe how the proposal affects the grammar, type system, and meaning of expressions and statements in the Java Programming Language as well as any other known impacts.

COMPILATION: How would the feature be compiled to class files? Show how the simple and advanced examples would be compiled. Compilation can be expressed as at least one of a desugaring to existing source constructs and a translation down to bytecode. If a new bytecode is used or the semantics of an existing bytecode are changed, describe those changes, including how they impact verification. Also discuss any new class file attributes that are introduced. Note that there are many downstream tools that consume class files and that they may to be updated to support the proposal!

TESTING: How can the feature be tested?

LIBRARY SUPPORT: Are any supporting libraries needed for the feature?

REFLECTIVE APIS: Do any of the various and sundry reflection APIs need to be updated? This list of reflective APIs includes but is not limited to core reflection (java.lang.Class and java.lang.reflect.\*), javax.lang.model.\*, the doclet API, and JPDA.

OTHER CHANGES: Do any other parts of the platform need be updated too? Possibilities include but are not limited to JNI, serialization, and output of the javadoc tool.

MIGRATION: Sketch how a code base could be converted, manually or automatically, to use the new feature.


BREAKING CHANGES: Are any previously valid programs now invalid? If so, list one.

EXISTING PROGRAMS: How do source and class files of earlier platform versions interact with the feature? Can any new overloadings occur? Can any new overriding occur?


EXISTING BUGS: Please include a list of any existing Sun bug ids related to this proposal.


Join the discussion

Comments ( 42 )
  • mlewczuk Tuesday, January 27, 2009

    Great. For sure I will post at least one proposal.

  • David Linsin Tuesday, January 27, 2009


    I hope Sun has taken the time to take a look at the votings, which took place over the past couple of weeks.


    Regards, David

  • Joe Darcy Wednesday, January 28, 2009


    Yes, I've followed Stephen's series of language votes with interest.

  • Marek Koziel Wednesday, January 28, 2009


    Why null-s are not under consideration?

  • Osvaldo Pinali Doederlein Wednesday, January 28, 2009

    I think any proposal should strive to avoid differences between all "official" Java Platform languages, these being: the Java language, the Groovy language (JSR-241), and also JavaFX Script (currently just a Sun product but very likely a future JCP standard) and JavaScript (already bundled in Sun JDK via Rhino, but also a massively important companion to all web applications). It wouldn't hurt to also consider Scala, which is a very nice extension of Java IMHO as it keeps Java's static-typed-OO paradigm and improves on it; Scala's adoption to date is minimal, but they have some hard-earned experience pushing a Java-derived language forward.

    I don't mean that Java should copy other languages' syntaxes, but just that, if we decide to add to Java some syntax that exists - with similar semantics also - in other of these languages, we should avoid \*completely gratuitous\* differences. It is of course OK to have differences that have some justification, like some grammar ambiguity that would only happen in Java, etc.

    P.S.: It's sad that JavaFX Script itself didn't look closer at Scala, because both languages are even more alike, e.g. both have type inference, property-based construction, generators... JavaFX already resembles Scala in several syntactic choices but often with gratuitous differences: why def/var instead of def/val? Why "for (x in ..." instead of "for (x <- ..."? Neither of these choices are justified by better Java compatibility or any other reason I can see.

  • GreenEyed Wednesday, January 28, 2009


    Would API changes also be considered "language changes"? Because then I would propose to have a method added to String, isEmpty, that would be like the typical aString!=null && aString.trim().length()>0. That would save lots of chars, at least in my usual programs, and prevent silly typos where you have more than one string to check, and/or conditions...

    I know that the same can be accomplished very simply by creating a custom class to do so, but if everybody does their own... doesn't it mean it's a good candidate to be added to the common API?

    Just sintactic sugar, yes, but as you might produce the same bytecode as the equivalent double check, it would even be binary backward compatible, and it would mean less buggy code.

    Not sure if those are the proposals you are looking for, if need be, then a formal proposal could be sent, even though I'm not sure if formal proposals are meant to be added here.


    PD: One might consider also to use String as a condition... but I think that would mean a much bigger change. An API change would not be such a hassle.

  • Roman Elizarov Wednesday, January 28, 2009

    If switch by String is considered as "regularity improving change", then where is the support for Class literals in switch?

  • Joe Darcy Wednesday, January 28, 2009


    Certain types defined in the API do interact with the language specification, including java.lang.String, the wrapper classes (Integer, Double, etc.), class literals, and the meta-annotations in java.lang.annotation.

    However, the sort of API change in String you're proposing does not fall into the category of changes that would constitute a language change.

    There will be a process in place for proposing such API changes later in JDK 7.

  • Joe Darcy Wednesday, January 28, 2009


    Switching on class literals would be a possibility too.

    Traditionally a case label had to be a constant expression (JLSv3 section 15.28) of a primitive type. Constant expressions have always been defined over primitive types and strings so allowing strings to be constants for case labels is a natural extension.

    Starting in JDK 5, a case label could also be an enum constant, which is \*not\* a constant in terms of being a JLSv3 section 15.28 constant expression.

    Analogously, it would be possible to switch on class literals, which are also not defined as section 15.28 constants.

  • Joe Darcy Wednesday, January 28, 2009


    Certainly having an awareness of features and developments in other languages targeting the JVM and languages otherwise familiar to Java programmers is reasonable.

    However, a stronger consideration should be how the changes feel to Java developers in the context of Java programs. For these small changes, ideally they should be instinctively accepted as smooth extensions.

  • Joe Darcy Wednesday, January 28, 2009


    A few comments.

    First, the high-order question should be "why are these changes in" rather than "why is this other change not in." As noted in earlier blog entries in this series, especially given the maturity of the language and platform the default response is to leave the language as-is; the burden of proof is on the party wishing to make the change. Note also that there will be some overall bound on the size of the set of small changes that can be made; it is possible a change may be omitted from JDK 7 not because there is anything intrinsically wrong with it, but just that there is already a full set of other changes that have higher utility.

    I encourage those favoring other language changes, including null handling, to work on a form for the change and then submit it for consideration and discussion to the future project list. For a change to get in, part of that discussion will need to include a convincing case for the feature's inclusion. Proposal forms for the features I've listed will be sent to the list too.

    As for a new null handling operator, the Java language has not fundamentally changed its set of operators since the beginning. The prevalence of null handling is often more of an API design problem rather than a language design problem per se so I would favor mitigations to the problem that don't involve language changes, such as using null-checkers (see JSR 308) and encouraging APIs to return sentinel objects, like empty lists and zero-length arrays, rather than null.

  • sboulay Wednesday, January 28, 2009


    I don't see JSR-308 in the list above. Is that part of something else or no longer a change that will be part of JDK 7?

  • Joe Darcy Wednesday, January 28, 2009


    JSR 308 (http://groups.csail.mit.edu/pag/jsr308/) is a separate effort also targeted at JDK 7.

    There shouldn't be much direct interaction between the small language changes being proposed thus far and JSR 308; however, finding and dealing with any such interactions, as well as any interactions with JSR 294 modularity language changes, will be part of task of integrating all these changes into the platform.

  • Lasu aka Marek Koziel Thursday, January 29, 2009


    Thanks for answer.

    I need to say that in my opinion API changes should be considered at same time with language changes. I think that because we might miss some API proposal that can replace language changes.

    If happen that one API proposal will be so good and sensible that it will decrease other language change proposal priority, then we might notice that a lot efforts was lost unnecessarily.

    What's more I wander if JavaDoc as integral part of Java will be considered as well?

    According to:



  • Visitor 42 Thursday, January 29, 2009

    > There will be a process in place for proposing such API changes later in JDK 7.

    Would a suggestion stand a chance to clean up APIs that still use the old Vector or Hashtable in arguments or that return a Vector or Hashtable?

    Not by removing the constructors/methods that use Vector, but by providing alternatives using List or Map? And possibly marking the ones using Vector or Hashtable as deprecated?

    The reason for this should be obvious: APIs still exclusively using Vectors or Hashtable force the programmer to either use the outdated class throughout his/her own code or to write code to copy data back and forth between the outdated class and one of the "new" collection classes.

  • Shams Mahmood Thursday, January 29, 2009

    where is this form supposed to be submitted? :)

  • Joe Darcy Thursday, January 29, 2009


    In the near future there will be an openjdk.java.net web page and mailing list for Project Coin; the form should be submitted there.

  • Lasu aka Marek Koziel Thursday, January 29, 2009


    If I get it right we have only model of form.

    Submitting will be available in February.

  • Shams Mahmood Thursday, January 29, 2009



    eagerly waiting for it :D

  • Joe Darcy Thursday, January 29, 2009

    @Visitor 42,

    Due to the disruption deprecating an API can have, currently an API has to be "actively hazardous" to be deprecated, like Thread.stop. In the future we may add a "denigration" facility to mark API elements that aren't quite so bad that they should be deprecated, but shouldn't be used in most cases. Vector and Hashtable would be good candidates to be denigrated.

    There are no plans to have a wholesale parallel set of List/HashMap APIs versus Vector/Hasthtable ones beyond what has been done already.

  • Joe Darcy Thursday, January 29, 2009


    Ultimately it is the whole platform that needs to evolve sensibly and our ultimate responsibility as engineers is to ensure the conceptual integrity of the platform. API changes are generally preferred over language ones. However, I don't see the sort of changes I've listed as being easily substituted by API changes. For the more concise constructor calls, it would be possible to "fix" the problem by always use static factories instead, which I think is a fine idea for other reasons too. However, that wouldn't help calling existing source code that uses constructors rather than factories. The method with exotic names could be called reflectively, but that would lose compile time checking and be slower at runtime.

    Javadoc is due for a refresh, but that is not planned for JDK 7

    PS Per your blog, you can document type parameters in a class using " @param <R> Description of R" in the class javadoc comment.

  • Lasu aka Marek Kozie&#322; Thursday, January 29, 2009


    Thanks ;)

    I'm glad that while I'm quite new with Java we have similar opinion about language changes.

    But don't you think that string-switch I pretty gimpy solution?

    There is no way to use req. expressions, or other objects. If so much efforts is placed in changing language it should cover as much needs as possible, not just knit up.

    It's just shadow of:

    switch(object;Equally/\* null as == \*/) ...

    public interface Equally<Type> {

    boolean equal(Type base, Type other);


  • Joe Darcy Thursday, January 29, 2009


    As these are small language changes, they are intended to stop us hobbling, not to let us swim ;-)

    While general pattern matching is common in other families of languages, I don't think it would be a good fit to Java.

  • Lasu aka Marek Koziel Friday, January 30, 2009


    That's exactly what I meant ;)

    I'm just lazy and prefer do two steps at once:

    hobble -> walk -> run

    If it's only possible ;)


    I wander if Java should support basic patterns or not.

    Good patterns would allow community to write more compatible code. But wouldn't that be to much complex for beginners?

  • Geoffrey De Smet Sunday, February 1, 2009

    +1 on Null handling (a = b.?getC())

    +1 on string switch

    - 0.5 on multi-catch, as java is typesafe and any variable should be one type at least.

  • Daniel Wednesday, February 4, 2009

    I am looking for SupressFinalize() -equivalent in java. Does it qualify for project coin?

    For those who have no idea what SupressFinalize() is:

    SupressFinalize(Object) in .net prevent an object to queued in the finalization queue. This is called when the object is clean up. This give the developer a freedom to choose between GC+Finalization or dispose/close manually.

  • Joe Darcy Thursday, February 12, 2009


    No, there are no plans for a SupressFinalize capability. My understanding of how finalization is implemented in HotSpot is that if the default finalizer from Object is used, there is no finalization overhead since there is nothing to do.

    This decision is made on a per-class basis by the class author and not on a per-object basis by the user of an object.

  • Marek Lewczuk Thursday, February 12, 2009

    Joe, what about import aliases ? I was asking you about this few months ago, but you didn't answer. How do you see this, is it possible to have this feature in jdk7 ? For big projects that would be very helpful..

  • Joe Darcy Friday, February 13, 2009


    No, I would not favor import aliases or aliases for long type names. Deciphering the meaning of names in a Java program is complicated enough as is!

  • Paul LeBeau Saturday, February 14, 2009

    I've always thought it would be nice if there was some sort of syntactic sugar to cover the common case where you are dealing with exceptions that you know will not happen, or choose to ignore. For example:





    catch (SomeException e)


    // Do nothing


    This happens quite often in any non-trivial program and IMO the ugly boilerplate reduces the readability of code. However, I'm not sure what form the syntax for this might take. Perhaps:

    myResultSet.close() consume SQLException;

    The other case is where you are not expecting an exception, but want to know if it happens. An example might be StringWriter.close(), for example, which is declared as throwing IOException even though it never does. Effectively you want to convert a checked exception into a runtime one:

    myStringWriter.close() unchecked IOException;

  • Peter Lawrey Tuesday, February 17, 2009

    Here is my suggestion for treating arrays as Objects which have member functions instead of relying on helper methods.


  • Daniel Cheng Tuesday, February 17, 2009

    the SupressFinalize() method in .net allow deciding whether to finalize() a object depends on _the state_ of the object, not the class.

    Let me give a example: a database connection.

    If the connection is close, don't queue in finalization queue. This make i/o in finalization less harmful.

  • Peter Lawrey Tuesday, February 17, 2009

    @Daniel one way to the same thing is

    // in finalise().

    if (!isClosed()) close();

  • AB Sunday, February 22, 2009

    Switch should be deprecated now that we have enums. Use the command pattern:




  • Laurens Van Houtven Wednesday, February 25, 2009


    I'm nobody special, I just use Java in the context of a bunch of university courses. I'm not familiar with any of the code involved, I just use it.

    I've noticed that you cannot create BigInteger objects from primitive or boxed primitive integer types (Tried int, long, Integer, Long).

    Apparently there is a constructor for longs, but it's hidden (or at least, that's what Eclipse tells me when I try to use it). I'm not sure this does what you'd expect it to do (create a BigInteger with .intValue() equal to the provided int) -- if it doesn't, that'd explain the visibility.

    If that constructor does something weird and is used internally for that purpose, the cost would be rewriting whatever it is that does into something else. Otherwise, I don't really see the cost.

    The following snippets work, but are obviously ugly:

    new BigInteger("100"); // Turning an integer into a string so we can turn it into an integer? Yuck!

    new BigInteger("" + 100) // abusing String + int -> String + Integer.toString() -> String

    new BigDecimal(100).toBigIntegerExact(); // yes, BigDecimal does have the required constructor, despite not actually being meant exclusively for integer types...

    And, of course, you can create a new Integer object and call toString() on it. Ugh.

    I'm sure there's a good reason for this, but I've found it quite annoying. new BigInteger(10000) makes sense. new BigInteger("" + 10000) does not.

    I'm not advocating the removal of the String constructor. I'm sure it has its uses: for one, being able to create BigIntegers that are absurdly huge and can not be accurately represented by a primitive integer type. I'm saying we should have more constructors :-)

    I don't think any tests would have to be changed (just added, obviously). This sounds quite easy to do (disclaimer: I am not familiar with any of this code!). It wouldn't break any existing code (the class has no visible constructors compatible with a single long/int/byte argument.

    If I'm completely wrong and implementing this would cause the sky to come falling down, please educate me and show me the error of my ways :-)

    Thanks for reading,


  • Joe Darcy Wednesday, February 25, 2009


    First, the issue you raise is a libraries issues and not a language one. Second, to create BigInteger values from integral primitive types, just use the static factory BigInteger.valueOf(long).

  • Diego Souto Tuesday, March 3, 2009

    Maybe three syntactic sugar conventions

    \* if (object)

    -- instead of --

    if (object!=null)

    \* MyClass obj = new MyClass([attrib1="value1", attribN=valueN]);

    -- instead of --

    MyClass obj = new MyClass();



    \* properties like in C# or Delphi instead of definition of attribute, getter and setter.

  • Richard Johnson Tuesday, March 3, 2009

    This is a good project that risks major feature creep. That said, it would be really good if the default encoding for strings were UTF-8 instead of ISO. As it is, all asian and many central and eastern european strings must be escaped character-by-character. ISO might have made sense ten years ago, but globalization marches on.

  • Jeff Skjonsby Tuesday, March 3, 2009

    I would love having a literal string syntax for regex and paths and multiline strings.

  • Samuel Tellez-Cobos Friday, March 6, 2009

    Please... add in the new JDK the optional parameters... for example:

    public void myMethod(optional String p1,String p2){



  • Henning Hoefer Saturday, March 14, 2009

    Another really small language change (syntactic sugar) suggestion would be a shorthand ternary operator:

    object ?: otherObject

    could be an alias for

    object != null ? object : otherObject

  • JGarrido Monday, March 23, 2009

    int a = 1;

    int b = 1;

    int c = 1;

    String abc = "aaa";



    System out-> aaa


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