Java Posse #277 Feedback: Not a view from an ivory tower

The entry below is a slightly edited copy of a message I used to start a new thread on the Java Posse's Google Group, largely in response to comments make by Dick Wall in the first twenty minutes of episode #277 of the Java Posse podcast.

After listening to episode 277, I'm led to conclude I'm thought of by some as one of the "ivory tower guys" who "just says no" to ideas about changing the Java programming language.

I have a rather different perspective.

In November 2006, Sun published javac and related code under the familiar GPLv2 with Classpath exception. [1]

Shortly thereafter in January 2007, no less a Java luminary than James Gosling endorsed the Kitchen Sink Language (KSL) project. [2] In James' words KSL is "A place where people could throw language features, no matter how absurd, just so that folks could play around" since he has "... never been real happy with debates about language features, I'd much rather implement them and try them out." [3]

KSL received no significant community response.

Later in 2007, after the remaining core components of the platform were published as open source software as part of OpenJDK during JavaOne, in November Kijaro was created. [4] Kijaro is similar in spirit to KSL, but does note require contributors to sign the Sun Contributor Agreement (SCA). Before Project Coin, Kijaro saw a modest number of features developed, fewer than ten, which is also not a particular vigorous community response given the millions of Java developers in the world.

The earliest posts on what would become Project Coin mentioned the utility of prototypes, the Project Coin proposal form included a section to provide a link to an optional prototype, and I repeated stated throughout Project Coin the helpfulness of providing a prototype along with a proposal.

Despite the availability of the OpenJDK sources for javac and the repeated suggestions to produce prototypes, only a handful of prototypes were developed for the 70 proposals sent into Project Coin.

Dick asked rhetorically during the podcast whether alternative projects exploring language changes were inevitable as the "only approach given strict control exercised over the JVM [by Sun]."

IMO, such approaches are inevitable only if Sun's repeated efforts to collaborate continue to be ignored.

Classes on compilers are a core component of many undergraduate compiler science curricula. All the Java sources in the JDK 7 langtools repository adds up to about 160,000 lines of code and javac itself is a bit over 70,000 lines currently. These are far from trivial code bases and some portions of them are quite tricky, but implementing certain changes isn't that hard. Really. Try it out.

Dick says toward the end of the opening segment "If people do want to do this stuff, right now they are being told they can't."

I certainly do not have the authority to tell others what they can and cannot do. Indeed, I have advocated producing prototypes of language changes as a much more productive outlet than whining and pouting that other people aren't busy implementing the language changes you want to little avail. Others have already noted in previous messages to this group the irony of Lombok using the annotation processing facility I added to javac in JDK 6 as an alternate way to explore language changes (together with an agent API to rewrite javac internal classes!) . However, way back before JDK 5 shipped in 2004, we at Sun recognized that annotation processors by themselves would be a possible way to implement certain kinds of de facto language changes. The apt tool and later javac were always designed to be general meta- programming frameworks not directly tied to annotations; for example, an annotation processor can process a type containing no annotations to, say, enforce a chosen extra-linguistic check based on the structure of the program. [Such as the naming convention checker shipped as a sample annotation processor in JDK 6.]

As an example of what can be done just using annotation processing, long-time annotation processing hacker Bruce Chapman implemented "multi-line strings" as part of his rapt project [5]; the value of the string is populated from a multi-line comment. After repeatedly outlining how it would be possible to do so on the annotation processing forum [6], I've gotten around to hacking up a little proof- of-concept annotation processor based implementation of Properties. [7] The user writes code like

public class TestProperty extends TestPropertyParent {
   protected TestProperty() {};

   protected int property1;

   @ProofOfConceptProperty(readOnly = false)
   protected long property2;

   protected double property3;

