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

A follow-up entry to Dick Wall's Google Group post to my earlier reaction to Java language evolution and management concerns raised in the first twenty minutes of episode #277 of the Java Posse podcast.


Anyone can have an opinion. Having an informed opinion takes some effort. Implementing the conclusions of an informed opinion can take considerably more effort.

Project Coin != http://bugreport.sun.com/bugreport/

For many years people with ideas for language changes (and other matters) have been welcome to submit them to bugs.sun.com; there is no expectation that something other than a rough idea is required. These ideas are evaluated and there are well over 100 open "requests for enhancement" (rfes) related to language changes. I reviewed all of these open ideas before embarking on Project Coin. Many other submitted language rfes have been considered and subsequently closed.

Project Coin explicitly offered a different social contract than bugs.sun.com; beyond just a vague idea, contributors were invited to participate in the work of bringing a language change into the platform. To be clear, the abundance of open language rfes means an additional idea for language change in and of itself has essentially no value. Instead, the coin of the realm in Project Coin was the analysis of the impacts and benefits of a language change and code for a prototype implementation. Those are valuable because they are essential components of the work needed to bring a language change to the platform. The Project Coin Proposal form [1] guided the analysis and the OpenJDK langtools repository gave a starting point for a compiler prototype. People could collaborate on different aspects of a proposal and the Project Coin list explicitly made such requests for assistance on-topic. The recommendation for prototypes was not made for punitive purposes; rather it was made so that more accurate information could be gathered about the language change. Quoting a comment left by Mark Mahieu on my blog [2]:

"By the time I posted a link to a runnable prototype [of the Elvis operator] to the list, my own understanding was much, much clearer, and very different; after delving into the real detail I'd come to the conclusion that it's not a good enough fit (for Java) in the form proposed."

In contrast to this productive discourse, take the brouhaha over not including multi-catch in the Coin final five left in comments on my blog. [3] My message announcing the final five makes clear that this decision was made based on resourcing concerns rather than the merits of the idea itself. Not one of the people leaving comments full of wailing and gnashing of teeth about the omission offered to do anything to help implement the feature.

It is far easier to impose demands than to satisfy them. When there is no "cost connection" between those imposing demands and those satisfying them, ridiculous expectations can result, such as this individual [4] whose series of requests to jdk7-dev in June I will paraphrase:

"Hi. I'm some random Java developer with admittedly little technical expertise [5] and no money. I read one blog entry written by Neal Gafter several years ago [6]; despite my lack of money and admitted lack of technical expertise, I think reading that single blog entry written by someone else should imbue me with enough authority to dictate [7] how other people should allocate their resources to work on the cool Java language changes I personally want to see."

I have exactly zero respect for this line of thinking and see no reason to tolerate it.

If someone says he doesn't know what he is talking about, I believe him. I also take the next logical step of not giving much credence to his conclusions and demands.

No one is stopping this fellow or any other interested person from taking a compiler course, downloading the OpenJDK sources to javac, reading the considerable programming language literature of generics, and working on an implementation of reified generics or some other language variant. (The careful reader will note that Microsoft's papers describing reified generics in CLR emphasize how fast they were able to make List<int> go and do not focus on the performance penalty paid by List<Integer> because of the extra level of indirection between an object and its dispatch table.)

On the subject of listening to developers ideas for changes, I posted some related thoughts to the coin list back in July [8]:

"Design by committee" is often derided as an inappropriate way to manage technical projects. Simple polling about technical issues is design by committee where the committee can be arbitrarily large and any pretense of expertise in the area is removed. Therefore, polling would be a poor way to drive specific technical decisions about the Java Programming Language. One of the benefits of working in a technical field is that technical problems often have right answers, regardless of how many people agree or disagree with them.

This is not intended to be a slight against Java programmers who contributed suggestions informed by their daily experiences with the language to the Coin alias, to Sun's bug database, or elsewhere. Rather, it is a recognition that, just as being a player and being a coach are district roles requiring distinct skills, using the language and evolving it and district tasks with related but separate skills sets. Polling can provide a good indication about what pain points people are experiencing; that is an important input, but only one kind of input, to how the language should change.

Most Java programmers do not need to be language experts. This is very much a feature and not a bug of the Java ecosystem. Not having to be a language expert means Java programmers have time to be experts about other things :-)

Moreover, the responsibilities of stewardship including preserving the conceptual integrity of the platform, which does not necessarily follow from point decisions.

