Nabble - groovy - jsr

Groovy 1.5.6 is out!

2008-04-25T11:21:20Z

Hi all,

G2One and the Groovy development team is pleased to announce the
release of Groovy 1.5.6, a bug fix release for the stable Groovy 1.5.x
branch.

A regression introduced in 1.5.5 was fixed, and 35 bugs have been
resolved (generics, MOP, and joint compiler issues, better line
information for IDE support, etc)

As usual, you can download the latest Groovy dustribution here:
http://groovy.codehaus.org/Download

And read the change log to know all the details there:
http://jira.codehaus.org/browse/GROOVY?report=com.atlassian.jira.plugin.system.project:changelog-panel

Enjoy!

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

Fwd: final Groovy JSR?

2008-04-05T10:10:29Z

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

Fwd: final Groovy JSR?

2008-04-05T10:10:13Z

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

Re: final Groovy JSR?

2008-04-04T15:33:42Z

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

Re: final Groovy JSR?

2008-04-04T14:41:04Z

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

Re: final Groovy JSR?

2008-04-04T14:38:18Z

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

Re: final Groovy JSR?

2008-03-22T06:46:48Z

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

Re: [groovy-dev] Tentative Roadmap

2007-12-17T01:40:39Z

On Dec 17, 2007 10:25 AM, Alexandru Popescu ☀
<the.mindstorm.mailinglist@...> wrote:
> Firstly I would like to thank Mr.G and Jochen for setting up such a
> detailed roadmap.

You're welcome :-)

> Now, I would like to add my opinion about it (opinion that might not
> match exactly the above plan).

At least, it's not in contradiction with the roadmap!

> I do consider that the Groovy language has become "enough" feature
> rich. IMO, the most important aspects for the future of the language
> are now more in terms of usability. I don't think I can come out with
> a nice proposal as you did, but my suggestion would be that the work
> should focus on the following directions:
>
> 1/ fixing bugs related to the 1.5 major release. This will probably
> result in a couple more minor releases.

Agreed, this is what the 1.5.x releases are for.

> 2/ focus on the performance. As discussed at GDC this mostly means
> rethinking the whole MOP, stabilizing and unifying the MOP, etc. I
> would definitely see the whole energy of the Groovy people going this
> direction only for the next period.

It's going to be a long process I suspect, as various experiments will
have to be done, lots of discussions, a nice general proposal of what
we really want, etc. So it's something that is going to be done in
parallel to the progress we make in 1.x.

> Probably the only "new" feature that I see as belonging to "usability"
> is the multi-assignment, but this is just a nice to have one, so it
> shouldn't focus on it right away (or at least I wouldn't consider it
> as a strict goal for the next immediate period).

I tried to put certain features at certain milestones, but we can
certainly reorder the priorities.
I've put multiple assignments early in the roadmap because we had
promised them in 1.1/1.5, but as they're certainly not critical, we
can postpone them to a latter release, it's not really critical.

In the new features, there are things which should be discussed for
inclusion or not.
For instance, anonymous inner classes, nested classes and co.
Initially, in the early days of Groovy, we didn't want to support them
because we found them ugly, and closures should be used more to fill
in the gap.
So, it's perhaps a debate we should have as to whether the Groovy
users really want them in the language?

Regarding other features, for instance AST Transformations, we can
already do that today, but in a more convoluted way (through the
Groovy classloader), so it's mainly about making this feature easier
to use. And for the concurrency feature, it could even just be an
additional module, instead of bloating Groovy core with yet another
big feature.

> Hope you don't mind expressing my thoughts here,

On the contrary, thanks for sharing your thoughts!

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

Tentative Roadmap

2007-12-16T15:50:06Z

Dear Groovy developers,

Now that we have released 1.5, it is time to think about the future of Groovy, by discussing its roadmap.

After some discussions at GDC#4 ( http://docs.codehaus.org/display/GroovyJSR/GDC4+Discussions), on the lists, and elsewhere, we've listed possible improvements and new features.

Jochen and myself compiled a tentative roadmap this weekend, taking these ideas into account and trying to lay them out across potential release numbers.

This is a tentative roadmap.
Certain features can be discussed, whether we do want them or not.
And there's room for moving features from one to another release.
New ideas missing can also be introduced.
So it's still pretty open at the moment.

Note that the roadmap can change across the course of time according to the progress (or lack thereof) we make on the GEPs (Groovy Extension Proposals).
It is not set in stone today, even after our upcoming discussions. The GEPs will drive us through the releases.
It is very important that we try to clearly define what we want to do in the coming releases, and not just commit blindly any cool hacks :-)
We need to have crystal clear scope and semantics for all major features.

First of all, the basic idea: instead of one huge release a year with several betas and RCs, it'd be great if we could make more frequent releases (with a few betas and RCs) every two or three months or so, but containing a lower number of major features. So ideally, we could release 1.6 / 1.x throughout the year, with a bigger 2.0 at then end of next year with a reworked MOP system.

There are three main kind of releases:
- 1.5.x will provide some patches to the 1.5 final release
- 1.6 / 1.x will introduce a few major features at each release depending on the completeness of the GEPs
- and 2.0 will focus on the reworked MetaClass runtime system and will be worked on in parallel to the other 1.x releases.

