Todays news that there are likely to be language changes in JDK 7 was a bit of a surprise. It seemed like the chance had passed.
Small language changed for JDK 7
Joe's post isn't very long, but it is clear.
- "I'll be leading up Sun's efforts" - so its supported by Sun
- "develop a set of ... language changes - so its more than one change
- "small language changes" - small means no closures or properties
- "we'll first be running a call for proposals" - community involvment
- "in JDK 7" - in the next version (but why does the blog not say Java 7?)
I've used this blog, and previous visits to JavaPolis (now Devoxx) to discuss possible language changes. Some have been good ideas, others not so good. The main point was to provide a place for discussion.
The next phase after that was to implement some of the language changes. This has been achieved with the Kijaro project. As far as I'm concerned, anyone can write up an idea for a Java language change, and then I'll provide commit access at Kijaro for it to be implemented in javac - no questions asked.
Expectations
So, before we all submit lots of crazy ideas and get carried away, lets remember that Sun provided some hints at JavaOne 2008. This presentation includes the following as ruled out:
- Operator overloading (user defined)
- Dynamic typing
- Macros
- Multiple dispatch / multi-methods
And the following as 'under consideration':
- Multi-catch in exceptions
- Rethrowing exceptions
The following are listed as 'long term areas of interest':
- Parallel algorithms
- Versioning of interfaces
- Delegation
- Extension methods
- Structural typing
- Pluggable literal syntaxes
So, there is already quite a wide list on the table. Plus, there were other ideas suggested at last years JavaPolis, by both Josh and Neal:
- Variable declaration type inference (for generics)
- Enum comparisons
- Switch statement for strings
- Chained invocations, even when method returns void
In addition to all the above, I strongly suspect that there isn't going to be a chance to tackle problems with generics. This is similar to closures and properties. There isn't the timesclae or manpower to tackle these big issues in the timeframe being talked about (especially now Neal Gafter works for Microsoft).
My ideas
Well, I'll mostly save those for another day. But I would like to see a proper consideration of enhancements to help with null handling. And enhancments to the for-each loop.
Saying NO!
Finally, an appeal to Sun. Many in the community are deeply sceptical of any language changes at this point. The message should be simple - people need to feel that there is a clear means to vote or argue AGAINST a proposal, just as much as to make suggestions FOR change. Although I don't expect to make much use of the facility, I know there are many that do want to express this opinion.
Summary
This is a new departure for Sun in so openly asking for ideas from the community. We need to respond and reply with thoughtful ideas for what will and will not work.
As far as I'm concerned, Java 7 should *strictly* sport improvements to the JVM, specifically tail-calls and whatever invokedynamic is called these days. I know that we've done the whole "Java should be frozen" meme almost to death, but that is legitimately what I think the best course of action would be. Oddly, this is pretty good for Sun too given their new-found infatuation with JavaFX.
ReplyDeleteLet experimental languages like Scala, Fan and Clojure take the lead on new features where development can be unimpeded by the massive bureaucratic process which now surrounds the canonical "Java". Somehow though, I doubt that is what's going to happen...
> This is a new departure for Sun in so openly asking for ideas from the community. We need to respond and reply with thoughtful ideas for what will and will not work.
ReplyDelete>
Here is a thoughtful idea:
we need no Sun-owned and -controlled Java7. The sucessor of both Java and C++ should be defined and created by an independent consortium representing both the corporate/industrial side (think of Google, IBM and Intel) and FOSS-foundations like Eclipse and Apache.
The good news: the successor of Java already exists. It is IBM's still experimental language X10. That's a program-language designed for the upcoming hardware-revolution say massive multi- and manycore computers. X10 is very Scala-like and has closures, type-inference and build-in synthax for parallel processing.
I hope that IBM together with some industrial partners gets more aggressiv in pushing X10.
ULi, so you say no to Sun but yes to IBM after all. i think what you say is silly about next Java. Even fan is a better language than X10 but subject is not a next java here.
ReplyDeleteWhat about 'very small' language changes like regexp literals and multi-line string literals ala C#?
ReplyDeleteInstead of continuously extending Java to keep up with competition how about a language extension plugin system that allows you to extend the java syntax in a standardized way. Small utility languages like regexp literals, multiline strings, embedded xml snippets, embedded sql, javafx.
ReplyDeleteLots of those small languages is really useful. If the language plugin provided syntax highlighting, error tagging, static type check then the IDE experience could be just as good as with plain java. And the integration with java would be better than any separate compiler could achieve.
JSP could be implemented as a language plugin.
I suggest that a number of mirrored digraph's to be allocated as enclosure syntax. /# #/ <% %> $$ $$ $< >$.
This is a syntax suggestion from what I had in mind.
import language <% org.scheme.JScheme %>;
import language {{ java }};
...
int n=5;
System.out.println(<% ((lambda (x) (+ x 2)) {{ n }}) %>);
Neal left Google and works for Microsoft now?
ReplyDeleteJava needs Closures and Properties. Any new language has them nowadays, as is demonstrated by JavaFX Script. If Java does not get them, it will slowly degrade to "one of the old languages that do not provide closure and property syntax".
ReplyDeleteRe "people need to feel that there is a clear means to vote or argue AGAINST a proposal"
ReplyDeleteThat's what your blog is for. Language design is NOT well suited to a democratic process.
@BoD:
ReplyDeleteRead Stephen's take on that from an entry earlier this year:
http://www.jroller.com/scolebourne/date/20080502
Hello!
ReplyDeleteI do not agree with U that foreach loop have to iterate throw map.
If u want see sample extended iterator implementation:
http://alan.umcs.lublin.pl/~lasu/LUtils.zip
I did not made all test but in final, it will support many things U need and more like Serialization.
Greetings
I guess I side with the "don't change Java the language" camp mainly because I'd like to see things like mlvm. And, besides, my favorite language of late is Groovy and it has closures... Groovy has a nifty Meta Object Protocol... and it's almost a proper super-set of Java syntax. So why is Groovy not bundled in with the rest of the JDK? If not Groovy for some reason then why not something like it? Actually, I'd love for someone to explain to me why *not* Groovy... I really would like to understand.
ReplyDeleteI'd like to see a better BigDecimal, with a literal syntax and operator overloading. I don't care much whether it's a "primitive" value type or a reference type because performance is not my issue.
ReplyDeleteI want something for currency and other business numeric requirements that is not as convoluted to use as BigDecimal. I would prefer an implementation that allows for variable precision and scale (floating point), but it absolutely needs to default to ROUND_HALF_UP, and implement the equals method in a manner that ignores precision and scale.
+1 for ability to voting for/against a feature.
ReplyDelete-1 for evolving Java democratically.
I'll be the first to admit that I don't know enough to design a language, and I've got 7+ years of Java experience.
What we need is multi-line, verbatim, string literals, like
ReplyDeleteString sql = @"SELECT *
FROM Customer
WHERE Id = 123"@;
Shawn,
ReplyDeleteWhy not Groovy? Because it makes what should be compile errors into runtime errors.
As for possibly impractically big features, I'd like to see traits.
ReplyDeleteAs far as smaller rounding of the edges, I'd like to see the exception transparency from BGGA closures. I realize BGGA as a whole is out, but just exception transparency when dealing with generics would be helpful.
Finally, as for type inference I'd like to see the ability to do:
Collection foo = new ArrayList<>();
but NOT the ability to do:
var foo = bar.onlyTheCompilerAndIdeKnowWhatThisReturns();
or even
Collection<> foo = new ArrayList();
I think this is consistent with proposals I've seen from Josh Bloch at least in the past.
Jess: The exception transparency support in BGGA accounts for most of the specification, implementation, and testing complexity. In other words, that's what makes BGGA closures "large".
ReplyDelete@BoD, Harri, Regexp literals and multi-line string literals are both probably in the small category and suitable for consideration.
ReplyDelete@Erik, I wrote up ideas for compile time pluggable syntax - http://www.jroller.com/scolebourne/date/20080502
@David, Yes Neal works for Microsoft now
@Faith, I agree that the language that most developers use should have closures and properties. I'm far from certain that adding them to Java will achieve your goals however - Java is already pretty full.
@72.254.39.144, I didn't argue for democracy. I simply argued for negative feedback to be as important as positive feedback.
@Lasu, It would be good to see a writeup of your ideas - I couldn't immediately understand it from the zip of code
@Shawn, I think Groovy is doing very well (see Devoxx whiteboards). I don't think it needs to be included with the JDK to be successful, and I think the JSR process would probably not help it at this point.
@Nathan, I believe that Sun may be soliciting library change ideas too. But they may want you to write the code and tests.
@Jess, Neal has replied on exception transparancy. On generics inference, the type being proposed is RHS inference using <> as you describe.