I don't understand who is being accused of preventing or impeding use of, say, Scala. For its part, Sun has encouraged experimentation with the Java language changes and has funded work to improve the support of non-Java language on top of the JVM too. Lack of corporate sponsorship of particular other languages should certainly not be equated to impeding their use. Conversely, Java developers are in no way obliged to participate in Project Coin or OpenJDK activities. However, if the extent of a developer's interaction with those working on the language is leaving childish comments on blogs, don't expect to have much influence over the results.

[1] Project Coin: Small Language Change Proposal Form Available
[2] http://blogs.sun.com/darcy/entry/project_coin_final_five#comment-1252023525000
[3] http://blogs.sun.com/darcy/entry/project_coin_final_five#comments
[4] http://mail.openjdk.java.net/pipermail/jdk7-dev/2009-June/000666.html
[5] http://mail.openjdk.java.net/pipermail/jdk7-dev/2009-June/000704.html
[6] http://mail.openjdk.java.net/pipermail/jdk7-dev/2009-June/000675.html
[7] http://mail.openjdk.java.net/pipermail/jdk7-dev/2009-June/000686.html
[8] http://mail.openjdk.java.net/pipermail/coin-dev/2009-July/002120.html

Comments:

Re" In contrast to this productive discourse, take the brouhaha over not including multi-catch in the Coin final five left in comments on my blog. [3] My message announcing the final five makes clear that this decision was made based on resourcing concerns rather than the merits of the idea itself. Not one of the people leaving comments full of wailing and gnashing of teeth about the omission offered to do anything to help implement the feature."

I did provide a working prototype of multi-catch in the BGGA compiler more than a year before the Coin call for proposals, and I communicated directly to you (Joe) my willingness to complete the work for project Coin (i.e. implement the feature in isolation) if it was a feature you were interested in having. As I understand your comments, it wasn't the compiler implementation you were mainly worried about. You were worried about the specification work in the type system. However, quoting from the proposal:

"To avoid the need to add support for general disjunctive types, but leaving open the possibility of a future extension along these lines, a catch parameter whose type has more than one disjunct is required to be declared final."

In short, I don't believe the proposal has any impact on the type system.

Posted by Neal Gafter on September 14, 2009 at 10:35 AM PDT #

Some time ago, I started a thread in the c.l.j.p Usenet group (<http://groups.google.com/group/comp.lang.java.programmer/browse_frm/thread/444250a94b1020c6 >) which discussed some then-proposed features for Java 7 (most of which I don't think were ever seriously considered).

While the thread did generate at times into mere attack-and-counterattack posts, I think the most useful part of the thread was a rather in-depth discussion on how operator overloading could or should work, aesthetically and practically speaking. The crux of the matter was dealing with LHS primitive operands, but, in discussing that, the notion of commutativity of operators and inverse operators (- being the inverse of +) was raised. No one came out of it with an implementation or even anything close to one, but it does go to show what thinking about implementation can do to proposals.

Oh, and if you have a nice way to fix the LHS primitive operand problem, please, let me know :-) .

Posted by Joshua Cranmer on September 14, 2009 at 11:10 AM PDT #

Wow, that's brutal.

> "Hi. I'm some random Java developer with admittedly little technical expertise [5]

He doesn't say he has little technical expertise, he says he doesn't have enough to contribute more. I think the vast majority of Java developers are in the same situation - enough expertise to make suggestions and go into a few details, but not enough to discuss the intricate details of the implementation of reified generics.

> and no money.
He doesn't mention money.

> I read one blog entry written by Neal Gafter several years ago [6]; despite my lack of money and admitted lack of technical expertise, I think reading that single blog entry written by someone else should imbue me with enough authority to...

He's probably read more than the one blog entry, obviously. And the pages for project coin had an "open call for proposals", with no requirement of expertise for the submitter, that I can find.

> dictate [7] how other people should allocate their resources to work on the cool Java language changes I personally want to see."

I thought that was the whole point of project coin: to suggest changes for Sun to make. In fact, that's the whole point of bug reports, RFEs, and expert groups: to suggest (not "dictate" - that's too strong) to Sun what changes Sun should make to Java.

I realize that Sun's now more in a "do it yourself if you really want it, I don't have time" mode, but that's fairly new. It's going to take time for people to get used to that.

Either lighten up or make it clear that you only want submissions from people who have the time, expertise, and inclination to get deep into the implementation details.

Posted by Andy Tripp on September 14, 2009 at 03:19 PM PDT #

@Andy,

The point of Project Coin was never a new suggestion box; it was to provide a venue for interested parties outside of Sun to actively participate in the pleasures and work of changing the Java programming language. Completing the Project Coin form credibly requires technical expertise; see the social contract discussion above.

However, the person in question did \*not\* send email to Project Coin and before getting started and Project Coin explicitly called out reification as a being too large for Project Coin. [1]