   public static TestProperty newInstance(int property1,
                      long property2,
                      double property3) {
       return new TestPropertyChild(property1, property2, property3);

and the annotation processor generates the superclass and subclass to implement the desired semantics, including the getter and setter methods, etc. Using annotation processors in this way is a bit clunky compared to native language support, but if people want to experiment, the capabilities have been standardized as part of the platform since JDK 6.

It is technically possible to take the OpenJDK sources and construct a version of javac that accepts language extensions; after all, this is how we generally evolve the language and also how the JSR 308 changes were developed before going back into the JDK 7 code base. Additionally, the IcedTea project and the shipping of OpenJDK 6 in Linux distributions has provided an existence proof that folks other than Sun can take the entire OpenJDK code base, add various patches and additional components to it, and ship it as a product.

Given the OpenJDK sources Sun has published, subject to the license and trademark terms and conditions, anyone is free to implement and use language changes, as long as they assume the costs and responsibilities for doing so. Experimentation has long been encouraged and experiences from experiments using language changes on real code bases would certainly better inform language evolution decisions. Unfortunately, others have generally not done these experiments, or if the experiments have been done, the results have not be shared.

I also do not have the power to prevent others from using non-Java languages on the JVM or to force others to run anything on the JVM, nor would I want to exercise such powers even if I had them. Indeed, for some time Sun has endorsed having additional languages for the platform and the main beneficiary of John Rose's JSR 292 work will not be the Java language, but all the non-Java languages hosted on top of the JVM.

I do have the authority to speak on what Sun will and will not spend our resources on in relation to Project Coin, certainly a right any organization reserves to do with its resources.

If there are frustrations waiting for Java language changes, I assure you there are also frustrations working on Java language changes. For example, I find it frustrating (and self-inconsistent) that people state "I don't have technical expertise in this area" while simultaneously expecting their preferences to be selected without any contribution on their part. [8]

Finally, going back to a white paper from 1996, the design of Java quite intentionally said "No!" to various widely-used features from the C/C++ world including a preprocessor and multiple inheritance. Again since the beginning, Java admittedly borrowed features from many other established languages. [9] Given the vast number of potential ways to change the language that have been proposed, many language changes will continue to be called and few will continue to be chosen. In any endeavor there is a tension to balance stability and progress. For the Java language, given the vast numbers of programmers and existing code bases, we try to err on the side of being conservative (saying "No." by default) first to do no harm, but also to preserve the value of existing Java sources, class files, and programmer skills.

There are many other fine languages which run on the JVM platform and I expect the Java language to continue to adopt changes, big and small, informed both by direct experiments with prototypes and by experiences with other languages.

[5]; see also Bruce's


The incredible amount of work put in on the closures prototypes, which have not led to anything being added to Java 7, does rather dissuade one from wanting to spend a lot of effort on an implementation before your good selves have blessed the idea.

That said, most language changes will not require as much work as the closures prototypes did.

Posted by Ricky Clarkson on September 03, 2009 at 09:56 AM PDT #


First, there is far from unanimity in the Java community on the underlying choice of whether or not closures would be an appropriate language change for Java at this time. Second, Neal's work was acknowledged by Sun as the Silver-level winner of the OpenJDK Community Innovators' Challenge.

Posted by Joe Darcy on September 03, 2009 at 10:56 AM PDT #

These Java Posse comments are based on an outdated world and are indicative of problems in the general Java community IMHO. As Joe says, the code has been there for over two years (nearly three for javac), yet there has been incredibly little input or response given the size of the community.

If Sun were really the roadblock people make out, then surely someone would have forked the codebase by now. It's possible. It's all there under the GPLv2 + Classpath exception. I wouldn't want to see it happen and I know it's not going to happen because those who can't be bothered to even look at the code and make small patches are hardly going to start maintaining such a huge codebase.

If there's one issue with OpenJDK at present, it's not resistance from Sun but people. There's just not enough people there, reviewing patches and improving the infrastructure. Instead, patches sit on mailing lists for weeks and we still don't have things we aimed for months ago like a fully open bug database. And the reason? The community. Or rather, the lack of one.

If there were more people commenting on patches from outside Sun, if there were more people pushing against some of the arbitrary barriers currently in place, there would be more reason for Sun to exert the time and effort to change things. There isn't. From a worldwide Java community, the mailing lists show basically the IcedTea hackers and a number of other talented individuals external to Sun. Out of millions of Java developers.

It's time the community stopped whining and started acting if they really want to be taken seriously.

Posted by Andrew John Hughes on September 03, 2009 at 12:26 PM PDT #

Your frustrations are comprehensible, but so is the disappointment of many seasoned Java developers, witnessing longstanding closure wars without any substantial outcome. James Gosling wrote in September 2006: "There's an entertaining little firestorm going on over closures". Three years are a long time in our business.

In the same blog entry, James Gosling also wrote: "I have somewhat mixed feelings about closures: they are pretty complicated.", which exposes a remarkably different assessment of the skills of the Java developer community. Obviously, James Gosling thinks that the average Java developer might have difficulties mastering closures, while you expect more Java developers to hack the compiler ;-)

Posted by Karl Peterbauer on September 03, 2009 at 06:24 PM PDT #


If we expect anything resembling unanimity in the Java community before adding any major language feature, I believe Java will never have any new major language features.

The truth is that the process for adding language features to Java is opaque and heavyweight. The latter is sort of expected given the widespread usage of the language, but the former could be rectified.

In particular, it would be nice if there was a clear decision maker when it comes to these things. Most languages that evolve well have someone with a unifying vision providing guidance, which is something that Java is lacking as far as I can see.

The closures example is a good one. Things went on for many months and no-one had any idea what the official position was. You mention James Gosling as a luminary in your post, he was in favour of closures, wasn't he? As was Neal, Gilad, Peter and others. Still not enough. What is then? If people knew, they may be more tempted to contribute.

Personally, I've moved on and do all my development in Scala instead of Java whenever I can (which thankfully has been pretty often recently).


Posted by Ismael Juma on September 03, 2009 at 07:59 PM PDT #


"First, there is far from unanimity in the Java community on the underlying choice of whether or not closures would be an appropriate language change for Java at this time."

Good. That's a positive reflection on the diversity of the Java community. My point about closures is that Sun did not even appear to engage in the debate except to say no 3 years down the line. That does not encourage anyone.

On another note, is an open bug-tracker such an investment of effort? I submitted a bug report on OpenJDK at one month ago and it still does not appear on the public website. I can't really see Sun as being anything other than opaque while that kind of system is in place.

Posted by Ricky Clarkson on September 03, 2009 at 08:40 PM PDT #

I agree that people having to actually do the work. Even "hackers in the trenches" can write code and contribute it, let people play with it, get feedback, etc. The "ivory tower people tell me I don't want this" claim is just weird. I don't understand why people reason that way. It is as if they disqualify themselves beforehand from pushing the community forward. And indeed the world changed drastically when most Sun's java software related implementations became Free Software. Everybody now has the ability to fork if they wish since almost everything is available under the GPL these days. That is enormous power (and with it comes great responsibilities).

That said I can certainly see reasons for people to feel the freedom and openness could be improved. Nobody wants to fork, the community as a whole is helped by having a canonical Free Java implementation as much as possible. That is also why currently certain issues don't lead to forking to open up the processes more. The damage of forking is just bigger than making the processes more open and transparent. But it still would be really beneficial if we could make things more open and transparent around OpenJDK:

- We want a canonical implementation as much as possible, but Sun is still publishing their Java JRE/SDK products as proprietary software with a license that disallows anybody from inspecting, comparing, publishing and discussing how they changed the OpenJDK code they base their products on. Getting everybody, including Sun to play by the same rules when publishing products (under the GPL) would increase the trust of the community.

- Although the code is free, the JCP isn't. The JCP still allows publishing JSR specifications that then cannot be used by the community for working on free implementation. Sun itself is doing this, putting terms in their JSR click-through licenses that disallow sub- and super-setting, or basing implementations on Sun derived code... (which was published under the GPL remember...)

- The JCP workaround for "small public interface changes" process (CCC) still isn't transparent. In fact it isn't documented anywhere as far as I know, but people are still required to get permission from the CCC first.

- Commits require bug numbers that the community is unable to create. The public bug database is often ignored and the proprietary sun bug tracker is very hard to use and has lots of issues hidden from the community (even issues mentioned in commits, so it is impossible to judge what a bug really was and why the fix was necessary in the first place).

- Sun demands full control and all rights over any contribution through the SCA, so they are the only party that can "escape" the tit-for-tat GPL share-alike rules of the community. That means some improvements have to stay out of OpenJDK just because of this legal restriction that favours Sun above the community.

- A lot of communication still is done only in private. Although the hg repos show all commits, a lot of the discussion and patch approval process is hidden because Sun engineers are still allowed to put changes in without discussing them with the rest of the community on the public lists.

- Sun sometimes makes promises about liberating code, like the plugin and webstart for example, that then never happen. Don't promise things you are then not actually doing.

Fixing the above will certainly improve the situation and will make it easier for supporters of Sun and OpenJDK to really stand behind it as the way to push Java forward together. Then saying that "those who do the work, get to decide how the project [Java] evolves" would be really true for everybody.

Posted by Mark on September 03, 2009 at 10:31 PM PDT #

Joe, try to look at this situation from view of somebody from community, which you blame to be passive:

1. One of basic psychological properties of men is to invest time only if we have some level of assurance, that invested time will not wasted. Also note, that professionals care about own time more, than students. So, it is normal to
describe proposal, than receive feedback, than if feedback is positive: implement one, otherwise - not. So, instead asking 'why only a handful of prototypes were developed for the 70 proposals', real question are: 'why some prototypes was developed at all ?'

Also, note, that fact, that 'exists people without experience, which contribute nothing but write to project coin' does not annul fact, that exists people who can produce value, if one will be accepted.

2. Feedback, which ordinary community member received from project coin is also frustrated: naturally people want to receive in feedback some clear vision of future not only in scope on project coin, but in more general perspective.
I. e. ideally will be to receive classification by 4 cases:
- (1) proposal just no valid to be reviewed.
- (2) Sun will reject proposal 'at all'
- (3) Sun will reject proposal now for project coin but in principle it can be accepted later. I. e. under some conditions (such as implementation, .. etc) it is possible to include such feature in Java in some future during year or two.
- (4) accepted now.

Instead we have (1,2,3) in one group, so if exists people, which devote some time for real contribution in project coin, but without accepted proposals, then their motivation to devote time to Java language development now lower, than before project start, because they does not receive any positive feedback.

3. Also note, that only 2 from 7 accepted proposals was not from Sun; one of non-Sun proposal was flying in blogs near year before project coin starts; second look's like maintenance-level change. May be exists reasons, but from outside this viewed as NIH syndrome.

4. Also one of well-known characteristics of OSS, that contribitors prefer work in areas, which are interested to them, not which is needed by project owner.

So, from point of view of external developer, activity in Java language development is waste of time: if we will propose change, we have no way to receive feedback, examples from past (closures and now project coin) shown that with probability of 99% you work will be dropped.

It is possible to fix such situation (?): may be, but defining clear vision of community process.
(for now my forecasts are pessimistic).

Posted by Ruslan Shevchenko on September 03, 2009 at 10:32 PM PDT #

@Ricky: "My point about closures is that Sun did not even appear to engage in the debate except to say no 3 years down the line. That does not encourage anyone." -- Did any other major JCP member engage in the debate? Please refresh my memory.

@Israel: "The closures example is a good one. Things went on for many months and no-one had any idea what the official position was." -- Whose official position? Do you mean Sun's? I have spoken for Sun on the Java language at JavaOne for three years running and did not use the word "closure" at any point. Evidently closures do not fit into Sun's short and medium-term vision for the Java language. Nor do reified generics. Nor do multimethods. Nor do a hundred other features Sun is not currently pursuing. You should ask other major JCP members for their position on Java language enhancements.

Posted by Alex Buckley on September 04, 2009 at 05:29 AM PDT #

@Ruslan: You endlessly complain that Sun doesn't give you feedback on your proposals. If you send a proposal to a mailing list, and only a few people comment on it, then your proposal is evidently not very compelling. It might be a good idea, but it's less good than other ideas which get a lot of discussion.

Send a proposal for C# to Microsoft and see what feedback you receive.

Frankly, your primary concern is not the technical quality of a feature, but whether Sun "blesses" your feature and pushes it through the JCP on your behalf. Sun is not going to do that for most features, from you or anyone else. You will be disappointed 95% of the time if getting recognition from the JCP if your goal.

Posted by Alex Buckley on September 04, 2009 at 05:44 AM PDT #


First, everyone who participated in the coin list did so of their own free will; they choose to spend their time following the activity or contributing to it. The expectations going into Project Coin should have been quite clear; the default answer is "no," a prototype can help your case because it provides more accurate information about the utility of the change.

Of the selected proposals, only one was written by a Sun employee (Strings in switch by me) and the majority of the voluminous traffic on the coin list (around 1300 email messages just during the call for proposals period!) were not penned by Sun employees. So there was significant non-Sun involvement in coin.

To be blunt, many of the submitted proposals were simply not credible attempts by the authors of producing a useful analysis of the new feature. They were closer to a passive-aggressive ploy to have others on the list do the detailed work and hard thinking required to turn a general idea into a meaningful proposal.

That is not the arrangement offered by the Coin invitation; it is rude to expect others to spend more time "fixing" a proposal than the original author spent writing it.

Posted by Joe Darcy on September 04, 2009 at 06:05 AM PDT #

> Send a proposal for C# to Microsoft and see what feedback you receive.

Apart from the difference that C# is actually innovating on its own, they just added optional parameters due to strong demand from the community (MVP's). Of course hackers in that camp are more attracted towards Mono as it provides the best of both worlds - open source as well as innovation.

Posted by Martin S. on September 04, 2009 at 06:10 AM PDT #


There are millions upon millions of Java developers who would have to learn about closures if they were added in the platform.

I do not expect the "average Java developer" to have the skills or interest to hack the compiler. But, I don't think it is unreasonable for a vanishing small fraction of Java developers, a dozen, two dozen, to implement and experiment with new language features before they are added to the platform.

Posted by Joe Darcy on September 04, 2009 at 06:20 AM PDT #

"Evidently closures do not fit into Sun's short and medium-term vision for the Java language"

so based on this statement we can safely assume that closures & reified generics are off the plate for Java 8 ? I am very much curious who forms "Sun's Official" position. Is it a specific team an individual at Sun .. maybe you?

"C# to Microsoft and see what feedback you receive"

Most of the proposals sent to coin have already been implemented in C#.

Posted by joeJava on September 04, 2009 at 06:25 AM PDT #

@Martin S: That's good news if you're an MVP. What is Microsoft's response if you're an unaffiliated individual with a half-formed idea illustrated by confusing example code which raises a new question from every new reader?

@joe java: No, you cannot assume that. You cannot assume anything about JDK8. Planning for JDK8 will start after JDK7 is completed. The major new feature for JDK7 is the module system and the modularized JDK codebase, which will allow structural changes to the language, libraries, and VM which are impossible today.

In terms of who forms Sun's official position, it's a team effort. As spec lead for the language, I have a fairly powerful ability to say "no, this is a bad or unsafe feature" ... but what determines if features actually get pushed forward is a mix of customer demand and internal resourcing. For reference, a customer is not someone who says "+1" on a mailing list or leaves blog comments saying "How can we get this feature into Java?".

Posted by Alex Buckley on September 04, 2009 at 06:45 AM PDT #

@Alex: [?! - where I 'endlessly complain ?'].

I just tell, why spending time, participating in Java language evolution, is not attractive for external developer. It does not depend from me or some other person. If you want to draw peoples to language development, than you must know how situation is looks from other side. It's just information, nothing more. If you don't want to hear answer, than don't ask appropriative question [why community is passive].

Microsoft does not define process for external contriubution to language. [but I'm sure, that if they will define such process, they will
take into account Sun errors. Also you can build next version of process better, if will hear answers]

May be we have situation, where really Java does not need external help from community. I. e. if traditional development model is 'cathedral', you happy with this, interaction with community require adding elements of 'bazaar' and extra resources for communication. This can be also honest answer.

Posted by Ruslan Shevchenko on September 04, 2009 at 06:59 AM PDT #


1. [ 5/7 or 1/7 (?) :
let's look at first you post: [A]
and final 5 results: [B]

A.1 is B.1 (string in switch)
A.2 is B.3 (diamond)
A.3 --- is not in final 5
A.4 is B.7 (JSR 292)
A.5 [sun] (+ literals [not-sun]) is B.6

(what we have in B but not in A: B.2 (flying in blogs near year)
B.4 (maintance-level change)
B.5 (integer literals: Bruce Chapman [sun] + Derek Foster [not-sun])
So, proposals from external world is in minority.

2. Coin was good initiative and you was provide great work moderating one. If we see that exists some objective contradictions (you think that community is passive, many people from community think, that Java development is too slow), than nothing bad in analysing such points. [more, I think that analysing of pain points for each project is duty of PM].

For now is clear, that if you want to achieve some result from community, than you must think about result/effort ratio for ordinary community member. When this ratio is low, community is passive, when hight - active.

Posted by Ruslan Shevchenko on September 04, 2009 at 08:13 AM PDT #


Below is the list of accepted features sent to the coin-dev list with the author and affiliation of the proposal:

\* Strings in switch, Joe Darcy, Sun
\* Automatic Resource Management, Josh Bloch, Google
\* Improved Type Inference for Generic Instance Creation, Jeremy Manson, Google
(implementation by Maurizio Cimadamore of Sun)
\* Simplified Varargs Method Invocation, Bob Lee, Google
\* Literal improvements, Bruce Chapman and Derek Foster
\* Language support for JSR 292, John Rose, Sun
\* Indexing access syntax for Lists and Maps, Shams Mahmood Imam
\* Collection Literals, Josh Bloch, Google

The Bruce Chapman who is active on Project Coin is \*not\* the Bruce Chapman who works for Sun.

So as you can see, most of the accepted proposals were not authored by Sun. Evidently other people judged the initial list of proposals to seed the discussion to be worthy of inclusion.

Posted by Joseph Darcy on September 04, 2009 at 08:42 AM PDT #

@Joe. Thanks. You are right if not count 'mentioning in first port' form of affiliation from Sun.

Posted by Ruslan Shevchenko on September 04, 2009 at 09:07 AM PDT #

@Ruslan: Sun is not interested in the general "external developer" participating in Java language development. I do not speak for other major JCP members, but I think it's safe to say that most are interested in expert contributions only.

An "ordinary community member" does not magically become an expert by filling out the Coin proposal form. If someone filled out the form and sent it to the Coin list with no prototype and it received little discussion, then in all likelihood their proposal was no good. Maybe it was a good idea, but poorly written. The Coin community does not owe you a detailed explanation.

There are community members on the Coin list who made expert contributions. Sometimes the contribution was to refine a proposal and further support it. Sometimes the contribution was a private prototype that showed up problems with a proposal. Sometimes the contribution was to keep their mouth shut and not draw attention to a proposal they hoped would go away.

Posted by Alex Buckley on September 04, 2009 at 09:42 AM PDT #

@Alex. Sorry, I does not understand you at all here. The word 'ordinary' was used by me not as synonym of 'non-expert'.

Posted by Ruslan Shevchenko on September 04, 2009 at 10:00 AM PDT #

@Ruslan: In general, you imply that there is a class of ordinary Java developer who is interested in language development but is not a language expert. I agree that class exists. You are a member of it. Trouble is, only expert contributions are useful.

Posted by Alex Buckley on September 04, 2009 at 10:28 AM PDT #

@Alex So this is personal attack ;) Sorry, I was not expect this.

Curiously, that most of my effort in project coin was not in proposals, but in providing statistics about usage patterns of other proposals (which, as I remember, was accepted positive in mail list).

//Ahh, you attack is answer on my defence of you incorrect words about multiline strings proposal:

Ok, so now I know why Java is dying: people, which head Java are not adequate enough to live without baseless personal attacks. Ok, live in you word if you prefer. Regards !

Posted by Ruslan Shevchenko on September 04, 2009 at 10:57 AM PDT #

@Ruslan: "expert contributions" was meant to refer to proposals. I am a fan of multiline strings but your proposals were difficult to understand. However, your analyses were quite useful, and sparked good discussion. There was some question about their accuracy, but your contribution was impressive overall.

People have alluded to improvements for "next time". Clearer roles for contributors is one of them, perhaps enforced by separate lists for proposals and analyses. You are right that contributors come in different guises.

Posted by Alex Buckley on September 04, 2009 at 11:18 AM PDT #

About quality proposals: I'm sure that if we will provide 'blind test', than we will unable to separate proposal from 'experts' from 'non-experts' in you sense. My language is not ideal, but language of other proposals [some of which was accepted] was the same quality. Of course this is bad, but this is problem for both 'experts' and 'non-experts' in you sense.

//(And to prevent 'bad' submission for 'next time', good solution is qualification round before judgement 'in essence')

Sorry if my word where too harsh. Thanks for recognition for 'non-expert'-s to participate in game. At least any expert was non-expert at some point of time and may be I have chanсe ;)

Posted by Ruslan Shevchenko on September 04, 2009 at 11:54 AM PDT #

> Send a proposal for C# to Microsoft and see what feedback you receive.

Funny you should mention that. I blogged once about a frustrating API in a .NET framework library, and how its design forced me to use a reflection hack during runtime.

I was contacted by no less than the lead developer for that particular team, complete with a workaround that worked.

And, in the next version of the framework, they fixed the issue.

Posted by Jonathan Holland on September 05, 2009 at 03:26 AM PDT #

The problem is that after years of political games in the Java, OpenSolaris, MySQL etc communities around Sun, we're very skeptical that OpenJDK will endorse and accept our work.

We might be wrong.. we might be TOTALLY wrong. However, you can't just expect us to drop our prejudice over night.

I personally have tried to contribute code BACK to Sun over the years. I had patches to java.util.regex which were denied... these were simple patches to small bugs and added features. I was told they were denied as they would be added to future versions of the JDK; they never were.

I have lots of examples like this....

Anyway, it's going to take a while for Java to gain the reputation of Python or Ruby in the community.

There's just a lot of bad karma in the air...

Posted by Kevin Burton on September 05, 2009 at 05:11 AM PDT #

A whole career of submitting bug fixes to Sun and have them go no where has breed nothing but distrust. Now that same organisation wants all the control of the process and expects fully working implementations of major functionality only to ultimately say no.

Nothing changed except the sticker on the box, and with Oracle owning it all you can bet it will get worse. The JavaPosse is spot on with their remarks, major and minor features have been rejected off hand without much of a good discussion even when popular with the community at large.

Posted by Paul Keeble on September 05, 2009 at 09:59 AM PDT #

Joseph, thank you for your opinion.
The real problem actually is that, thanks to Java, we have all happily forgotten on how to use pointers and C/C++ JDK sources are just unbreakable to us ;-)

