Coming Soon: A JSR for small language changes in JDK 7

I'm happy to announce that I'll be leading up Sun's efforts to develop a set of small language changes in JDK 7; we intend to submit a JSR covering those changes during the first half of 2009. However, before the JSR proposal is drafted and submitted to the JCP, we'll first be running a call for proposals so Java community members can submit detailed, thoughtful changes for consideration too. We'll be seeding the discussion with a few proposals we think would improve the language. More information on our proposed changes, guidance for measuring the size of a change, and criteria for judging the desirability of a language change will be coming over the next several weeks.

I've proposed an OpenJDK project to host the discussion of the proposals and potentially some prototype implementations.

Suggested Reading
So you want to change the Java Programming Language...

Comments:

For those of you attending Devoxx this week, I'll be aiming to reserve some space on the whiteboards upstairs to allow ideas and discussion starting Wed morning.

Posted by Stephen Colebourne on December 08, 2008 at 06:56 AM PST #

Oh, and a quick reminder that prototype implementations already exist for a number of language change ideas at Kijaro - http://kijaro.dev.java.net. Anyone reading this that wants some space at the Kijaro project for your own idea, just contact me, and you can start hacking javac.

Posted by Stephen Colebourne on December 08, 2008 at 07:28 AM PST #

Stephen,

https://kijaro.dev.java.net/ works better. (For some reason, java.net project pages are https.)

Dave

Posted by David Walend on December 08, 2008 at 09:15 AM PST #

I'd like to propose "Reusable Exception Handling Objects" for consideration. This blog post has a first draft of the porposal. http://aberrantcode.blogspot.com/2008/03/try-and-try-again.html

Collin

Posted by collin.fagan@gmail.com on December 08, 2008 at 11:05 PM PST #

Language changes or language additions? That's a critical distinction. There are very few new additions that are simple and obvious enough to carry their added weight at this point in time unless other parts of the language are removed to make room for them. We really don't need six new ways to do things we can already do.

And really I thought Java 7 was far enough along that something like this wouldn't just be starting now. Maybe Java 8 would be more realistic?

Posted by Elliotte Rusty Harold on December 09, 2008 at 12:07 AM PST #

Elliotte,

I agree we don't need six ways to do any one thing, but I think features like multi-catch and switch(string) is at least consistent with the existing language syntax/conceptual-model.

Joseph,

Any plans on fixing the Generics corner cases in Java7 or Java8? I'd personally like to see full-fledged reification.

Posted by Gili on December 09, 2008 at 12:18 AM PST #

Hello!
First of all, I would like to suggest conditional dot operator, which would drastically increase code readability in some cases like XML processing.
a.?.b();

It should work like:

a.?.operations===
{
Object o= a;
if (o==null) return null;
return o.operations;
}

Note that this way would be wrong(in multi-thread):
{
if (a==null) return null;
return a.operations;
}

“Parent p= parent return null if parent is null, perform operation in other way.”

It would help avoid some NullPointerException.

Now if we have multi-thread program, in which there is a possibility that other thread do some changes. Implementation something like:
F f =a.b.c.d.e.f()
need to be done:

{
F f=null;
if(a!=null){
B b=a.b;
if (b!=null){
C c = b.c
if (c1=null){
...
}
}
}
}

While with this operator it would be ( '.?.' is operator ):

F f = a.?.b.?.c.?.d.?.e.?.f();

>How does the grammar need to be revised?
Add new operator only, look like little work

>How is the type system affected?
No affect?

>Are any new conversions defined?
I do not see any.

>Are naming conventions or name visibility modified?
No.

>Is the existing structure of packages, classes, or interfaces changed?
No.

>How can the new feature be annotated?
No.

>Is method resolution impacted?
What ?

>How does the change impact source compatibility?
Old code will work same as before.
>How does the change impact binary compatibility?
Do not know.

>Does the feature affect the reachability of code or the definite assignment of variables?
None affect?

The only problem can be if we some one try

f= a.?.b.?.c.?.f;
where f is a simple type.
I think warning should be shown then.

