I am looking forward to our discussion in person hopefully tomorrow (Wed) after the languages summit. We'll bring a recorder, of course so the listeners get the benefit of hearing you directly. We're all huge fans of yours Joe, but of us 4 - probably Carl is the only one you could label as a "compiler guy" and capable of building a prototype of these things. We all know languages very well, and understand the complexity of implementing them.
There is however, a very big difference between looking at a language change from the perspective of a language implementor vs a language user. In any case, I look forward to our discussion! - Joe (the other Joe) 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 --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
