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):

  • Strings in switch: A simple change that improves regularity in the language (5012262, 4269827).

  • More concise calls to constructors with type parameters: A large pain point when using generics occurs with the need to specify type parameters both on the left hand side of a declaration of a generic variable as well as on the right hand side in a constructor call to initialize the variable (4879776).

  • Exception enhancements: multi-catch and final rethrow: Exception handling would be streamlined if semantically the same code for distinct exceptions could be shared (4432337).

  • Ability to call with methods with exotic names: As the Java platform gets better support for non-Java languages via the Da Vinci Machine project, it is useful to allow Java programs to call methods from foreign languages hosted on the JVM, even if those languages have different naming restrictions than Java (6746458).

  • (Possibly) Bracket notation to access collections: Collections like List and Map are nearly ubiquitous in Java programs and they offer many advantages over arrays, including better integration with the generic type system, availability of growable data structures, and the possibility to use immutability. However, arrays do have their more concise [] notation; allowing lists and maps and similar data structures to use this notation would encourage their use even more widely (4632701, 4877954).


PROJECT COIN SMALL LANGUAGE CHANGE PROPOSAL FORM v1.0

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?

OVERVIEW
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?

EXAMPLES
Show us the code!
SIMPLE EXAMPLE: Show the simplest possible program utilizing the new feature.

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

DETAILS
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.

COMPATIBILITY
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?

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

URL FOR PROTOTYPE (optional):

Comments:

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

Posted by mlewczuk on January 27, 2009 at 04:09 AM PST #

Hi,

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

http://www.jroller.com/scolebourne/entry/jdk_7_language_changes_everyone

Regards, David

Posted by David Linsin on January 27, 2009 at 12:17 PM PST #

@David,

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

Posted by Joe Darcy on January 27, 2009 at 04:00 PM PST #

@Joe
Why null-s are not under consideration?

Posted by Marek Koziel on January 27, 2009 at 08:02 PM PST #

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.

Posted by Osvaldo Pinali Doederlein on January 28, 2009 at 02:37 AM PST #

Hi,
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.

S!
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.

Posted by GreenEyed on January 28, 2009 at 03:05 AM PST #

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

Posted by Roman Elizarov on January 28, 2009 at 04:35 AM PST #

@GreenEyed,

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.

Posted by Joe Darcy on January 28, 2009 at 05:51 AM PST #

@Roman,

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.

Posted by Joe Darcy on January 28, 2009 at 07:16 AM PST #

@Osvaldo,

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.

Posted by Joe Darcy on January 28, 2009 at 07:31 AM PST #

@Marek,

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.

Posted by Joe Darcy on January 28, 2009 at 07:57 AM PST #

Joe,

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?

Posted by sboulay on January 28, 2009 at 09:10 AM PST #

@sboulay,

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.

Posted by Joe Darcy on January 28, 2009 at 01:55 PM PST #

@Joe
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:
http://lasu2string.blogspot.com/2008/12/is-javadoc-killing-program-evolution.html

Greetings!

Posted by Lasu aka Marek Koziel on January 28, 2009 at 05:45 PM PST #

> 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.

Posted by Visitor 42 on January 28, 2009 at 10:16 PM PST #

where is this form supposed to be submitted? :)

Posted by Shams Mahmood on January 29, 2009 at 12:15 AM PST #

@Shams,

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.

Posted by Joe Darcy on January 29, 2009 at 12:29 AM PST #

@Shams
If I get it right we have only model of form.
Submitting will be available in February.

Posted by Lasu aka Marek Koziel on January 29, 2009 at 12:33 AM PST #

@Joe
@Lasu

eagerly waiting for it :D

Posted by Shams Mahmood on January 29, 2009 at 12:42 AM PST #

@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.

Posted by Joe Darcy on January 29, 2009 at 12:48 AM PST #

@Lasu,

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.

Posted by Joe Darcy on January 29, 2009 at 01:37 AM PST #

@Joe
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);
}

Posted by Lasu aka Marek Kozieł on January 29, 2009 at 09:49 AM PST #

@Lasu,

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.

Posted by Joe Darcy on January 29, 2009 at 01:48 PM PST #

@Joe
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?

Posted by Lasu aka Marek Koziel on January 29, 2009 at 04:03 PM PST #

+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.

Posted by Geoffrey De Smet on February 01, 2009 at 03:29 PM PST #

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.

Posted by Daniel on February 04, 2009 at 10:21 AM PST #

@Daniel,

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.

Posted by Joe Darcy on February 12, 2009 at 09:18 AM PST #

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..

Posted by Marek Lewczuk on February 12, 2009 at 03:35 PM PST #

@Marek,

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!

Posted by Joe Darcy on February 13, 2009 at 04:03 AM PST #

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:

try
{
someMethod()
}
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;

Posted by Paul LeBeau on February 13, 2009 at 08:49 PM PST #

Here is my suggestion for treating arrays as Objects which have member functions instead of relying on helper methods.
http://www.freshvanilla.org:8080/display/www/Array+super+class

Posted by Peter Lawrey on February 17, 2009 at 05:31 AM PST #

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.

Posted by Daniel Cheng on February 17, 2009 at 01:12 PM PST #

@Daniel one way to the same thing is

// in finalise().
if (!isClosed()) close();

Posted by Peter Lawrey on February 17, 2009 at 03:25 PM PST #

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

switch(someString)
->
MyEnum.valueOf(someString).perform();

Posted by AB on February 22, 2009 at 04:18 AM PST #

Hey.

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,

Laurens

Posted by Laurens Van Houtven on February 25, 2009 at 07:29 AM PST #

@Laurens,

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).

Posted by Joe Darcy on February 25, 2009 at 08:59 AM PST #

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();
obj.setAttrib1("value1");
obj.setAttribN(valueN);

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

Posted by Diego Souto on March 02, 2009 at 05:59 PM PST #

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.

Posted by Richard Johnson on March 03, 2009 at 07:01 AM PST #

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

Posted by Jeff Skjonsby on March 03, 2009 at 11:01 AM PST #

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

public void myMethod(optional String p1,String p2){
//CODE
}

Posted by Samuel Tellez-Cobos on March 05, 2009 at 10:26 PM PST #

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

Posted by Henning Hoefer on March 14, 2009 at 04:00 AM PDT #

int a = 1;
int b = 1;
int c = 1;
String abc = "aaa";

System.out.println(a+""+b+""+c+"\\n");
System.out.println(abc);

System out-> aaa
aaa

Posted by JGarrido on March 23, 2009 at 01:42 AM PDT #

Post a Comment:
Comments are closed for this entry.
About

darcy

Search

Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today
News

No bookmarks in folder

Blogroll