Nuff said On Fri, Sep 11, 2009 at 7:12 AM, 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 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. > > > > -Joe Darcy > > Project Coin Lead > > > > [1]http://blogs.sun.com/ahe/entry/javac_open_sourced > > > > [2]https://ksl.dev.java.net/ > > > > [3]http://blogs.sun.com/jag/entry/compiler_fun > > > > [4]https://kijaro.dev.java.net > > > > [5]https://rapt.dev.java.net/;see also Bruce'shttps:// > hickory.dev.java.net/ > > > > [6]http://forums.sun.com/forum.jspa?forumID=514 > > > > [7]http://blogs.sun.com/darcy/entry/properties_via_annotation_processing > > > > [8]http://blogs.sun.com/darcy/entry/project_coin_final_five#comments > > > > [9]http://java.sun.com/docs/white/langenv > > > -- Viktor Klang Blog: klangism.blogspot.com Twttr: viktorklang Lift Committer - liftweb.com AKKA Committer - akkasource.org Cassidy - github.com/viktorklang/Cassidy.git SoftPub founder: http://groups.google.com/group/softpub --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
