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. -Joe Darcy [1] "Project Coin: Small Language Change Proposal Form Available" http://blogs.sun.com/darcy/entry/project_coin [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 On Sep 10, 10:12 pm, Dick Wall <[email protected]> wrote: > Well - back from a mini "vacation" and what a lot got stirred up. I > wanted to clear a few things before hopefully getting together with > Joe and anyone else interested next week to talk through the rest. I > will keep comments short here, mainly due to time, but I am sure this > will not be the end of the story. In brief: > > My comments about "being told they can't" were actually uttered with > the JCP and not Sun in mind - Joe - you added the [by Sun] modifier to > the end (and I find that willingness to claim the link interesting as > well). However, later in the same article you mention " 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". I don't know which "we" you are > referring too here, but this is definitely the source of the > frustration that leads to energetic and talented developers to work > outside the traditional parameters and come up with ideas like Lombok. > I completely stand by what I say - I have heard "we" just say no to > ideas like properties and closures to Java with my own ears, so it's > little wonder people find other ways. > > As listeners to the podcast will know, I am firmly behind Scala as an > alternative, and it is an alternative that suits me well personally. I > applaud efforts like Lombok and others though, that help improve > things and *should* keep everyone happy (after all, they are optional > and do not change the core platform or libraries), and yet many of the > same "we" that are against change in Java also seem to be against > Lombok or even Scala when I talk to them for any length of time. > > The last point I want to make, and the one I find hardest to swallow, > is the inherent assumption that unless someone has the skills or > willingness to work on a prototype of their own, they should not have > an opinion or at least should not be surprised if that opinion is > ignored or refused. > > Let's think about that another way. We are all developers here (well, > I would imagine most are that are reading this). If I applied that > attitude to my own job, the scientists and other subject matter > experts (who frankly know a lot more than me about the stuff that > matters) would never get what they need to do their job. I would be > insisting that they write up a prototype before I would implement a > solution for them. It is my *job* to translate those wishes into > actuality for them. That is the role of a software developer. In other > words, they are my customers, and their opinions are actually far more > important than my own, since they know what they want out of a genetic > calculator, or lab sample tracking system, or whatever else. Can I do > everything they want - well, no - I am resource limited just like > yourselves, but will you ever hear me tell them that they absolutely > can't have something unless they do it themselves, no you won't, nor > will I discourage them from working on something themselves. > > Any time I hear someone working on a compiler telling a developer that > they don't need that feature or they don't understand what they are > asking for, I cringe. The people using the Java language likely at > least have a clue what they need - maybe you can't listen to a single > voice, but when enough people ask for something, even if they are not > language experts, surely you should still listen? It is great that you > guys are language and compiler experts, for the reason that it frees > me and others like me to do what we need to do (could you write a > human genome risk calculator?). My answer for much of my recent work > has been to use Scala, as that solves my problems and meets my needs > much better than Java does now, others will find their own way, but > requiring everyone to submit prototypes before a proposal will be > considered I think is just a handy excuse to retain the status quo, > and honestly you can't stand in the way of progress - it will simply > find another path. > > I look forward to talking through these points in more detail soon. > > Cheers > > Dick > > On Sep 2, 8:44 pm, jddarcy <[email protected]> wrote: > > > 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." > > > 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 not does 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 2005, 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. > > > 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() {}; > > > �...@proofofconceptproperty > > protected int property1; > > > �...@proofofconceptproperty(readOnly = false) > > protected long property2; > > > �...@proofofconceptproperty > > 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 > > ... > > read more » --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/javaposse?hl=en -~----------~----~----~----~------~----~------~--~---
