[groovy-jsr] Fwd: The Groovy Language Specification
There are a few points I'd like to clarify after I read your message.
1) Groovy is an OSS project: that means discussions should be held in
PUBLIC. It's out of question that discussions are held between a small
set of persons. I can't stand that, and I won't stand it furthermore.
So please, now, move all your emails to the relevant jsr mailing list.
In the past, I've lazily allowed that a few discussions be held in an
inner circle, it's been a mistake. I apologize for that. This era is
over, and it's time to keep things open to everybody interested.
Moreover, it's really not polite at all, not fair to all the Groovy
followers, affictionados and developers who put so much energy and
passion into the project. They diserve to be informed on everything
that's happening in the Groovy sphere.
You also seem to forget that the JCP version 2.6 was there to allow
much more openess than the classical "small community" language
designers are used to. Even Sun seems more open these days...
2) Groovy is not just a Java clone with some diffs. Groovy can also be
considered a standalone language, and merits to have its own
standalone specification. A GLS won't only be read by Java
professionals. Many other persons from different horizons will come to
Groovy and won't understand this diff. It'd be pretty boring to read.
You must not forget that Groovy is a language on its own, and is not
only targeted at Java guys or Java professionals.
3) I don't like the words you used to describe Jeremy's work -- even
when said in private. It's not very nice, and the words "rough" and
"backwards" are a bit harsh to my ears. And you sound a bit too
pretentious to my taste as well when claiming your past work's been
better. I don't want to diminish your own capabilities and your great
knowledge at all, but it's just that you need to carefully choose the
words you use. Jeremy's doing a wonderful work here, and you should at
least recognize that. That's not the first time I notice your
arrogance in your wording in different occasions, but I sincerly hope
you're more careful in the future about these things.
As you've all noticed tonight, I'm a bit angry! And I hope these few
words will send a clear message to the community and everyone involved
in the life of this wonderful and promising project.
John, I'm forwarding your email to the rest of the list for information.
> On Oct 27, 2005, at 1:18, Jeremy Rayner wrote:
> Hi John,
> I've been revisiting the Groovy specifications, trying to make
> it into a readable, usable document. One decision that seems
> fairly critical is that of using full specification text, rather than
> being a 'diff' of the original Java Language Specification.
> By critical you mean that a factored (diff-based) specification will fail?
> Or that a decision is needed now to avoid useless work?
> I have an initial draft of the first half of chapter 3 at this location
> http://groovy.codehaus.org/jsr/spec/AltChapter03LexicalStructure.html >
> I see that it's very rough. It's also several steps backward from
> my factored draft of that chapter; in particular, it does not address
> g-strings, whose lexical rules are remarkably subtle.
> It's very common for specifications to build on each other, rather
> than rewriting each other. Why won't it work in this case?
> (I don't regard C++ as a good precedent for us, BTW.)
> However, I have concerns over this approach, as I am mindful of
> the copyright on the JLS, from which I am sourcing vast amounts
> of information and indeed verbatim sections.
> http://java.sun.com/docs/books/jls/second_edition/html/jcopyright.doc.html >
> Yes, that was one of my reasons to start with a factored approach.
> You are making a "derivative work" from the JLS, which requires
> written permission from the copyright holder. Given that the JLS
> is one of Java's "crown jewels", a lot of people would have to be
> lobbied successfully before that written permission could be obtained.
> Here's another reason: As with the JLS, the audience for the GLS
> is implementors, teachers, book writers, and (as a reference) power
> users, not end users. All of these people will know Java, and/or be
> willing to refer to the JLS. For many of them, having the GLS repeat
> large tracts of the JLS (method resolution, generics, etc.) will be a
> distraction instead of an added value.
> Imagine a GLS without change bars, where the teacher or implementor
> must compare the JLS and GLS side by side to find Groovy's distinctives.
> Doesn't that seem like a faux pas? (It does to me.) Now, for the
> audiences I described, putting *only* the changed material into
> the specification is almost as informative, and decidedly easier
> to handle (smaller, easier to search, etc.).
> Another reason for the factored approach is practicality.
> The JLS is very large and complex, and once we start cutting
> and pasting from it, we'll be obligated to understand and manage
> every bit of that complexity. It's the same as reusing code by
> cut-and-paste instead of via an API: You lose track of your
> own changes in the sea of imported code. Granted the JLS
> has no "API", but we can (in effect) build one out of subsection
> references and English prose.
> We have enough to do (on part-time, volunteer labor) to make basic
> decisions about the language, without also managing the many
> hundreds of pages of content in the JLS.
> My quandary is that Groovy is trying to be as close to the Java platform
> as possible, and the rigour of the JLS spec should be applied to the
> Groovy platform too. But in doing so I do not want to create a GLS
> that we cannot publish due to copyright concerns.
> I'm sure we can get rigor enough (at least for 1.0) with a factored
> I would be surprised to see any evidence to the contrary.
> Could I ask you, therefore, to approach the appropriate parts of Sun
> with a request for written authority to create a specification along
> the lines of the samples above, noting that where appropriate
> we will actually be reproducing close to verbatim some areas
> of the JLS.
> Though I foresee a number of roadblocks to this, I'll ask around.
> Please be thinking of a Plan B.
> -- John
> P.S. I'm almost done with a big wiki page on scoping.
> I hope you'll all insert comments and improvements.