Ideally, we should try to release 1.5.1 next week, before Christmas, with the current fixes for the Ant builder, the dead lock in the class loader.
And probably a 1.5.2 when we find the concurrency issue we have on parallel environments.

Without further ado, here's the proposed Roadmap.
The GEPs will be there for defining the exact scope of the major features by giving some finer-grained details of the content of the upcoming releases.
I'll publish this roadmap on the JSR wiki.

Groovy Roadmap

Groovy 1.5.1

Bug fix release
Deadlock in GroovyClassLoader
Problem with Ant tasks

Groovy 1.5.2

Bug fix release
Concurrency issues (unless it's fixed in 1.5.1)

Groovy 1.6

Based on JDK 1.5 with Retro* version available for JDK 1.4

Make sure we can run the unit tests with the retro-weaved jar to ensure compatibility

Annotation definition in Groovy

Currently, annotations can't be defined in Groovy, only used

Multiple assignment

Define the exact scope of multiple assignment by revisiting the existing GEP page

Groovy 1.7

Upgrade to ASM 3

if necessary or deemed useful (more efficient bytecode?)

Groovy incremental compiler

Especially useful for the Eclipse plugin

AST transformations

reuse of annotations or not
exact scope of those transformations

pluggable AST transformations for advanced DSL or integration cases

Groovy 1.8

Nested Classes & Anonymous Inner Classes

The exact semantics with relationship to the MOP should be properly defined through a GEP

Groovy 1.9

Upgrade to Antlr 3

We'll be able to use the tooling support accompanying Antlr 3

Concurrency features

Define what coverage we'd like to bring

Rollback the iterator features to properly discuss them first

Work on this theme first as a module, and if deemed right, we can bring it back to groovy-core

Groovy 2.0

New MetaClass system

Benchmark test suites to track progress of performance across releases
GEP

defining the scope of changes
describing the new system
proposals of a more homogeneous system

homogenize categories, EMCs, custom metaclasses

homogenize the configuration / declaration / convetions

have per-thread / scoped EMCs (like categories)

per-module/library metaclasses

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

What's new in Groovy 1.5?

2007-12-09T07:26:27Z

Hi all,

After the announcement of the release of Groovy 1.5, as promised in
the release notes, here's a detailed article on what's new in Groovy
1.5.

Read it on InfoQ:
http://www.infoq.com/articles/groovy-1.5-new

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

Groovy 1.5 is there!

2007-12-07T15:41:12Z

Hi all,

I'm very pleased to announce the release of Groovy 1.5.

You can read the release notes there:
http://docs.codehaus.org/display/GROOVY/2007/12/07/Groovy+1.5+released

An upcoming article on InfoQ will give you a more in-depth overview of
this new version.

Thanks a lot to everybody: developers, contributors, users.
Without you, Groovy wouldn't be the great dynamic language it is today.

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

Release candidate 2 is available!

2007-11-02T13:13:20Z

Dear all,

The Groovy development team and G2One, the Groovy & Grails company, are happy to announce the new milestone of Groovy: the second release candidate is here. Just a few weeks after the first release candidate, this new version focused mainly on bug fixing, ironing out the Swing console with a nice new icon toolbar and the interactive shell, and the XML handling. You can have a closer look at the JIRA issues for more detailed information and you can download Groovy 1.1-rc-2 from the usual place.

Apart from these bugs and little improvements, we kept on increasing the performance of Groovy. As an informal benckmark, we measured the time taken by our test suites to run, and for instance, according to the Grails team, the Grails test suites executed about 40% faster with Groovy 1.1-rc-2 than with Groovy 1.1-rc-1, of course, depending on your project, your mileage may vary.

Please help us making sure Groovy 1.1 is rock-solid by having a run with this new release candidate in your projects, so that we can iron out the latest little problems that may arise. Thanks in advance for your help. Stay tuned for the final Groovy 1.1 release in a couple of weeks!

Download: http://groovy.codehaus.org/Download
JIRA issues fixed: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10242&styleName=Html&version=13792

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

RE: [groovy-user] Groovy 1.1-beta-3 released, RC-1 and 1.1-final around the corner

2007-09-21T02:25:15Z

> * The ternary operator can be shortcut to simplify a != null ? a :
> "default value" into a ?: "default value". We call it the Elvis
> operator -- a beer for those who guess why we've chosen that name.

Was it supposed to be hard to recognize the quiff? :)

Ciao, Jürgen

--
1&1 Internet AG · Brauerstrasse 48 · D-76135 Karlsruhe

Amtsgericht Montabaur HRB 6484

Vorstand: Henning Ahlert, Ralph Dommermuth, Matthias Ehrlich, Andreas Gauger,
Matthias Greve, Robert Hoffmann, Norbert Lang, Achim Weiss
Aufsichtsratsvorsitzender: Michael Scheeren

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

http://xircles.codehaus.org/manage_email

[grails-user] Groovy 1.1-beta-3 released, RC-1 and 1.1-final around the corner

2007-09-20T17:47:19Z

Dear Groovy friends,

I've blogged about the new here:
http://glaforge.free.fr/weblog/index.php?itemid=222&catid=2

and there:
http://docs.codehaus.org/display/GROOVY/2007/09/20/Groovy+1.1-beta-3+released%2C+RC-1+and+1.1-final+around+the+corner

But here it is:

