5 Apr 19:10
Fwd: final Groovy JSR?
From: Guillaume Laforge <glaforge@...>
Subject: Fwd: final Groovy JSR?
Newsgroups: gmane.comp.lang.groovy.jsr
Date: 2008-04-05 17:10:13 GMT
Subject: Fwd: final Groovy JSR?
Newsgroups: gmane.comp.lang.groovy.jsr
Date: 2008-04-05 17:10:13 GMT
Wasn't delivered. ---------- Forwarded message ---------- From: Bill Shannon <bill.shannon@...> Date: Fri, Apr 4, 2008 at 11:59 PM Subject: Re: final Groovy JSR? To: Guillaume Laforge <glaforge@...> Cc: jsr-241-comments@..., Groovy JSR <jsr@...> Guillaume Laforge wrote: > On Sat, Mar 22, 2008 at 8:24 PM, Bill Shannon <bill.shannon@...> wrote: > > > [...] > > You need a spec that's sufficient for someone else to implement > > Groovy support without reference to your code. I don't know that > > much about Groovy, but you might want to split the spec into a > > language/compiler portion and a runtime portion (assuming runtime > > support beyond what's in Java SE is needed). > > > > What do you mean by language/compiler portion, and runtime portion exactly? > I just want to be sure I understood correctly. > For the language part, we need to explain the semantics of the > language, its grammar, etc. > For the runtime part, you mean things like the libraries? ie. a > closure class, a GString class, etc. > Is that what you meant? > Yes, exactly. > Back on the level of integration mentioned above, and on this > portability / interoperability aspect, Groovy mandates a seamless > integration with Java. But does it mean we'd also mandate a perfect > interoperability with other Groovy implementations? > I think it would be better if you did, but it's up to you to decide. > The fact Groovy is a dynamic language, with a MOP, a double dispatch > system, means that we rely on some proprietary APIs for generating > bytecode, for handling method calls, doing some clever call site > caching techniques, etc. > > If we'd choose to totally specify these aspects, it'd mean that we > couldn't extend Groovy or improve its performance by introducing other > improvement techniques or that we could evolve the underlying code > generation classes. > > Is it okay if we dont specify these to avoid restraining further > development, perhaps at the cost of making two compiled Groovy classes > incompatible if compiled with two different compilers? > > Obviously, it's a problem Java doesn't have since it's a statically > compiled language. > You're allowed to make that choice. It's up to your expert group to decide whether that's a good choice. Personally, I think this might be acceptable for a first release, but long term it will limit acceptance of Groovy. But you should work through the scenarios for how you expect people to use Groovy to see if it will be an issue for you. For example, do you expect people to write libraries using Groovy, which they would distribute as jar files? > > > In addition to the actual tests in the test suite, you get to decide > > what the rules are for running your test suite. Do people have to > > run the binaries in your test suite? Are they allowed to recompile > > your test suite with any arbitrary compiler? Can they modify the tests > > in your test suite? Are they allowed to extend the Groovy language or > > Groovy APIs to add their own value-added, non-standard features? What > > exactly is considered "passing" your test suite? If someone questions > > whether tests in your test suite are correct, how do they interact with > > you to get a fix? > > > > And where these rules should be explained? In the TCK itself? > We include them in the TCK User's Guide. > > > We have a set of rules we use for all Sun TCKs, and we can give you a > > template you can start with for these compatibility test suite rules. > > > > I'd be interested in seeing these rules. > Let me figure out how to get them to you. > > > Of course, we also have an (open source) test suite harness, but you're > > free to use whatever harness you want. The major advantage of using > > our harness is that it makes it easier to integrate your TCK with a > > Java platform TCK, if your JSR were to be included as part of a Java > > platform specification. That may not be an issue for you. > > > > Have you got something in mind here?(ie. integrating Groovy in the JDK) > No, I didn't have anything specific in mind. This has been an issue for a few other JSRs, but I don't expect it to be an issues for you. We're very interested in having Groovy work well with GlassFish, but I don't think we'll be proposing to include it in Java EE or Java SE anytime soon.
RSS Feed