Posted by Marian on September 06, 2009 at 12:49 AM PDT #


As javac is written in Java, that shouldn't be an issue for language changes.

In fact, javac is the best-written Java code I've ever seen. (probably people who actually fix bugs in it have a different opinion)

Posted by Ricky Clarkson on September 06, 2009 at 12:51 AM PDT #


you outlined the implementation of first-class properties using annotation processors and code generation.

In fact, JPA 2.0 (Linda DeMichiel, Gavin King et al) will adopt a exactly this strategy for a type-safe, compiler-checked criteria API. This API (and the supporing tool-chain) could be substantially simplified if the Java language would support a type-safe literal syntax for methods and fields. The problem space is well understood, no need for further experiments here. I'm sure that the JPA 2.0 expert group will provide a good, feasible solution, but it will not have the elegance and power of C#'s LINQ (which requires a bunch of other language enhancements).

JSR 295 (Beans Binding) also heavily suffered from missing language features. In essence, this JSR was about keeping properties of different objects in sync, primarily for "data binding" of bean properties to UI widgets such as textfields or check boxes. This is obviously a painful task if properties have to be identified via strings and reflection (in fact, they used JSP's EL syntax). The JSR was finally abandoned, perhaps because of other reasons I don't know.

Hans Muller's JSR 296 (Swing Application Framework) had to stick to strings for associating UI widgets like menu items with annotated methods. Not a showstopper issue, but method literals would have spiced up the solution. Uh, this JSR is also abandoned...

Personal story: Most of my work time, I'm slapping a user interface (GWT in my case) around a database, with JPA and a decent data-binding mechanism as essential drivers. Some time ago, JPA 2.0 was pie in the sky, so I had to stick to non type-safe, non-refactorable JPA query strings, but JSR 295 was still alive, and I really liked many concepts proposed there. I could not use it directly, since JSP EL heavily relies on reflection, which is unfortunately not available in a GWT environment, and I really dislike the idea of using JSP EL anyway. As a workaround, I reimplemented JSR 295's core concepts, this time using apt-generated property objects. I hope that I can replace my proprietary poor man's solution soon by replacing it with the JPA 2.0 code generator. Even then, I will have only a very clunky solution compared to the built-in capabilities of C#/LINQ.

Last battle area: On the server-side, it's quite popular to use an IoC-container (e.g., Spring) to wire up the main pieces of an application, and IoC for the client is becoming a hot topic. Annotation-driven auto-wiring works in many cases, but not always, typically requiring the use of XML for defining the relationships. This piece of XML introduces yet another non type-safe, non-refactorable element, prone to a whole class of nasty runtime errors (and requiring massive additional tooling support, for example for convenient auto-completion). Current vanilla Java is way too verbose, but a concise literal syntax for methods/properties might be an enabler for a full-blown Java-only Ioc-container.

Bottom line: The need for new language features (type-safe literals for methods/fields/properties, closures and the like) does not arise from subjective, nebulous reasons such as preferring functional programming style over imperative style. It's about solving practical problems, and it is a matter of fact, that expert groups of important JSRs have clearly stated that they can only provide the second best solution because of missing language features.

Posted by Karl Peterbauer on September 06, 2009 at 04:51 AM PDT #

I believe the proposal call was finished when Gavin suggested this.

Posted by sboulay on September 06, 2009 at 11:20 AM PDT #

Maybe Java doesn't get prototypes because the brightest people already moved to greener pastures? It's not attractive to work on Java, and Sun is to blame to make it such a terrible experience.

And why should I try to move an overturning galley if there are motor boats waiting for me? And after declining closures for Java7, Java \*is\* an overturning galley, and if you want to stay on the JVM, Scala is the only reasonable way to go.

Posted by Landei on September 06, 2009 at 06:15 PM PDT #

@Landei: I don't disagree. My problem is just that I find Scala too different and academic to be a realistic candidate for next gen Java. I see a major problem with the elite using Scala for their projects whilst the remaining cubicle workers are destined to legacy Java work. I know what Ted Neward says about this issue (we'll always need people flippin' burgers), but I disagree.

Posted by Casper Bang on September 06, 2009 at 09:35 PM PDT #

@Jonathan Holland: You say: "I blogged once about a frustrating API in a .NET framework library, and how its design forced me to use a reflection hack during runtime. I was contacted by no less than the lead developer for that particular team, complete with a workaround that worked. And, in the next version of the framework, they fixed the issue."

1) You didn't send in a proposal; you blogged an idea with no expectation that anyone in particular, let alone from Microsoft, would read it. It so happens that the right engineer ended up seeing it - perhaps through luck, perhaps through an automatic alert - and had the resources to fix it in a timely fashion. This rare but plausible sequence of events is not unknown at Sun either.

