Joe, I think a very (_very_) large problem with The Kitchen Sink
Language, kijaro, and the open sourced JDK is that you fundamentally
can't solve your own problem with it.
There are exceptions, but the vast majority of java programmers I know
of that are interested in developing their own language features use
an IDE. The reason is fairly simple; people with the ability to reason
about which features they'd want in a programming language rightly
think java is beyond cludgy with a dumb editor. They use the smart
IDEs - generally eclipse, netbeans or IntelliJ, because those source
editors are pretty much the most advanced thing out there, for _any_
programming language. In other words, I firmly believe java would have
died a long time ago if it wasn't for the IDEs. It's no accident,
either; the way java works means that IDEs can do an extraordinary
amount of work for you, far more than in languages such as python,
where refactorings use a lot of weak raw string searches and
guesswork.
All of which is nice, but makes projects like the KSL, kijaro, and
even hacking the openJDK code base not particularly useful. Prototypes
are always nice, but I honestly cannot get a good feel of a new
language feature if I'm forced to program in notepad.
That's what makes lombok so different, and that's perhaps why the
lombok discussion group already has more posts in it inside of a month
than kijaro's in its 2 years. You can actually use it, right now, on
your day to day projects, without having to completely change your
development environment (including IDE, build scripts, etcetera).
Well, not _entirely_, you must be using only eclipse and javac, and
various source-based tools like the GWT compiler and even javadoc
cannot (yet!!) interpret lombok code. But it's close enough; the pain
of having to work around lombok's inadequacies is less than the gain,
and that's of course the key factor.
I'd also like to state my support for Jess Holle's very astute
observation that the first serious attempt to build a fully specced,
fully prototyped proposal (BGGA) got a rather lukewarm response from
sun. The BGGA proposal didn't just have an excellent spec and
prototype behind it, it has received more community support than any
proposal I've _ever_ seen in the history of java. All that, and sun
still doesn't care? That's a pretty cold shower for anybody else
wanting to try what you're suggesting: Building a prototype like you
suggest doesn't at the moment seem to make a big difference in the
likelyhood of that proposal being selected for inclusion into the JDK.
It is certainly why Roel and I built lombok into what it is today;
originally we had a plan to build an alternative closure proposal
(because, for all the praise Neal ought to receive for his work on
speccing out BGGA and building the prototype, I think there's a better
way, but that's not very relevant to this discussion), building on
neal's prototype, but after the non-result of BGGA, I didn't see how
that was going to be useful. To be useful, it had to do at least 1 of
the following 2 goals:
1. Make a lot of headway in getting the proposal into the JDK, and/or
2. be usable by myself during my day-to-day programming work.
As a prototype so far doesn't seem to accomplish goal #1, and (at
least as based on a fork of javac) isn't useful for goal #2, lombok is
an eclipse plugin and a javac annotations processor hack instead. On
that note, thanks much for the APT API - it's nice. The javac API is
also quite clean, I don't really get why Jess thinks the javac code
base is 'gnarly'. It's muuuuuch cleaner than eclipse's ecj.
But, let's not get carried away here - lombok only uses a tiny little
bit of the APT API. What lombok does is fundamentally not supported by
annotation processing. We just use annotation processing as an 'in' -
a way to get our code executed so we can break public API contracts
and dig into javac's innards. As nice as the annotation processing API
is, the cost of being forced to create subclasses is far too great to
justify some relatively small improvement as multi-line strings.
It's like the pair class: There are a few gazillion Pair
implementations out there because the slight benefit of having one is
not worth the burden of adding a dependency on a library, and yet, you
do want the feature, so people work around it. These language
improvements seem similar: For every _SINGLE_ instance where you'd
want it, it's not worth the trouble of building an annotation
processor and having to deal with generated subclasses, but add up all
the times you'd actually use such an improvement, and it's very much
worth it. Lombok solves this problem. KSL/Kijaro/OpenJDK don't.
-- Reinier Zwitserloot
On Sep 3, 4:47 pm, Jess Holle <je...@ptc.com> wrote:
> All points well taken -- at least by me.
>
> I know what it's like to work as hard as you can towards something and
> be shot down by criticism that you're not doing anything or not even trying.
>
> That said, a few points:
>
> * Not all of us are compiler experts -- and javac is fairly large
> and gnarly.
> * Doing most things involving more than just compilation syntax or
> simple changes/additions to core Java classes is rather daunting
> in OpenJDK. There were large portions of some presentations at
> JavaOne outlining just how hard this is when one has to consider
> native and Java code and their memory interactions with GC, etc.
> Also, from everything I've heard, OpenJDK is still a rather gnarly
> codebase. Being able to open a top-level project in an [ideally
> free] IDE on each platform, simply hit "build" and get the same
> result as Sun, and have full code completion / navigation data
> would be a really helpful starting point... Project Maxine really
> struck me as compelling way out of many of these issues -- but it
> is in its research infancy and could have been killed for all I
> know (I never heard it mentioned by Sun folk at this year's
> JavaOne...).
> * Neil Gafter certainly availed himself of javac, OpenJDK, etc, and
> produced a BGGA prototype. After all of this work, it went
> nowhere. Various Sun folk said they simply had no resources to
> properly deal with the proposal. This has to make others gunshy
> of investing their time and effort.
> * There is also a sense that any such effort won't bear fruit for
> years -- as JDK development cycles are pretty long, JDK feature
> freezes come pretty early, and at least some of us can't actually
> /use /any feature until it is available on /all /of our platforms
> in a normal released JDK. In my case, this platform mix includes
> AIX, which automatically adds at least a year and usually more
> beyond Sun's development cycle. [Yes, this is beyond Sun's
> control and one of my major gripes with IBM -- that and their lack
> of consistency with Sun's JVM implementation.]
> * I /desperately /want a "controlled" form of multiple inheritance
> in Java ala traits or mixins. The reduction in clumsy hand wiring
> to various delegate objects is clear to anyone who has used such
> features. Java has always been extremely clumsy in this regard
> and this has been clearly evident from day one. This needs to be
> fixed! Just because Sun said no to C++'s complex, problematic,
> uncontrolled and chaotic multiple inheritance does not mean Java
> should throw out the baby with the bathwater! In this case Sun
> has repeatedly told me and others "no", with no good reason other
> than a dogmatic "multiple inheritance is bad and will never be in
> Java". This is madness. Simply allowing something like:
>
> public interface MyTrait
> {
> public Foo getFoo();
>
> public void operateOnFoo()
> {
> // default implementation calling getFoo() as needed
> }
> }
>
> would be huge -- and only requires that interfaces be allowed to
> provide implementation [and something like MyTrait.operateOnFoo() in
> cases where there is ambiguity between implementations]. One could
> also introduce a new contextual keyword of "trait" rather than
> "interface" here for clarity, but that seems unnecessary.
>
> Finally, we did discover the ability to auto-generate base classes via
> annotation processors. It's not immediately clear that this is possible
> from perusing the documentation, but this approach does open up a lot of
> doors...
>
> --
> Jess Holle
>
>
>
> 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
>
> ...
>
> read more »
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