As I was informed while discussion about it Groovy already have it:
http://groovy.codehaus.org/Operators
It use (?.) as operator, but in my opinion (.?.) would be more visible.
--
Greetings!

Posted by Lasu -Marek Kozieł- on December 09, 2008 at 01:03 AM PST #

I just forget.

Should be pocible to use it on arrays:
array.?.[5]

Greetings!

Posted by Lasu -Marek Kozieł on December 09, 2008 at 01:29 AM PST #

Please support a more intuitive way than listeners!
Events (and delegates) like in C# would be fine.

Posted by Lui on December 09, 2008 at 01:48 AM PST #

Part 2.

Iterators should be available for foreach loop.

Part 3.
foreach loop should be able to iterate throw more containers
like:
{
String[] array;
Iterator<String> iterator
for(String s:array:iterator)
}

Part 4.
Wildcards on foreach loop.
Because no all time casting is required.
{
for(? some:array:iterator)

}

In that case some type would be :
Interfaces /classes that are implemented by array & iterator.
This would avoid long unnecessary code.

Part 5.
Add new interfaces, like:

/\*\*
\* {@link Comparable}{@literal <Element>} implements {@link ComparatorAsymmetric}{@literal <Element,Element>}
\*
\* @see Comparator
\* @author Marek Kozieł
\*/
public interface ComparatorAsymmetric<Source, Element> {

/\*\*
\* @param source the first object to be compared.
\* @param element the second object to be compared.
\* @return a negative integer, zero, or a positive integer as the first argument is less than, equal to, or greater than the second.
\* @throws ClassCastException if the arguments' types prevent them from being compared by this comparator.
\* @see Comparator#compare(Object, Object)
\*/
public int compare(Source source, Element element);

}

It woul increase encapulation. Should I describe reason?

--
Greetings!

Posted by Lasu -Marek Kozieł on December 09, 2008 at 02:52 AM PST #

Stephen,

Please send a pointer to pictures of this year's Devoxx language whiteboards after the conference.

Thanks.

Posted by Joe Darcy on December 09, 2008 at 03:58 AM PST #

@Collin, @lasu, and others with language changes ideas, we'll start formally accepting proposals once the OpenJDK project's email alias exists and I've written up more of the supporting information.

Posted by Joe Darcy on December 09, 2008 at 04:29 AM PST #

@Elliotte, the candidate language changes will be additions in the sense that we generally don't want to invalidate existing programs. However, if the result is a more regular language, the additions can be simplifications and lead to simpler, shorter, programs.

Posted by Joe Darcy on December 09, 2008 at 04:33 AM PST #

Deprecation of non-argument versions of to(Upper/Lower)Case methods in the JDK would be great since these two methods are the main reason that most java applications don't run on Turkish locale machines.

Posted by Bilgehan Maraş on December 09, 2008 at 06:03 AM PST #

At Devoxx, we've two whole whiteboards devoted to this topic. One is freeform, the others asks developers to rank from 1 to 8 eight of the most commonly talked about ideas. Pictures and feedback after Devoxx. And if you are at Devoxx, then please help with the ranking!!!

Posted by Stephen Colebourne on December 09, 2008 at 09:17 PM PST #

I've posted some specs on how to enhance Java's string handling, which is badly falling behind compared to other languages.

Some initial ideas here:
http://docs.google.com/View?docid=d36kv8n_32g9zj7pdd

Any feedback is welcome.

Posted by Jacek Furmankiewicz on December 09, 2008 at 10:25 PM PST #

@Stephen
Could u give us link? Is this open?

@Jacek
I agree with u about Un-Escaped Strings
Other would be problem in my opinion. But it's not place about discus.

Posted by Lasu -Marek Kozieł on December 09, 2008 at 11:44 PM PST #

@Stephen
I found that page:
http://www.javapolis.com/confluence/display/JP07/Whiteboard+results+-+Language+change
And I cannot agree with some ideas.
Like:
> Access List and Map using []
In my opinion it''s horrible because:
1.List & Map are not well implemented.
2.This can be obtained by adding new constructor “public List(Type[] array)”
3.List should be extended with one level type validation “public List(Class<? Super Type> componentType)”

