Thanks Joe. I appreciate this response. Any chance we can get a blog
on it to spread around?
On Sep 2, 2009, at 8:44 PM, jddarcy 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's https://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 javaposse@googlegroups.com
To unsubscribe from this group, send email to
javaposse+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/javaposse?hl=en
-~----------~----~----~----~------~----~------~--~---