Groovy 1.1-beta-3 is there, paving the way for an RC-1 in the
following weeks, and if all goes well, for 1.1-final in October, right
in time for the Grails eXchange conference that takes place in London.
This conference will also be the opportunity for the Groovy developer
team to meet for the fourth Groovy Developer Conference! With Groovy
1.1 released by then, it'll be time to think about what's going to
happen for the next major version of Groovy.

Before going through the new release, let me recap some of the nice
things that have been happening lately around Groovy:

* JetBrains released a second milestone to the wonderful Groovy &
Grails IntelliJ IDEA plugin, so be sure to check it out, as you'll
feel at ease developing Groovy with all the bells and whistles of your
beloved IDE. You've never programmed Groovy and Grails with so much
pleasure.
* IBM's ProjectZero team is also helping us improving the Eclipse plugin.
* Sun gave us access to a nice server beast so we can conduct some
high-concurrency load testing on Groovy.

So what's in this release you may wonder? Well, there are a few nice
novelties, but they should be the last ones before 1.1.

First of all, Alex Tkachman, along with Jochen, worked very hard on
improving the performance of Groovy. On some micro-benchmark seen on
the blogosphere, we even got a 100% improvement. Of course, depending
on your usage of Groovy, your mileage may vary, but let me
congratulate Alex for this great achievement.

Now regarding new features:

* The last mile of Java 5 related feature is included: you can use
and define enums in Groovy.
* The closure and map coercion to interfaces mechanism has been
extended to work on concrete classes too.
* The ternary operator can be shortcut to simplify a != null ? a :
"default value" into a ?: "default value". We call it the Elvis
operator -- a beer for those who guess why we've chosen that name.
* In the dynamic space, Graeme Rocher has been continuing
enhancing and improving the ExpandoMetaClass and has added some new
methods like methodMissing(), respondsTo() or hasProperty(). Don't
forget to check the documentation and the child pages.
* It is now possible to customize the variable resolving strategy
in closures (not yet documented), so that you can decide whether you
want to the resolution to go to the delegate first or only, to the
closure itself, or to the owner.
* Jason Dillon has been working on improving the good old Groovy
Shell (groovysh). It is still a work-in-progress, so by default, it is
not activated, but you may try it by setting a NEWSHELL environment
variable to a dummy value. Some completion is there thanks to JLine,
ANSI color makes things more friendly on most platforms (Windows being
the exception as always), and the driving idea behind those evolutions
was getting rid of the infamous "go" command.
* Romain Guy, on his side, along with the help of Danno Ferrin and
Andres Almiray. have polished the Groovy Swing Console look'n feel.
* One last nugget, some improvements have been worked on to allow
a better integration between the groovyc and javac Ant task letting
you use the javac Ant task as a sub-element of the groovyc Ant task --
however, for big projects with a lot of classes, it may be pretty
hungry for memory.

With all that, it's time to give the usual links. Apart from those new
features or improvements, we've closed a fair amount of bugs too, if
you want to have a closer look at what we've worked on, you can have a
look at the JIRA issues closed for beta-3.

You can download Groovy at the usual place: Joachim Bauman is updating
the Windows native installer (which also contains Antti Karanta's
native launcher for Windows) and he should make it available in the
following days.

One last closing word: the documentation of the website is available
too, and over those past months, the documentation climbed to about
900 pages worth of PDF export! Even bigger than the fine GinA lady!

Keep Groovying, thanks to all the developers and contributors for
their help, and stay tuned for RC-1 and 1.1 pretty soon!

--
Guillaume Laforge
Groovy Project Manager
http://glaforge.free.fr/blog/groovy

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

http://xircles.codehaus.org/manage_email

how to make new specification request.

2007-08-18T13:33:42Z

i'm working in web application projects using JSF .
i'm asked from team manager to write "module specification request" for every web module.

can anybody tell me what the content of any specification request document.

[groovy-dev] get scripting engine by file extension

2007-07-30T15:30:05Z

Hello!

I have an application where I use JSR-223 for evaluating the scripts, and I use file extension for identifying the scripting engine that is required to evaluate the script:

ScriptEngineManager scriptEngineManager = new ScriptEngineManager();
ScriptEngine engine = scriptEngineManager.getEngineByExtension("groovy");

With groovy-1.0 it works fine.
but with groovy-1.1-beta2 this code throws a following exception:

Exception in thread "main" java.lang.IncompatibleClassChangeError: Found interface groovy.lang.MetaClass, but class was expected
    at com.sun.script.groovy.GroovyScriptEngine.<clinit>(GroovyScriptEngine.java:63)
    at com.sun.script.groovy.GroovyScriptEngineFactory.getScriptEngine (GroovyScriptEngineFactory.java:87)
    at javax.script.ScriptEngineManager.getEngineByExtension(ScriptEngineManager.java:275)
    at <user code stack trace follows>

And in the version 1.0 there really was "public abstract class MetaClass" which is now "public interface MetaClass extends MetaObjectProtocol"

So the question is: is the groovy API not following JSR or the JSR engine implementations is outdated ? :)
Can anyone suggest?

Thx,
--
Anton Arhipov

[groovy-dev] Groovy 1.1-beta-2 released!

2007-07-05T15:36:10Z

Dear community,

The Groovy team is pleased to announce the release of Groovy
1.1-beta-2, yet another step on our aggressive roadmap towards the
release of Groovy 1.1 in October.