>String switch
What for, who need string oriented language?
Is not better to extend switch to accept comparator?
switch (object:objectComparator) {
case object1: return 1;
case object2: return 2;
case object3: return 3;
}

>Null-handling
Notice that this is not common. And depends from kind of problem.
If problem if graph/tree (sometimes multi-thread) like, u will need that solution in 90%.
In other problems u wont need that at all.

@Jacek
>For-each loop for Maps
but what e problem for map to provide one more iterator?

Greetings!

Posted by Lasu -Marek Kozieł on December 10, 2008 at 12:38 AM PST #

I realize closures are out for Java 7 (at least from what I hear), but some level of the exception transparency it introduced for generics would be a really good thing.

Posted by Jess Holle on December 11, 2008 at 07:13 AM PST #

Re: "I realize closures are out for Java 7 (at least from what I hear), but some level of the exception transparency it introduced for generics would be a really good thing."

If it weren't for the bits around exception transparency (e.g. disjunctive types), BGGA's closures would be a medium change. Most of the spec, implementation, and testing complexity resides in the support for exception transparency.

Posted by Neal Gafter on December 12, 2008 at 12:37 AM PST #

The Devoxx whiteboard language change vote results are now available: http://www.jroller.com/scolebourne/entry/jdk_7_language_changes_devoxx

Posted by Stephen Colebourne on December 14, 2008 at 06:56 AM PST #

@Stephen,

Interesting whiteboard analysis; thanks.

Posted by Joe Darcy on December 15, 2008 at 05:49 AM PST #

And the results from JavaEdge in Israel, where I used the keynote to actually explain 10 options and get immediate voting using cards:

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

Posted by Stephen Colebourne on December 21, 2008 at 09:41 AM PST #

I believe a method size() for arrays would improve consistency between the usage of arrays and collections. I would also assume that this is a quick change and has a low risk.

Posted by Lars Vogel on December 22, 2008 at 04:12 AM PST #

A far better RFE is to make Arrays first-class citizens. Give them hashCode(), equals(), toString() directly on the object.

Posted by Gili on December 22, 2008 at 04:50 AM PST #

I'm not sure if hashCode(), equals(), toString() an arrays would still count as a small change.

I still believe that size() is a small change with little risk but with a notable benefit for a consistent API.

Posted by Lars Vogel on December 22, 2008 at 05:36 AM PST #

@Lars and @Gili,

Changing the default behavior of hashCode, equals, and toString on array objects is not being considered for JDK 7. Since JDK 5, more useful implementations of the functionality of those three methods have been provided in the java.util.Arrays class.

It would be possible to add a size methods to arrays, but I don't see that as a high priority.

Posted by Joe Darcy on December 24, 2008 at 08:14 AM PST #

Another reason for extension methods.

Those that think that the idea does nothing except move around methods are dead wrong.
If the sdk is going to maintain its boneheaded attachment to backwards compatibility, at least make it possible to have some kind of "backwards" compatibility on future definitions of interfaces.

I can think of two or three instances on the jdk myself.

Charsequence -> needs a getChars, doesn't have it because the engineer that made never had Data Strutures in college and never realized that getChars can be written by getChar.

The list example.

What would be really cool would someone making a sdk branch where (everything) except swing would have warts removed.
I would use the altered version in a instant.

Posted by guest on December 27, 2008 at 12:48 AM PST #

Is there any plan to submit in the proposal an idea for NotNull support, akin to

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

This tome seems a sensible improvement to provide compile time checks rather than runtime failures or poluting code with asserts.

Personally I think the @NotNull annotation would achieve the same thing and be more flexible. You could envisage other assertion based annotations also i.e. @Signed or @Range etc, which could enable the developer to infer more to the compiler that the currently can, which would therefore reduce chance of Runtime issues.

The paradigm of adding more power to the compiler is one of the advantages of Generics and I think anything thats enable the catching of errors earlier (compile time) would be good.

Posted by Liam Knox on December 29, 2008 at 06:11 PM PST #

@Liam,

