Re: final Groovy JSR?

[glaforge]

Hello Bill,

On Fri, Mar 21, 2008 at 7:25 PM, Bill Shannon <bill.shannon@...> wrote:

I see that the Groovy JSR has been going for about 4 years now,
and the implementation is up to version 1.5.x, but there's still
no Public Draft or Proposed Final Draft of the spec.  When do you
expect to complete the JSR?

Very good question. Actually, after a long period of hibernation on the JSR front, we're resuming work on it in the upcoming months.

But we'd be happy to have some guidance to the steps to follow, and details of the key deliverables that are expected to ship with the JSR.

So far, the RI is there, of course, in the shape of Groovy 1.5.4.
The TCK is not split from the Groovy test suites, so we'd need to find an easy way for people to reuse it if they want to develop a compatible Groovy language.
On the spec side, we have the language grammar in an EBNF and diagram form, but what is still missing is the writing of the formal specification document, beyond our online documentation or the books we've written on the topic.

--
Guillaume Laforge
Groovy Project Manager
G2One, Inc. Vice-President Technology
http://www.g2one.com

[glaforge]

Hi Bill,

Thanks a lot for your explanations.
I haven't been able to answer earlier, I'm sorry.

Some comments inline.

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?

> Do you want someone
>  else to be able to implement a Groovy compiler that generates code
>  that works with your runtime?  And vice versa?  And if the Groovy
>  compiler or interpreter needs to be available to applications at
>  runtime, how does that work and what level of mix-and-match do you
>  want to support?

Okay, it's up to us to decide the level of integration the spec
mandates or not for a language to be considered a valid Groovy
implementation. Furthermore the TCK will help ensure this.

> Very precise syntax specifications for a language
>  are critical, but you also need to specify the semantics as precisely
>  as possible.  This kind of specification is different than the
>  typical user documentation people produce; rather than describing how
>  it *does* work, you have to describe how it *must* work, in sufficient
>  detail that someone else implementing your specification will end up
>  with behavior the same as yours, without reference to your code or
>  (ideally) your implementation.  In cases where the specification isn't
>  sufficiently complete, we often rely on the behavior of the reference
>  implementation to determine what is intended, although independent
>  implementors of the specification don't really like it when we do that.

Ok, that makes perfect sense.

>  You also need a test suite that tests as much of this as you think
>  is necessary to ensure application portability and interoperability.

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?

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.

>  We all recognize that there is no such thing as a "complete" test suite,
>  and a high quality test suite is a lot of work.  You get to decide how
>  complete the test suite needs to be, and the JCP EC gets to decide
>  whether it's "complete enough" when they approve your JSR.  The more
>  likely it is that there will be independent implementations, the more
>  important it is to have a high quality test suite.  If you expect
>  everyone to use your implementation, you can probably get by with less.

Ok.

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

>  In addition to "run rules" and process issues, our TCK rules also
>  describe things that we want to be true of any implementation, but for
>  which there's no easy way to test.  Especially important to us is the
>  issue of language extensions, but you get to decide what rules you want
>  to enforce for your language.

Ok.

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

I haven't looked yet at the OpenJDK project.
Is the test harness available in the OpenJDK project?
Is there any place explaining how this test harness is working?

>  In terms of process, there's lots of information available on jcp.org.
>  You should of course produce a Public Draft specification, collect
>  comments from the public, incorporate those comments as appropriate,
>  produce a Proposed Final Draft specification, and eventually submit
>  your JSR for a Final Approval Ballot.

Ok.

>  I hope that helps.  Please feel free to ask if you have any more questions.

I'm sure I'll have many more questions along the way!

>  I'm looking forward to a final Groovy specification!  We're very excited
>  about supporting Groovy in GlassFish!

Thanks a lot for those great explanations and these kind words.


--
Guillaume Laforge
Groovy Project Manager
G2One, Inc. Vice-President Technology
http://www.g2one.com

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[glaforge]

Bonjour Liz,