For this release, I would like especially to highlight two key
contributions to the project:

* First of all, after we've added Java 5 annotation support in
Groovy 1.1-beta-1, this time, it was generics' turn. Thanks to the
help of some JBoss developers who've integrated Groovy in JBoss Seam,
we've been able to test our support for annotations and generics, and
to make sure we would release a quality milestone to our users. Groovy
is the first alternative dynamic language for the JVM that supports
annotations and generics, so that you can integrate Groovy with any
Enterprise application frameworks like EJB 3 / JPA, JBoss Seam, Google
Guice, Spring, etc.
* Secondly, I'm very happy to report the contribution of JetBrains
to the development of Groovy. While working on the IntelliJ IDEA
plugin for Groovy and Grails, the talentuous JetBrains team provided
us with a joint Java/Groovy compiler! No more nightmare to cleanly
separate Java and Groovy code to avoid cyclic references and tedious
build configuration, you can now use the Groovyc compiler to compile
both Groovy and Java sources in a single step.

Apart from those two great contributions that we have integrated in
the project, we've worked on many other areas since the release of the
first beta:

* We have ironed out the usage of Java 5 annotations (for instance
annotations for method parameters were missing).
* As I've already mentioned, we've added support for generics in
Groovy, so that the generated bytecode properly includes the
reflection information needed at runtime by various tools such as JPA.
In the area of Java 5 features, static imports were also available in
Groovy in beta-1 to make the code even more concise and readable.
* Still pursuing the symbiotic relationship between the Groovy and
Grails projects, the Grails team has integrated in Groovy its new
ConfigSlurper mechanism to configure your applications more easily
(documentation to come on that feature soon).
* The classical for loop is now back in Groovy after a lot of user requests.
* Named parameters are also now possible on top-level statements,
without parentheses, so that expressive code can be written like in:
move x: 10.centimers, y: 8;centimeters or fund.compareWith bench:
NIKEI, over: 2.months

Apart from that, we also focused on cleaning up the Groovy grammar,
improving the code coverage and the performance of Groovy in highly
concurrent scenarios for paralle machines. Overall, roughly a hundred
bug fixes, enhancements or new features have been integrated in this
new release. On the tooling front, the Eclipse plugin recently
released version 1.0.1, while the progress on the IntelliJ IDEA plugin
has been awesome, you should also check it out.

You can download Groovy 1.1-beta-2 from the download area. You can
find the full release notes in our JIRA bug tracker.

Thanks to all users, contributors and committers for allowing us to
make this great release.

--
Guillaume Laforge
Groovy Project Manager
http://glaforge.free.fr/blog/groovy

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

http://xircles.codehaus.org/manage_email

[groovy-user] Groovy 1.1-beta-1 released with annotation support

2007-04-30T16:16:38Z

Dear all,

After Groovy was awarded the first prize of the JAX conference in Germany last week for being the most innovative and creative project in 2007 in the Java community, we're pleased to announce the release of Groovy 1.1-beta-1.

This release is the first beta release after the release of Groovy 1.0. But it's a very important release as we've been working on key features putting Groovy clearly as the de facto enterprise scripting solution. Indeed, Groovy is now the first and sole alternative language for the JVM that supports Java 5 annotations. Groovy 1.1-beta-1 also supports Java 5 static imports.

You can now use Groovy to write your EJB 3 / JPA beans, to wire your components with Google Guice, to mark your services transactional with Spring's @Transactional annotation, to develop JBoss Seam entities, or to be able to write unit tests with JUnit 4 or TestNG. If you want the best and seamless Java integration, and be able to use the latest frameworks around that leverage Java 5 annotations, look no further, Groovy is the unique solution to your scripting and dynamic needs. Whether you hack a script in your shell, or if you want to implement Domain-Specific Languages, Groovy has everything you need to make you more productive.

Of course, this release contains a nice list of bug fixes and improvements, making Groovy a very stable and viable platform on its own, or for your integration needs. You can find the list of all the bugs and improvements on JIRA.

Just to highlight some of the other interesting gems you'll find in this release, note that Groovy mocks now let's you deal with properties as well, you can group list and map elements with a discriminator closure with the groupBy() method from the GDK, the use directive now returns the value returned by the closure it is passed, and you can add maps together. All in all, minor features, but which might come in handy from time to time. A more interesting one is probably the ExpandoMetaClass from Grails has been brought back to Groovy.

You can download Groovy from the usual location. You'll be able to download the binary distribution, the source distribution, and a zip of the online documentation (over 500 pages) and the JavaDoc.

While the core Groovy team was working on the language, the Groovy Eclipse Plugin team has been making awesome progress, and the (soon-to-be-released) plugin now sports good code-completion capabilities. But we also have good news for the IntelliJ IDEA lovers, JetBrains is working full-steam to provide their own Groovy plugin, so stay tuned for additional news in that area.

A part of the Groovy and Grails team will be present at JavaOne 2007 in San Francisco to present the cool things you can do with Groovy, or how Grails reivents Spring / Hibernate development, so please come and say hi if you're around. This year, Groovy and Grails will be very well represented, there will be 8 Groovy sessions and 3 Grails sessions. Overall, twice as much as last year.

Additionaly, on Monday evening, just before JavaOne, there will be a special GroovyOne community event from 7pm to 10pm at the W Hotel organized by the fine folks from NoFluffJustStuff and the AboutGroovy community site. It will be a great opportunity to meet core Groovy and Grails developers, leads and book authors. More details to follow.