Questions about whether Stephen plans to submit his proposal should be directed to Stephen of course :-)

However, having the language and compiler track nullness and non-nullness is a type system change and nearly any type system change would be larger than small.

I'd prefer to see the problem of null tracking addressed using enhanced annotation processors with JSR 308.

Posted by Joe Darcy on January 01, 2009 at 10:51 AM PST #

@Joe

Thanks for the response, I was unaware of this JSR and will take a look. Agreed in hinesight this is no small change.

Posted by Liam Knox on January 02, 2009 at 08:37 AM PST #

I want closures in JDK 1.7 !!

Posted by Morten on January 13, 2009 at 03:02 AM PST #

Here's a simple addition: make the number comparison operators ">", "<", etc., work on any type that implements Comparable. I've seen too much verbose code that confuses the return value from compareTo() when c1 >= c2 would be much easier to read.

It gets a little tricky with autoboxing/unboxing, but since new Integer(3) < new Integer(5) and 3 < 5, it shouldn't really make any difference.

The only remaining confusion is that because == will remain an object identity comparison, not an invocation of Comparable, c1 >= c2 && c1 <= c2 would not necessarilly imply that c1 == c2. Hopefully it will imply that c1.equals(c2).

Posted by Timothy F on January 13, 2009 at 11:33 PM PST #

@Morten,

Wanting something is often rather easier than obtaining it.

Before generics were added to the platform, there was extensive experimentation and exploration of various ways parameterized types could be incorporated. In particular, the larger Pizza proposal pointed the way to the smaller GJ one, which served as the basis for how generics were eventually added.

I think work should continue refining and simplifying closures proposals for Java for consideration in post-JDK 7 platform versions.

Posted by Joe Darcy on January 14, 2009 at 03:21 AM PST #

A simple change: make the keyword "try" optional. Any block can have catch or finally clauses.

Posted by Tbee on January 28, 2009 at 10:03 PM PST #

I have a proposal on metaprogramming for java. it can be done on token and AST level, depending on how obtrusive changes you can accept.

http://mahogny.areta.org/temp/javametaproposal.txt

it makes things possible without resorting to bytecode hacking, such as automatic getters/setters, heavy performance improvements and syntactic strength beyond c++ templates.

AST level metaprogramming done the right way will not even affect current parsers nor typecheckers. but some of the real gold requires token level metaprogramming.

Posted by Johan Henriksson on February 03, 2009 at 05:03 AM PST #

Allow "default" as the modifier for default visibility.

Posted by Adrian Kuhn on February 11, 2009 at 04:19 AM PST #

I am a Java programmer on the MIPAV medical image package at NIH. Icould only ask NIH for permission to join the JCP if I could work on either of both of 1.) long indexing of arrays and 2.) extended precision of integers and floats. A group of medical researches at the National Institutes of Health are currently producing 59 slice 3210 X 2881 ARGB files that require 3210 X 2881 X 59 X 4 bytes = 2,182,530,360 bytes. Java uses 32 bit signed integers to index arrays so the largest index an array can have is 2\*\*32 – 1 = 2,147,483,647. The researchers are planning to increase the file size from 59 slices to several hundred slices so the margin by which Java is inadequate will quickly increase. The advent of HDTV also means that all sorts of video images will be dramatically increasing in size. Java will quickly cease being a major programming language if it does not meet this important need. This should be an extremely easy change to make in Java since it only requires replacing 32 bit ints with 64 bit longs. A Java program doing a best parameter search failed because I could only use 64 bits rather than the full 80 actually available on the processor. This is another area of major scientific importance where Java is falling short. While Java does have a BigDecimal class to allow extended precision, BigDecimal cannot be used with many commonly used scientific functions, such as a sine or Bessel function. Please let me know if I can make a contribution towards either or both of these problems.

Posted by William Gandler on February 12, 2009 at 11:21 PM PST #

I'm not certain if this counts as a 'small change' but I would like to see the addition of a destructor.

My suggestion is the addition of an interface similar to Serialize but called Destructor.

A class which implements the Destructor interface would need to implement a 'dtor' method (or some other appropriate name).