2) I was referring to C# language proposals. Changing APIs is non-trivial but it is much easier than changing a language. So the question stands: How do you formally submit C# language proposals?

Posted by Alex Buckley on September 08, 2009 at 04:21 AM PDT #

"How do you formally submit C# language proposals?"

Same way as people have submitted RFE's to Sun over the years, with the community voting on it. I.e. here's C#'s Mads Torgerson (who worked with Neal Gafter on Java wildcards) responding to a proposal:

It's debatable whether that's any less formal than a mailing-list. But it certainly is a lower bar of entry as people are not asked to implement prototypes or to hush if they do not have that capability. That seems to come back to various definitions of "community" apparently going around.

Posted by Casper Bang on September 08, 2009 at 06:49 AM PDT #

@Caspar: indeed seems to have the same role as A member of the public asks "Please can I have this feature?", other people can vote, and ultimately a Microsoft/Sun employee says yes or no.

This kind of mechanism has a low barrier to entry. That's a \*disadvantage\* because your database just fills up with half-formed ideas which go nowhere.

Hence, Coin offered an \*additional\* channel for proposing language changes above and beyond those already submitted via

Since rough sketches can already be submitted to, we felt justified in having a higher bar for the additional channel.

Posted by Alex Buckley on September 08, 2009 at 09:35 AM PDT #