Instead, the email in question was sent to the general jdk7-dev list months after the Project Coin call for proposals had ended. The email received a prompt, informative, and polite response from Maurizio Cimadamore, an expert on generics reification, who pointed out basic technical flaws in the message and explained several subtler issues with adding reification to the platform at this stage. [2]

Rather than dropping the issue at this point, there was an invocation of an apparently newly-read blog by Neal. [3] When told reification, a significant engineering effort, was not in the plans for Sun (or anyone else) to work on in JDK 7, the response [4] from someone who says he "cannot contribute to technical discussions regarding the implementation or otherwise of Reified Generics in Java" [5] was to assert that the priority must be inappropriate.

The brutal truth is, if you aren't paying for an effort and you don't know what you are talking about, you don't usually get to decide what happens.

Neal later suggested that a way to have reified generics would be raise funds and hire someone to implement them. [6]

[1] http://blogs.sun.com/darcy/entry/guidance_measure_language_change_size
[2] http://mail.openjdk.java.net/pipermail/jdk7-dev/2009-June/000667.html
[3] http://mail.openjdk.java.net/pipermail/jdk7-dev/2009-June/000675.html
[4] http://mail.openjdk.java.net/pipermail/jdk7-dev/2009-June/000685.html
[5] http://mail.openjdk.java.net/pipermail/jdk7-dev/2009-June/000704.html
[6] http://mail.openjdk.java.net/pipermail/jdk7-dev/2009-June/000706.html

Posted by Joe Darcy on September 14, 2009 at 04:10 PM PDT #

Hi Joe,

First of all, thanks for the work with project coin and for trying out new ways of letting people help improve java. I know it can be a tough way to work, so I understand some frustration.

But

1) In light of your comments, it is a shame that Sun/Oracle is not better at working with people who are qualified, and put in lots of time to improve java - eg. the IcedTea hackers. http://blog.fuseyism.com/?p=83 I would be wonderful if you also took the chance to advocate improvements inside Sun/Oracle.

2) I think that your post on the 5 selected projects was not very clear that if someone stepped up and made a solid multi-catch implementation it would have very high chances of being accepted. Noone like working hard just to have their work rejected. Maybe if you re-announce that "solid multi-catch impl = almost certain acceptance" someone will step up?

Best
Anders

Posted by Anders Norgaard on September 14, 2009 at 04:18 PM PDT #

Joe,

Neal Gafter's remarks above indicate that he was willing to produce a prototype for multi-catch. Further, your remarks in http://blogs.sun.com/darcy/entry/project_coin_final_five indicate that you like the mult-catch feature. So why did you not take Mr. Gafter up on his offer? This is very disappointing.

Further, I think it's interesting that Mr. Gafter, who I certainly think should be considered an expert on this subject, doesn't think it would be as difficult to implement multi-catch as you do. It sounds to me that we're talking about only a few weeks of programmer time. If you're saying that Sun can't afford to pay for a few weeks of programmer time to add this feature, and is instead reduced to begging for outsiders to do this work for free, I'm even more disappointed. What sort of faith are we supposed to have in Java's future if this is the case, especially given that, at least to this point, the begging hasn't been that productive? Can we get a statement from Oracle regarding their intended future funding levels for the Java team?

Posted by katz on September 14, 2009 at 09:50 PM PDT #

" did provide a working prototype of multi-catch in the BGGA compiler more than a year before the Coin call for proposals"

The plot thickens ....

"In short, I don't believe the proposal has any impact on the type system"

Even more so ...

"Neal later suggested that a way to have reified generics would be raise funds and hire someone to implement them"

He brings up an interesting point. Maybe we could do the same to fund changes like multi-catch. That would solve the resourcing problem.

Posted by JavaJoe on September 14, 2009 at 10:43 PM PDT #

I though of something that would make a nice syntax enhacement for java 7 and project coin. Unfortunatly i only thought of it now.

Have a keyword like (Object ... objs) for multiple arguments, but that instead of allowing 0 length arrays, always has at least one. This can be simulated by having (Object req, Object ... objs) but leads to ugly code inside the function, and leads to javadoc ambiguity/repetition.

Have fun with this idea. I hery by declare that i had it, and the idea is in the public domain.

There.

Posted by paulo on September 14, 2009 at 11:22 PM PDT #

I hope Oracle keeps you on as Director of Developer Outreach. Using your keen logic, you've convinced me that:
1. Since I don't have compiler experience, I can't figure out what sucks about Java.
2. Strings in switch statements is really what I've needed all these years.

Posted by guest on September 14, 2009 at 11:31 PM PDT #

> The brutal truth is, if you aren't paying for an effort and you don't know what you are talking about, you don't usually get to decide what happens.