The class would then need to be referenced counted and the 'dtor' method called when the class goes out of scope.

This method would allow existing code to operate as is. It would have no impact on garbage collection for class without the Destructor interface and would finally allow java programmers to stop writing ridiculously convoluted catch blocks to try and clean up resources more naturally handled by a destructor.

This one change would have a significant impact on the number of lines of code required to handle any resource. It would also reduce the number of bugs caused by failure of programmers to free resources.

Its time java had a destructor.

Posted by Brett Sutton on February 16, 2009 at 10:36 AM PST #

@Brett,

We have no plans to add C++ style destructors to the language. In C++, destructors leverage the different "storage classes" of variables to allow the destructors to be called when a variable goes out of scope. However, in Java all objects are logically created on the heap, rather than some being limited to the stack, so while going out of scope is well-defined for a variable in Java, a Java object has a separate lifetime not necessarily tied to the lexical scope of where it was created.

The dtor method as you've described is functionally the same as the existing finalize method on Object, with all its attendant problems and limitations.

Posted by Joe Darcy on February 17, 2009 at 02:58 AM PST #

I understand the difference in storage classes with respect to variables and while I don't claim to be an expert on language implementations it doesn't however appear impossible to me to create a new class of classes which are managed differently.

This may be difficult but I don't believe that that is a reason to continue ignoring this very severe limitation of the language.

The lack of a destructor is responsible for countless millions of additional lines of code being written each year and even worse, countless numbers of bugs associated with the extra code and of course the whole class of bugs associated with not freeing resources.

Its really time that the java community solved this problem, rather than saying its just too hard.