@Karl Peterbauer,

Taking a glass half-full perspective, annotations together with annotation processing have allowed the removal of much of the need for non-Java files like XML deployment descriptors and have enabled the development of tool chains with feasible, if not ideal, solutions to some of the problems you cite.

JavaFX has extensive language support for binding.

Posted by Joe Darcy on September 08, 2009 at 10:02 AM PDT #


"Did any other major JCP member engage in the debate? Please refresh my memory."

Yes, Google announced an official position.

Posted by Ricky Clarkson on September 10, 2009 at 06:37 PM PDT #


The text of Google's official position on Java language changes is no longer at
nor can I find it in the wayback machine. However, IIRC it was something along the lines of "experimentation should continue." The position was neither "Yes." or "No." to closures or anything else.

Posted by Joe Darcy on September 11, 2009 at 03:46 AM PDT #

BIAS DISCLAIMER - features mention below are favored by me!

The tension between backward compatibility and introducing new features seems be the problem, there are ways out of this problem, e.g.:

1. Introduce a source statement before the package statement at the start of the file, e.g. "source Java7;". This way a file that is pre-7, or lacks a source statement, can be compiled with the existing compiler, and a file that is 7 can use the new compiler. This way mixed, pre & post 7, projects can be compiled and they can pick up the correct API via the module system (this is effectively how mixed language projects work at the moment).