Thanks a lot to everybody involved, and on behalf of the Groovy team, we hope you will enjoy this new release!

--
Guillaume Laforge
Groovy Project Manager

Re: Fwd: JavaOne EG Meeting Room

2007-03-23T05:06:56Z

> > From: Guillaume Laforge [mailto:glaforge@...]
> > Sent: Donnerstag, 22. März 2007 7:57
> > To: Groovy JSR
> > Subject: [groovy-jsr] Fwd: JavaOne EG Meeting Room
> >
> >
> > For those who will be at JavaOne this year (Groovy / Grails developers
> > and JSR EG members), we might have a room to make a quick meeting at
> > the Argent hotel if needs be.

Will there be any conference phone facilities, as I'll be
in the UK that day

Jez.
--
Groovy Engineer http://searchgroovy.org
http://javanicus.com/blog2

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

http://xircles.codehaus.org/manage_email

RE: Fwd: JavaOne EG Meeting Room

2007-03-23T04:35:30Z

I'll be there and happy to meet everybody.

Guillaume, I guess I'm not yet an official member of the JSR expert group.
Would you mind promoting me so? ;-)

cheers
Dierk

> -----Original Message-----
> From: Guillaume Laforge [mailto:glaforge@...]
> Sent: Donnerstag, 22. März 2007 7:57
> To: Groovy JSR
> Subject: [groovy-jsr] Fwd: JavaOne EG Meeting Room
>
>
> For those who will be at JavaOne this year (Groovy / Grails developers
> and JSR EG members), we might have a room to make a quick meeting at
> the Argent hotel if needs be.
>
>
>
> ---------- Forwarded message ----------
> From: Liz M Kiener <Liz@...>
> Date: Mar 22, 2007 6:36 AM
> Subject: JavaOne EG Meeting Room
> To: SPECLEADS@...
>
>
>
> Hello All -
>
> The PMO is pleased to offer you once more this year a room at the
> Argent Hotel for EG meetings during JavaOne. The room will be
> available all week until Fri 11 May on a first come first served
> basis. You can schedule the room by sending me email with date and
> time you would like.
>
> Kind regards,
> Liz :-)
>
>
>
>
>
>
>
> --
> Guillaume Laforge
> Groovy Project Manager
> http://glaforge.free.fr/blog/groovy
>

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

http://xircles.codehaus.org/manage_email

Fwd: JavaOne EG Meeting Room

2007-03-22T00:56:31Z

For those who will be at JavaOne this year (Groovy / Grails developers
and JSR EG members), we might have a room to make a quick meeting at
the Argent hotel if needs be.

---------- Forwarded message ----------
From: Liz M Kiener <Liz@...>
Date: Mar 22, 2007 6:36 AM
Subject: JavaOne EG Meeting Room
To: SPECLEADS@...

Hello All -

The PMO is pleased to offer you once more this year a room at the
Argent Hotel for EG meetings during JavaOne. The room will be
available all week until Fri 11 May on a first come first served
basis. You can schedule the room by sending me email with date and
time you would like.

Kind regards,
Liz :-)

--
Guillaume Laforge
Groovy Project Manager
http://glaforge.free.fr/blog/groovy

[Liz.vcf]

begin:vcard fn:Liz M Kiener n:Kiener;Liz M org:;JCP Program Management Office adr:USCA 15-108;;4150 Network Circle;Santa Clara;CA;95054;USA email;internet:Liz@... title:Program Manager tel;work:+1 510.550.4353 tel;fax:+1 510.550.4353/+1 408.276.7129 url:http://jcp.org version:2.1 end:vcard

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

http://xircles.codehaus.org/manage_email

Re: One easy way to improve performance a lot

2007-02-12T23:32:24Z

Yeah, now I'm using JSR223 Groovy-Engine which can cache scripts, so I don't care whether Groovy will cache scripts or not :)
Thanks for your response :)

Jochen Theodorou wrote:

Daniel.Sun schrieb:
> Hi all,
>
> I found more than 90% time is spent in compiling.
> So I think caching these latest compiled groovy class will improve
> performance a lot.
> The cache pool should be provided with gdk and instance of the pool should
> be store in a Thread which is started when we run our application.
>
> pseudocode as follows:
> find the requested class from cache.
> if (the class is cached) {
> if (modifying timestamp of groovy script file > modifying timestamp of
> class's groovy script file which is also in the cache) {
> recompile the groovy script file and cache it
> } else {
> return the requested class
> }
> } else {
> compile the groovy script file and cache it
> return the requested class
> }

that's how it is working, or not?

bye blackdrag

