> 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!
And I look forward to listening!
>
> - Joe (the other Joe)
>
> On Sep 2, 8:44 pm, jddarcy <jdda...@gmail.com> 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 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
-~----------~----~----~----~------~----~------~--~---