2. When a feature is heavily asked for, e.g. better inner classes / closures, then the minimum feature set, i.e. something like CISE plus a nifty collections library, could be implemented. At a latter date more features could be added, e.g. support for even shorter syntax, enclosing return statements, function types (structural typing), and user defined control structures if the need was still felt by the community. Some care is needed when introducing the starting proposal to ensure that it can be extended at a latter date (in the case of inner classes / closures at least this does not seem impossible).

On a more negative point, project coin was announced with various suggested ideas:

Strings in switch, more concise calls to constructors with type parameters, exception enhancements, ability to call with methods with exotic names, and (possibly) bracket notation to access collections.

The final list is:

Strings in switch, \*Automatic Resource Management\*, more concise calls to constructors with type parameters, \*simplified varargs method invocation\*, \*better integral literals\*, \*language support for Collection literals\*, ability to call with methods with exotic names (\*and rest of JSR 292\*), and (possibly) bracket notation to access collections.

The differences between the initial and final proposal lists are highlighted above. Half the final list was on the original list. This does not seem like a hugh change given the amount of discussion on project coin.

Back to the positive points. The project coin process did provide for open documented discussion of options, which as far as I can tell is well liked by the community.


-- Howard.

Posted by Howard Lovatt on September 13, 2009 at 05:30 AM PDT #