The cost to the development community (and to the business' that run java applications) due to the lack of this feature is considerable.

When making judgments about what features should be included, the core criteria should be around cost and bug reduction. On both of these criteria destructors rank very high.

I don't see any feature on this page which would provide such a large payoff as the implementation of destructors.

Thats my two cents worth. Does anyone else support my position?

Posted by Brett Sutton on February 17, 2009 at 08:45 AM PST #

@Brett,

The design of Java assumes garbage collection is available as the primary resource reclamation mechanism. If your resource reclamation can map into garbage collection, things work fairly well and naturally benefit from the many ongoing engineering improvements in that area. If your resources have a more block structured life cyle pattern (open files, etc.), then there is not a very elegant solution in Java today. Finalizers have serious limitations and while nested try-catch-finally blocks are possible, they are verbose and tricky to get right.

While block structured resource reclamation is a challenge in Java, adding destructors is definitely not a viable solution for Java. (Other solutions might be possible.) A basic design decision in Java was the uniformity of storage allocation; everything goes on the heap and references are ubiquitous. Revisiting such decisions later is impractical. This impractically is also seen in C++. C++ assumes a much lower level access is needed, which makes adding GC difficult. Smart pointers implementing reference counting is not a substitute for good GC; besides being hobbled by cycles, reference counting has high overhead and poor locality. Conservative collectors are by definition imprecise.

Given the relative use of Java versus C++ over the last decade, the set design decisions made in Java have demonstrably allowed very large systems to be built and deployed despite the existing limitations of the platform and the availability of alternate environments.

Posted by Joe Darcy on February 19, 2009 at 01:57 AM PST #

@William,

Yes, given the expansion of commonly available RAM and disk sizes, perhaps it is time to consider ways of providing 64-bit indexing of arrays or array-like data structures. I say array-like since if language support is added to use the indexing operator, [], with system-defined and user-defined classes, then "big collections" data structures could be written with or without native 64-bit array indexing. There would be a few compatibility issues around changing the size of array indexes, but I don't think there would be anything insurmountable. Other than the syntax, I generally prefer Lists to arrays since Lists have more flexible functionality (immutably, growable, etc.) and work better with the generified type system.

With my "Java Floating-Point Czar" hat on, the 80-bit format on x86 processors has been of long interest. Many years ago when I first started working on Java a hot topic was how to get \*exactly\* reproducible pure double semantics given some well-intentioned but unfortunate design decisions in the x87 register stack. While that problem was solved long ago, both Intel and AMD have since effectively deprecated the 80-bit format in preference to SSE's small SIMD vectors, 4 floats or 2 doubles. For example, 64-bit operating systems are \*not\* required to preserve the x87 register state on context switches; although the Unix calling conventions do preserve this state.

There are various techniques to simulate higher precision floating-point using plain double operations; I list a few references in my old JavaOne bof slides:
"What Some People Using the Java(TM) Programming Language Want to Know About Floating-Point Arithmetic "
http://blogs.sun.com/darcy/resource/J1_2001-BOF-0526.pdf

There has been some prior work to write transcendental function libraries for decimal types, but the most we might add to the JDK anytime soon is BigDecimal.sqrt.

On an academic note, my master's thesis "Borneo" (http://www.jddarcy.org/Borneo) designed language extensions to Java to more fully support IEEE 754 floating-point, including a new primitive type "indigenous" that would either map to 80-bit double extended on x86 platforms and to double everywhere else. One tricky bit was coming up with an encoding of constants in the class file so that full-precision correctly rounded values would be computed quickly on either style of platform.

Posted by Joe Darcy on February 19, 2009 at 12:40 PM PST #

While it may seem related to general arithmetic improvements, at least where accuracy is concerned,
those to java.util.Currency and getting at least a comparable set of types .NET has for over 6 years now is a bit different:
http://www.michaelbrumm.com/money.html
shows a proposal which .NET accepted and got it introduced into V2.0.

ICU4J and other projects, even JUnit as far back as 1999(!) introduced a simple Money and Currency class, but it never made it from Unit Tests to real Product ;-/

While the Financial Industry may not be saved by this either, once it comes up again from its self-inflicted crisis, such a step would not only improve Java's chance to survive against competing platforms which have such types already.
It would most importantly avoid banks and other financial institutions of having to reinvent that wheel over and over again.

Posted by Werner Keil on February 23, 2009 at 11:52 PM PST #

Hi Joe,

Do you think @Nullable or @NotNull annotations or their analogues can make it to JDK 7?

It would reduce repetitve null checks through out the method hierarchy.

To enforce not null constraint: you could do

public void doFoo(@NotNull Bar bar) throws Exception {
...
}

or vice versa

@Nullable
public Object doSomething(@NotNull Foo foo) {
..
}

Posted by Karthik Krishnan on March 02, 2009 at 09:21 AM PST #

Back in the days of JDK 1.0, I wrote an esssay on what the successor to Java would like like. Some of the features I requested, such as enums,
are now part of Java. It is posted at:
http://mindprod.com/jgloss/bali.html

The big one I think we need now is Eiffel/Delphi-like properties to tidy up the syntax of getters and setters. It is too difficult to flip from variable to getter/setter. Getter/Setter is clumsy, verbose and obscures program logic.

Posted by Roedy Green on March 03, 2009 at 04:02 AM PST #

How about some annotations for thread safety? I think these would greatly enhance the documentation of the language.

The set from Java Concurrency in Practice would be acceptable.

@ThreadSafe
@NotThreadSafe
@Immutable
@GuardedBy(String)

Their use is explained in Appendix A of that book. I think it would be a big benefit to all Java developers to have a single, standard set of notations for thread safety. These annotations should appear in some for in the standard Javadoc too (I'm not sure how. Surprise me.)

Posted by Mark Space on March 03, 2009 at 07:43 AM PST #

@Werner,

The addition of classes modeling Currency would not be a language change, just an addition to the libraries.

Posted by Joe Darcy on March 03, 2009 at 09:52 AM PST #

@Karthik,

It is possible a subset of the sort of annotations being defined by JSR 305 could be included in the platform, but I'm not sure how active that project is at present.

Posted by Joe Darcy on March 03, 2009 at 09:55 AM PST #

@Mark,

The addition of annotations for thread safety would not be a language change. The correctness properties of such annotations could be checked by an annotation processor or other tool that can perform extra-linguistic checks.

Posted by Joe Darcy on March 03, 2009 at 09:58 AM PST #

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