Home | About | Sematext search-lucene.com search-hadoop.com
 Search Hadoop and all its subprojects:

Switch to Threaded View
Bigtop >> mail # dev >> Bumping up version of Groovy in Bigtop


Copy link to this message
-
Re: Bumping up version of Groovy in Bigtop
+1 on bumping up Groovy version to 1.8.

On Sat, Oct 27, 2012 at 1:51 PM, Wing Yew Poon <[EMAIL PROTECTED]> wrote:

> It's good to hear from someone who's been using 1.8.
> I was looking recently at the version of groovy used in itest, and
> surprised that it was such an ancient version (1.6). I'm in favor of
> moving to a more recent stable version like 1.8. I am undecided if we
> should move to 2.x. Since we are not currently using Java 1.7 yet (for
> hadoop etc), I don't see the benefit as far as invokedynamic is
> concerned.
>
> On Sat, Oct 27, 2012 at 4:44 AM, Steve Loughran <[EMAIL PROTECTED]>
> wrote:
> > On 26 October 2012 19:54, Roman Shaposhnik <[EMAIL PROTECTED]> wrote:
> >
> >> On Fri, Oct 26, 2012 at 11:45 AM, Johnny Zhang <[EMAIL PROTECTED]>
> >> wrote:
> >> > Roman, how is your experience with Groovy's back compatibility? If we
> >> bump
> >> > to 1.8 or 2.0, do we expect any current tests failures?
> >>
> >
> > 1.8.x is pretty good, no problems I've encountered except that some of
> the
> > maven plugins are hard-coded to older ones (that's maven for you)
> >
> >
> > I haven't used 2.x. What it does promise is invokedynamic on Java7 and
> > performance gains from that
> >
> > http://dist.groovy.codehaus.org/JVM%20Summit%202012%20-%20Groovy.pdf
> >
> > -plus a static compile option.
> >
> >
> > for using Groovy in apps (as opposed to test code or other stuff where
> you
> > want high-perf groovy, this is all good).
> >
> > For tests? I don't see Groovy the bottleneck in my own code, though apart
> > from some GUI stuff.
> >
> > Groovy actually makes writing Swing apps something that you'd actually
> > consider doing:
> >
> https://github.com/hortonworks/HA-Monitor/blob/master/hmonitor/src/main/groovy/org/apache/ambari/servicemonitor/clients/gui/Ham.groovy
> >
> > You still need a reason to do so (here the monitoring/demo tool for HDFS
> > and JT failure), but once you've made that decision, Groovy is the
> language
> > to start with -at least until Java adds closures.
>