--
Jochen "blackdrag" Theodorou
Groovy Tech Lead (http://groovy.codehaus.org)
http://blackdragsview.blogspot.com/

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

http://xircles.codehaus.org/manage_email

Re: One easy way to improve performance a lot

2007-02-12T07:17:55Z

Daniel.Sun schrieb:

> Hi all,
>
> I found more than 90% time is spent in compiling.
> So I think caching these latest compiled groovy class will improve
> performance a lot.
> The cache pool should be provided with gdk and instance of the pool should
> be store in a Thread which is started when we run our application.
>
> pseudocode as follows:
> find the requested class from cache.
> if (the class is cached) {
> if (modifying timestamp of groovy script file > modifying timestamp of
> class's groovy script file which is also in the cache) {
> recompile the groovy script file and cache it
> } else {
> return the requested class
> }
> } else {
> compile the groovy script file and cache it
> return the requested class
> }

that's how it is working, or not?

bye blackdrag

--
Jochen "blackdrag" Theodorou
Groovy Tech Lead (http://groovy.codehaus.org)
http://blackdragsview.blogspot.com/

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

http://xircles.codehaus.org/manage_email

One easy way to improve performance a lot

2007-02-08T21:16:06Z

Hi all,

I found more than 90% time is spent in compiling.
So I think caching these latest compiled groovy class will improve performance a lot.
The cache pool should be provided with gdk and instance of the pool should be store in a Thread which is started when we run our application.

pseudocode as follows:
find the requested class from cache.
if (the class is cached) {
if (modifying timestamp of groovy script file > modifying timestamp of class's groovy script file which is also in the cache) {
recompile the groovy script file and cache it
}
} else {
compile the groovy script file and cache it
}
return the requested class

Best regards,
Daniel.Sun

Re: Improvement in handling exception

2007-02-08T04:13:21Z

John Wilson schrieb:
[...]
> I do, however, think that we could improve our Exception handling whit
> respect to Java interfacing. If a groovy method throws a checked
> exception but does not have a throws clause then a Java method which
> calls it cannot catch the exception.

a reason to declare that Exception in the throws clause

> The Groovy compiler can tell that a
> checked exception is thrown and could, in principle, put the throws
> clause into the generated bytecode.

sure yes... when I move the exception throwing code into another method,
then what? I don't think we should do that... too much magic and for
APIwriters it is a bad thing to have these Exceptions in there without
their knowledge. And if I write a method m1 that calls a method m2 that
throws a checked exception e1 and if I call this method m1, then how do
I catch e1? When I think about IOEceptions, then I think it is not
reasonable to automatically put anything into the method signature, that
is not decided by the programer.

bye blackdrag

--
Jochen "blackdrag" Theodorou
Groovy Tech Lead (http://groovy.codehaus.org)
http://blackdragsview.blogspot.com/

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

http://xircles.codehaus.org/manage_email

Re: Improvement in handling exception

2007-02-08T02:56:01Z

I very much agree with Paul's comments, but I would take a stronger
line:

I think that checked exceptions thrown by library / infrastructure are a
mechanism for the library / infrastructure implementer to control the
way in which an application is to be programmed, i.e. to limit the
freedom of the application developer to design and implement the
application as they want to do.

I find the fascism of checked exceptions issued by libraries /
infrastructure to be extremely constraining -- and if you see any of my
C++ or Java code you will see I am a huge fan of massive static type
checking, and use of cosnt/final everywhere to ensure single assignment
semantics wherever possible (arguably I overdo it :-).

Personally I can see no use for checked exceptions except where the
throwing and catching are always entirely within the code I write.

On Thu, 2007-02-08 at 20:34 +1000, Paul King wrote:

> There are those that despise checked exceptions (it makes TDD harder
> in Java) and those that argue the benefits. The balanced view for Java
> is that checked exceptions should be used when you can reasonably expect
> that the caller can and wants/needs to be able to respond to an error
> situation. The implication of this is that for nearly any general purpose
> library checked exceptions are not usually the way to go because you
> can't (in general) always know that a user of your library wants to
> respond to your errors. There are many places in Java which don't obey
> this rule. Groovy's design choices makes using such classes have much
> less scaffolding code and makes various kinds of testing both possible
> and relatively easy. You can add the relevant try/catch code if you
> wish.
>
> Now, arguments for using checked exceptions within your application
> are much stronger. There they can be much more beneficial and you can
> reasonably expect that parts of your application code can make expectations
> about how other parts can/should use exceptions. Even so, if you refactor
> your code into general purpose libraries, you will probably keep checked
> exceptions out of the reusable parts. What you will have left - the places
> were checked exceptions prove most beneficial should really only be a
> small number of layers. Groovy doesn't help in this case but there is
> no reason why good IDE support couldn't detect such scenarios.

--
Russel.
====================================================
Dr Russel Winder +44 20 7585 2200
41 Buckmaster Road +44 7770 465 077
London SW11 1EN, UK russel@...

signature.asc (196 bytes) Download Attachment

Re: Improvement in handling exception

2007-02-08T02:44:35Z

On Thu, 2007-02-08 at 09:54 +0000, John Wilson wrote:

> I always have a period when moving from programming language X to
> programming language Y of saying "In X we do this why can't I do it
> in Y?". In the end I understnad Y's way of doing things!

Back to Marion's thesis :-)

Don't forget though the situation:

I am moving from language X to language Y, I do this thing this way in X
why can't I do it this way in Y. Ah you do it that way in Y, but isn't
that ludicrous? If I did it this way in Y learning a lesson from the
way it is done in X then doesn't that work even better in Y? Oh yes.

This is why I like working in multiple languages at all times, the
cross-fertilization of idioms makes for much better programs in all
languages.

--
Russel.
====================================================
Dr Russel Winder +44 20 7585 2200
41 Buckmaster Road +44 7770 465 077
London SW11 1EN, UK russel@...

signature.asc (196 bytes) Download Attachment

Re: Improvement in handling exception

2007-02-08T02:34:52Z

John Wilson wrote:

>
> On 8 Feb 2007, at 06:11, Daniel.Sun wrote:
>> [...] I think Groovy should compel programmers to add 'throws XXXException'
>> explicitly as Java do when defining a method that can throw some
>> exception.
>
> The debate about checked vs unchecked exceptions is very old. Java has
> checked exceptions (put into the language at the very last minute), C#
> does not. There have been many discussions about the robustness of C#
> applications vs Java ones due to this difference. In practice there
> seems not to be any difference.

I would present the issues in a different (and much less succinct)
way than John but reach very similar conclusions...

There are those that despise checked exceptions (it makes TDD harder
in Java) and those that argue the benefits. The balanced view for Java
is that checked exceptions should be used when you can reasonably expect
that the caller can and wants/needs to be able to respond to an error
situation. The implication of this is that for nearly any general purpose
library checked exceptions are not usually the way to go because you
can't (in general) always know that a user of your library wants to
respond to your errors. There are many places in Java which don't obey
this rule. Groovy's design choices makes using such classes have much
less scaffolding code and makes various kinds of testing both possible
and relatively easy. You can add the relevant try/catch code if you
wish.

Now, arguments for using checked exceptions within your application
are much stronger. There they can be much more beneficial and you can
reasonably expect that parts of your application code can make expectations
about how other parts can/should use exceptions. Even so, if you refactor
your code into general purpose libraries, you will probably keep checked
exceptions out of the reusable parts. What you will have left - the places
were checked exceptions prove most beneficial should really only be a
small number of layers. Groovy doesn't help in this case but there is
no reason why good IDE support couldn't detect such scenarios.

Paul.

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

http://xircles.codehaus.org/manage_email

Re: Improvement in handling exception

2007-02-08T02:06:47Z

Yeah, you're right.
I will take more time in studying Groovy which is really very wonderful programming language.
I love it very much :)

John Wilson wrote:

On 8 Feb 2007, at 09:23, Daniel.Sun wrote:

> Thank you for your patient response.
> Maybe I program in Java for a long time, so something groovy I can't
> understand and meet troubles half-way :)

it's no problem:)

I always have a period when moving from programming language X to
programming language Y of saying "In X we do this why can't I do it
in Y?". In the end I understnad Y's way of doing things!

John Wilson
The Wilson Partnership
web http://www.wilson.co.uk
blog http://eek.ook.org

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

http://xircles.codehaus.org/manage_email

Re: Improvement in handling exception

2007-02-08T01:54:25Z

On 8 Feb 2007, at 09:23, Daniel.Sun wrote:

> Thank you for your patient response.
> Maybe I program in Java for a long time, so something groovy I can't
> understand and meet troubles half-way :)