On Wed, Mar 26, 2008 at 11:37 AM, Liz M Kiener <Liz@...> wrote:
>
>  Bonjour Guillaume -
>
>  It has been a while since you took over this JSR and we corresponded last.
> Your next stage for this JSR is the EDR.  You should have seen email from me
> regarding any planned stages before JavaOne.

Alright, I saw it.
It'll take me some time to get the EDR finished, and it won't be before JavaOne.

> Will you make it to San Francisco for JavaOne?

Yes.

> The PMO will once again host an EG meeting room.

Yup, I saw that, this is handy.

> I am attaching the EDR presentation for you outlining the deliverables for
> submission to the PMO.  You may want to take the opportunity to put an
> update on the Community Update Page of the JSR and send me a schedule update
> for the JSR detail page.
>
>  If you have any questions please contact me.

Merci beaucoup :-)

--
Guillaume Laforge
Groovy Project Manager
G2One, Inc. Vice-President Technology
http://www.g2one.com

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[glaforge]

On Fri, Apr 4, 2008 at 11:59 PM, Bill Shannon <bill.shannon@...> wrote:
> [...]
> > 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.

Yes, for sure, conceptually speaking, this would be desired.
For Java, this is simpler as a call to a method is directly encoded in
the bytecode.
No intermediary layer of indirection.
It then just depends on the runtime part (JDK classes, third party
libraries, etc)
But for a dynamic language, in the bytecode you'll find some calls to
utility classes handling the double dispatch.
Some of them are public APIs (which will be part of the JSR), but
others may be present that are specific to each implementation.
So we'll have to think deeper as to what we really want to make portable or not.
Tricky issue :-)

> [...]
>  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?

Right.
This has always been possible (as long as you have the Groovy runtime
on your classpath).
We can seamlessly integrate with Java, or any other alternative
language for the JVM.
But the problem comes when we have to be compatible between different
implementations of Groovy.
At the basic object level, things are just fine, but it's when you get
into metaprogramming techniques that this may be more problematic to
achieve that goal.
We'll see if it's doable or not, but I suspect we won't go as far in
the first version of the spec.

> [...]
>  We include them in the TCK User's Guide.
> [...]
>  Let me figure out how to get them to you.
> [...]
> https://jtharness.dev.java.net/

Great, thanks a lot for the link.

> > 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.  :-)

Then what's the poing of making a JSR? ;-)))

Thanks again Bill for your explanations, the links, and your fast replies!
This is very much appreciated.

--
Guillaume Laforge
Groovy Project Manager
G2One, Inc. Vice-President Technology
http://www.g2one.com

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[glaforge]

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.  :-)



> I haven't looked yet at the OpenJDK project.
> Is the test harness available in the OpenJDK project?
> Is there any place explaining how this test harness is working?
>

 https://jtharness.dev.java.net/



--
Guillaume Laforge
Groovy Project Manager
G2One, Inc. Vice-President Technology
http://www.g2one.com

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[glaforge]

Wasn't delivered.


---------- Forwarded message ----------
From: Bill Shannon <bill.shannon@...>
Date: Sat, Apr 5, 2008 at 12:40 AM
Subject: Re: final Groovy JSR?
To: Guillaume Laforge <glaforge@...>
Cc: jsr-241-comments@..., Groovy JSR <jsr@...>


Guillaume Laforge wrote:

>
> >  For example, do you expect people to write libraries using Groovy,
> >  which they would distribute as jar files?
> >
>
> Right.
> This has always been possible (as long as you have the Groovy runtime
> on your classpath).
>

 But what if the library is compiled by Foo's Groovy compiler and my
 program using the library is compiled by Bar's Groovy compiler?

 You have to decide whether this is important and/or likely.  I agree
 you can probably ignore this for the first version.

 Will this get any easier in Java SE 7 with the new dynamic language
 bytecode?




--
Guillaume Laforge
Groovy Project Manager
G2One, Inc. Vice-President Technology
http://www.g2one.com

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email