Hey, that's a big change from the first 10-12 years of Java (where "you don't know what you are talking about" means "you're a Java programmer, but have no knowledge about Java language implementation").

> The point of Project Coin was never a new suggestion box; it was to provide a venue for interested parties outside of Sun to actively participate in the pleasures and work of changing the Java programming language.

That's not the impression that this: http://wikis.sun.com/display/ProjectCoin/Home
...and this: http://mail.openjdk.java.net/pipermail/coin-dev/2009-February/000000.html convey.

Posted by Andy Tripp on September 15, 2009 at 01:43 AM PDT #

@Andy,

The basis of the modern economy is specialization of labor. That even extends to those specializing in programming in a language compared to those specializing in evolving the language. People versed in the long history of programming languages have always helped guide development of Java.

If you read the Project Coin proposal form, you'll see it is a nontrivial document to complete credibly.

Posted by Joe Darcy on September 15, 2009 at 04:07 AM PDT #

@JavaJoe: Do it! There is NOTHING stopping you. Please report back here how your publicity efforts go.

@Andy: You say "Hey, that's a big change from the first 10-12 years of Java." Are you sure? Do you really think the Java language has evolved along the lines of the thousands of RFEs filed with bugs.sun.com in that time? The #1 RFE for all of Java is design-by-contract which Josh explicitly rejected in the design of the 'assert' feature. (FYI, every time Sun's experts look at that RFE, we find a new reason why DbC is a bad idea to embed in a language.)

Ideas for language features are like ideas for startups: practically everyone has them, but the number that make it to worldwide acceptance is vanishingly small.

Posted by Alex Buckley on September 15, 2009 at 04:46 AM PDT #

@Alex,

"Do you really think the Java language has evolved along the lines of the thousands of RFEs filed with bugs.sun.com in that time?"

No, I think Java evolved along the lines of what JCP expert groups and Sun management wanted. Of all the people who had input into the decision to include any particular feature, my guess is that few of them knew any implementation details.

I realize that very few RFEs succeed. Even so, RFEs have always been the "official" way to suggest enhancements, and there was never any requirement that the submitter know anything. I realize project Coin was not meant as a replacement for RFEs, but people will treat it that way anyway because project Coin seems have some traction while RFEs don't.

Whether you (meaning "Sun") accept people's input is obviously up to you. The same goes for whom you respect. Just please explicitly say that you need to be able to discuss in-depth implementation issues.

@Joe - even with specialization, the car designer should accept advice ("make the oil filter easier to reach") from a mechanic, even if the mechanic has no clue about how to design a car.

I've looked through the proposal form before, and I agree it's tough to fill out without going through the implementation details. And I've seen people get hammered on the mailing list for not using the proper "JLS wording" and addressing all the edge cases. Again, no problem with that, I'm just suggesting you add a note: "You better be ready to talk intelligently about the implementation details, JLS wording, and corner case with Gafter and Darcy before submitting this form". ;)

Posted by Andy Tripp on September 15, 2009 at 07:26 AM PDT #

Joe,

I seemed to have failed in the intention of my post. I was trying to be constructive and offer a way forward; but all I seem to have done is upset you, this was not my intention.

I think there is an ever increasing feeling that Java is stagnating, and as a consequence many people, including myself, are starting to use other languages, like JavaFX and Scala. These are languages written from scratch; that is a hugh effort. It seems from the outside that Java is the neglected child of the JVM. How come JavaFX and Scala can both be written from scratch in the same time scale as Java goes from 6 to 7? Is the resourcing for Java really significantly less than for Scala and FX? For myself, and I assume others, I want Java to continue to grow and go from strength to strength. Hence my proposals to break the deadlock between backward compatibility and adding new features.

With regard to the community involvement, you are obviously disappointed that more people have not produced prototypes. There were some prototypes, e.g. CICE and BGGA, but these did not really advance the course of improved inner classes / closures. I can speak for myself and say that I am reluctant to invest my time in building a prototype etc. when the chances of acceptance appear to be slim; I assume from the lack of prototypes that others feel the same. You have to remember that this is not our day job, we would be doing this in our own time. People's own time is very valuable and they won't spend it unless there is going to be an outcome that is favorable (or at least likely favorable).

Anyway, I hope that the impasse between backward compatibility and new features can be broken and Java has a long and glorious future. I apologize again for upsetting you and re-iterate that this was not my intention. I think you did a really good thing in opening up the decision making to more scrutiny, and I say that as someone who did not get any of his pet favorites up!

-- Howard.

Posted by Howard Lovatt on September 15, 2009 at 05:12 PM 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