it's no problem:)

I always have a period when moving from programming language X to
programming language Y of saying "In X we do this why can't I do it
in Y?". In the end I understnad Y's way of doing things!

John Wilson
The Wilson Partnership
web http://www.wilson.co.uk
blog http://eek.ook.org

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

http://xircles.codehaus.org/manage_email

Re: Improvement in handling exception

2007-02-08T01:23:23Z

Thank you for your patient response.
Maybe I program in Java for a long time, so something groovy I can't understand and meet troubles half-way :)

John Wilson wrote:

On 8 Feb 2007, at 06:11, Daniel.Sun wrote:

> Hi all,
>
> "the Groovy methods will not declare that they throw any checked
> exceptions
> unless you’ve explicitly added the
> declaration, even though they might throw checked exceptions at
> runtime."
> quoted from 'Groovy in Action'
>
> I think Groovy should compel programmers to add 'throws XXXException'
> explicitly as Java do when defining a method that can throw some
> exception.
>
> Why do I think it very vital?
> For example,
> If I define an exception of my own.
>
> class MyException extends Exception {
> MyException(String msg) {
> super(msg)
> }
> }
>
> then I instantiate MyException and throw it in myMethod1
>
> def myMethod1() {
> throw new MyException("error root")
> }
>
> then I invoke myMethod1 in myMethod2
>
> def myMethod2() {
> //... omit
> myMethod1()
> //...omit
> }
>
> //...invoke myMethodx() in myMethody()
>
> At last I invoke myMethody in myMethodn which is vital for our
> application
> and should be robust and shouldn't crash.
> but I can NOT remember that myMethody can throw MyException. What
> is worse,
> I have NOT enclosed "myMethody()" in try-catch clause. Disaster
> appeared :(
> myMethodn will crash in some day.
>
> def myMethodn() {
> //... omit
> myMethody()
> //...omit
> }

The debate about checked vs unchecked exceptions is very old. Java
has checked exceptions (put into the language at the very last
minute), C# does not. There have been many discussions about the
robustness of C# applications vs Java ones due to this difference. In
practice there seems not to be any difference.

We took a decision right at the start of the project not to require
users to do housekeeping of checked exceptions and this seems to work
very well.

I do, however, think that we could improve our Exception handling
whit respect to Java interfacing. If a groovy method throws a checked
exception but does not have a throws clause then a Java method which
calls it cannot catch the exception. The Groovy compiler can tell
that a checked exception is thrown and could, in principle, put the
throws clause into the generated bytecode.

John Wilson
The Wilson Partnership
web http://www.wilson.co.uk
blog http://eek.ook.org

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

http://xircles.codehaus.org/manage_email

Re: Improvement in handling exception

2007-02-07T23:21:37Z

On 8 Feb 2007, at 06:11, Daniel.Sun wrote:

> Hi all,
>
> "the Groovy methods will not declare that they throw any checked
> exceptions
> unless you’ve explicitly added the
> declaration, even though they might throw checked exceptions at
> runtime."
> quoted from 'Groovy in Action'
>
> I think Groovy should compel programmers to add 'throws XXXException'
> explicitly as Java do when defining a method that can throw some
> exception.
>
> Why do I think it very vital?
> For example,
> If I define an exception of my own.
>
> class MyException extends Exception {
> MyException(String msg) {
> super(msg)
> }
> }
>
> then I instantiate MyException and throw it in myMethod1
>
> def myMethod1() {
> throw new MyException("error root")
> }
>
> then I invoke myMethod1 in myMethod2
>
> def myMethod2() {
> //... omit
> myMethod1()
> //...omit
> }
>
> //...invoke myMethodx() in myMethody()
>
> At last I invoke myMethody in myMethodn which is vital for our
> application
> and should be robust and shouldn't crash.
> but I can NOT remember that myMethody can throw MyException. What
> is worse,
> I have NOT enclosed "myMethody()" in try-catch clause. Disaster
> appeared :(
> myMethodn will crash in some day.
>
> def myMethodn() {
> //... omit
> myMethody()
> //...omit
> }

The debate about checked vs unchecked exceptions is very old. Java
has checked exceptions (put into the language at the very last
minute), C# does not. There have been many discussions about the
robustness of C# applications vs Java ones due to this difference. In
practice there seems not to be any difference.

We took a decision right at the start of the project not to require
users to do housekeeping of checked exceptions and this seems to work
very well.

I do, however, think that we could improve our Exception handling
whit respect to Java interfacing. If a groovy method throws a checked
exception but does not have a throws clause then a Java method which
calls it cannot catch the exception. The Groovy compiler can tell
that a checked exception is thrown and could, in principle, put the
throws clause into the generated bytecode.

John Wilson
The Wilson Partnership
web http://www.wilson.co.uk
blog http://eek.ook.org

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

http://xircles.codehaus.org/manage_email

Improvement in handling exception

2007-02-07T22:11:44Z

Hi all,

"the Groovy methods will not declare that they throw any checked exceptions unless you’ve explicitly added the
declaration, even though they might throw checked exceptions at runtime." quoted from 'Groovy in Action'

I think Groovy should compel programmers to add 'throws XXXException' explicitly as Java do when defining a method that can throw some exception.

Why do I think it very vital?
For example,
If I define an exception of my own.

class MyException extends Exception {
MyException(String msg) {
super(msg)
}
}

then I instantiate MyException and throw it in myMethod1

def myMethod1() {
throw new MyException("error root")
}

then I invoke myMethod1 in myMethod2

def myMethod2() {
//... omit
myMethod1()
//...omit
}

//...invoke myMethodx() in myMethody()

At last I invoke myMethody in myMethodn which is vital for our application and should be robust and shouldn't crash.
but I can NOT remember that myMethody can throw MyException. What is worse, I have NOT enclosed "myMethody()" in try-catch clause. Disaster appeared :( myMethodn will crash in some day.

def myMethodn() {
//... omit
myMethody()
//...omit
}

Best regards,
Daniel.Sun

Re: List of Closures and traditional for lopp

2007-02-01T08:38:52Z

John Wilson schrieb:

>
> On 1 Feb 2007, at 13:45, Jochen Theodorou wrote:
>
>> for (int i=0; i<X; <i++) {System.out.println(i);}
>>
>> seems not to confuse anyone. All I propose is to make this into a
>> usage of closures, that's all.. for example think of
>
>
> That's because I is declared outside the scope of the block and is
> inherited into the block in the normal way.
>
> In Java and C "(" does not introduce a new scoping context.

right, so there is no problem with the scoping ;) No, ( does really
introduce a new scoping context, because:

for (int i=0; i<X; <i++) {System.out.println(i);}
System.out.println(i);

is illegal, as result of a undeclared i, where

int i =0;
for (i=0; i<X; <i++) {System.out.println(i);}
System.out.println(i);

is allowed. Ok, maybe your "new scoping context" was fixed on the block
rather then the scope we are already in. But even if ( would introduce a
new scoping context and if the block after is automatically part of that
context, would it make a difference? that's the way it is implemented
for the while-statement atm.

bye blackdrag

--
Jochen "blackdrag" Theodorou
Groovy Tech Lead (http://groovy.codehaus.org)
http://blackdragsview.blogspot.com/

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

http://xircles.codehaus.org/manage_email

Re: List of Closures and traditional for lopp

2007-02-01T06:24:49Z

On 1 Feb 2007, at 13:45, Jochen Theodorou wrote:

> for (int i=0; i<X; <i++) {System.out.println(i);}
>
> seems not to confuse anyone. All I propose is to make this into a
> usage of closures, that's all.. for example think of

That's because I is declared outside the scope of the block and is
inherited into the block in the normal way.

In Java and C "(" does not introduce a new scoping context.

John Wilson
The Wilson Partnership
web http://www.wilson.co.uk
blog http://eek.ook.org

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

http://xircles.codehaus.org/manage_email