I have written a working example (For Java 5 or later) that you could consolidate the various helper method for array Arrays, Array, ArrayUtils, System etc into an OO way to be naturally available to uses of an array.
double[] values = { 5, 6.5, 2.1 };
values = values.add(3.2);
System.out.println(values); // prints [ 2.1, 3.2, 5.0, 6.5 ]

The compiler, IDEs and other tools handle this as expected.

I don't think there is much expectation that just providing a working prototype will make much difference which it comes to extending Java.
Otherwise all the features which have been added to Groovy which have been considered (as it is a super set of Java)

Providing a working prototype would have made the difference for how many suggestions... Can anyone name one?

Posted by Peter Lawrey on September 25, 2009 at 04:54 AM PDT #

It doesn't surprise me that Sun's attempts to open its projects hasn't resulted in many contributions.

I have worked for Sun, been a Java Developer for ten years, have 360 Duke Stars and if you google "peter lawrey"+java you get 9,140 hits ;)
I work as Head of Trading Technology for a hedge fund.
I must have had a few good ideas over the years. ;)
However, I have no idea whether any of the 30+ bugs/RFEs I have posted over the years have resulted in a change to the JDK and I have attempted to contribute to the OpenJDK a number of times haven't had any luck there either.

I don't even know how to query the status of reports I have made.

By comparison I have reported 30 issues in the last year on IntelliJ which is \*not\* an open source product, and 10 have been resolved.

So your frustration that there hasn't been more community contribution to the JDK is no surprise at all. ;)

Posted by Peter Lawrey on September 25, 2009 at 12:41 PM PDT #

Post a Comment:
Comments are closed for this entry.



« July 2016

No bookmarks in folder