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
-~----------~----~----~----~------~----~------~--~---
