Joe Aultman - Couple of Groovy Questions for you...

Joe Aultman - Couple of Groovy Questions for you...

Joined: September 18th, 2008, 7:30 pm

July 13th, 2011, 11:18 pm #1

Hi Joe,

I thought I'd ask here to give others who might also wonder, the benefit of our conversation...

Regarding Groovy (The Java Scripting Technology for scripting (among other things) the Essbase API):

Does Groovy require a runtime/exe to be installed to run? Or can it be launched using the JRE (or its own)?
Can a groovy app be configured to run as a portable, self contained program or must the supporting environment be there?

Instead of .groovy files to encapsulate, can I use something analogous to inner classes within one file? Or, can I "jar/zip" up a collection of .groovy's into one collection of files?

I've been to Groovy.com. A bit overwhelming. Are there a couple of blogs you might recommend?

So Currying, and not Schönfinkeling?



Regards,
Robb Salzmann

Accelaits Ascension Suite
- Environment Management
- System Optimization
- Realtime Monitoring
- Automation

www.accelatis.com
http://codingwithhyperion.blogspot.com/
Quote
Like
Share

Joe Aultman
Joe Aultman

July 14th, 2011, 1:08 am #2

Robb,

I'm out of town on vacation at the moment. I can answer most of your questions next week.

-- Joe
Quote
Share

Aleck
Aleck

July 14th, 2011, 6:33 pm #3

You're Groovy
Quote
Share

Joe Aultman
Joe Aultman

July 25th, 2011, 10:26 pm #4

But yes.
Quote
Share

Joe Aultman
Joe Aultman

July 26th, 2011, 12:25 am #5

Hi Joe,

I thought I'd ask here to give others who might also wonder, the benefit of our conversation...

Regarding Groovy (The Java Scripting Technology for scripting (among other things) the Essbase API):

Does Groovy require a runtime/exe to be installed to run? Or can it be launched using the JRE (or its own)?
Can a groovy app be configured to run as a portable, self contained program or must the supporting environment be there?

Instead of .groovy files to encapsulate, can I use something analogous to inner classes within one file? Or, can I "jar/zip" up a collection of .groovy's into one collection of files?

I've been to Groovy.com. A bit overwhelming. Are there a couple of blogs you might recommend?

So Currying, and not Schönfinkeling?



Regards,
Robb Salzmann

Accelaits Ascension Suite
- Environment Management
- System Optimization
- Realtime Monitoring
- Automation

www.accelatis.com
http://codingwithhyperion.blogspot.com/
a) Does Groovy require a runtime/exe to be installed to run? Or can it be launched using the JRE (or its own)?

Groovy scripts (even one-liners) can be complied with groovyc into .class files. These are normal Java classes you can execute with the JRE. There are a dependencies, so a couple of .jar files have to be in the classpath for it to work.

In my Groovy lib directory, this works:
> echo println 'Hello World' > hw.groovy
> groovyc hw.groovy
> java -cp ".;.\groovy-1.8.0.jar;.\asm-3.2.jar" hw

b) Can a groovy app be configured to run as a portable, self contained program or must the supporting environment be there?

As you can see from above, Groovy programs can be made as portable as any other Java program. That is, you need a JRE either way. There is a published script called GroovyWrapper that will probably help you bundle up a Groovy script as an executable jar.

c) Instead of .groovy files to encapsulate, can I use something analogous to inner classes within one file? Or, can I "jar/zip" up a collection of .groovy's into one collection of files?

I think inner classes are kind of un-groovy. They are late-comers, but they are in there. Generally they seem not to be the preferred way. Still, if it works for you...

It's an important consideration that the typical use case starts with no binary files, just code. Using .groovy files named after the classes they contain is so the compiler can find the classes without searching through all the files for the class it needs. If it needs to make a new X, it just looks for X.groovy. Having to parse through all the .groovy files to find where X is coded would be terrible.

I don't know if you can jar up a bunch of .groovy files and use that jar on the classpath (that would be cool), but I sure think you could jar up a bunch of .class files you've compiled out of the .groovy ones and get nearly the same effect.

You seem to be thinking about deployment to a production environment and potential issues around that. That is a valid concern. Ultimately, I don't think it's any riskier than any other scripting solution to deploy the full Groovy environment and a JDK to production. How different is that from putting the perl executable out there? Or CMD? Despite that, I can see real advantages to a scheme that uses raw, uncompiled code in a dev environment but deploys compiled .class and .jar files for production / DR / QA. I'm pretty sure the same thing can be done with Perl, but as I'm saying, for our purposes, Perl sucks. (With proper apologies to Tim Faitch.)

Let me know if this helps you and what you get figured out. I WANT ADOPTERS!

-- Joe
Quote
Share

Joined: September 18th, 2008, 7:30 pm

July 26th, 2011, 5:03 pm #6

Joe,

Thanks for the concise response. I would have spent days parsing through mounds of groovy docs to extrapolate what you conveyed in a few paragraphs. Your post is the Groovy gravy - I really appreciate it. I'll be in touch...



Regards,
Robb Salzmann

Accelaits Ascension Suite
- Environment Management
- System Optimization
- Realtime Monitoring
- Automation

www.accelatis.com
http://codingwithhyperion.blogspot.com/
Quote
Like
Share

GlennS
GlennS

July 26th, 2011, 6:42 pm #7

a) Does Groovy require a runtime/exe to be installed to run? Or can it be launched using the JRE (or its own)?

Groovy scripts (even one-liners) can be complied with groovyc into .class files. These are normal Java classes you can execute with the JRE. There are a dependencies, so a couple of .jar files have to be in the classpath for it to work.

In my Groovy lib directory, this works:
> echo println 'Hello World' > hw.groovy
> groovyc hw.groovy
> java -cp ".;.\groovy-1.8.0.jar;.\asm-3.2.jar" hw

b) Can a groovy app be configured to run as a portable, self contained program or must the supporting environment be there?

As you can see from above, Groovy programs can be made as portable as any other Java program. That is, you need a JRE either way. There is a published script called GroovyWrapper that will probably help you bundle up a Groovy script as an executable jar.

c) Instead of .groovy files to encapsulate, can I use something analogous to inner classes within one file? Or, can I "jar/zip" up a collection of .groovy's into one collection of files?

I think inner classes are kind of un-groovy. They are late-comers, but they are in there. Generally they seem not to be the preferred way. Still, if it works for you...

It's an important consideration that the typical use case starts with no binary files, just code. Using .groovy files named after the classes they contain is so the compiler can find the classes without searching through all the files for the class it needs. If it needs to make a new X, it just looks for X.groovy. Having to parse through all the .groovy files to find where X is coded would be terrible.

I don't know if you can jar up a bunch of .groovy files and use that jar on the classpath (that would be cool), but I sure think you could jar up a bunch of .class files you've compiled out of the .groovy ones and get nearly the same effect.

You seem to be thinking about deployment to a production environment and potential issues around that. That is a valid concern. Ultimately, I don't think it's any riskier than any other scripting solution to deploy the full Groovy environment and a JDK to production. How different is that from putting the perl executable out there? Or CMD? Despite that, I can see real advantages to a scheme that uses raw, uncompiled code in a dev environment but deploys compiled .class and .jar files for production / DR / QA. I'm pretty sure the same thing can be done with Perl, but as I'm saying, for our purposes, Perl sucks. (With proper apologies to Tim Faitch.)

Let me know if this helps you and what you get figured out. I WANT ADOPTERS!

-- Joe
I want to be adopted. Will you pay for my new car dad?
Quote
Share

Cameron Lackpour
Cameron Lackpour

July 26th, 2011, 9:56 pm #8

a) Does Groovy require a runtime/exe to be installed to run? Or can it be launched using the JRE (or its own)?

Groovy scripts (even one-liners) can be complied with groovyc into .class files. These are normal Java classes you can execute with the JRE. There are a dependencies, so a couple of .jar files have to be in the classpath for it to work.

In my Groovy lib directory, this works:
> echo println 'Hello World' > hw.groovy
> groovyc hw.groovy
> java -cp ".;.\groovy-1.8.0.jar;.\asm-3.2.jar" hw

b) Can a groovy app be configured to run as a portable, self contained program or must the supporting environment be there?

As you can see from above, Groovy programs can be made as portable as any other Java program. That is, you need a JRE either way. There is a published script called GroovyWrapper that will probably help you bundle up a Groovy script as an executable jar.

c) Instead of .groovy files to encapsulate, can I use something analogous to inner classes within one file? Or, can I "jar/zip" up a collection of .groovy's into one collection of files?

I think inner classes are kind of un-groovy. They are late-comers, but they are in there. Generally they seem not to be the preferred way. Still, if it works for you...

It's an important consideration that the typical use case starts with no binary files, just code. Using .groovy files named after the classes they contain is so the compiler can find the classes without searching through all the files for the class it needs. If it needs to make a new X, it just looks for X.groovy. Having to parse through all the .groovy files to find where X is coded would be terrible.

I don't know if you can jar up a bunch of .groovy files and use that jar on the classpath (that would be cool), but I sure think you could jar up a bunch of .class files you've compiled out of the .groovy ones and get nearly the same effect.

You seem to be thinking about deployment to a production environment and potential issues around that. That is a valid concern. Ultimately, I don't think it's any riskier than any other scripting solution to deploy the full Groovy environment and a JDK to production. How different is that from putting the perl executable out there? Or CMD? Despite that, I can see real advantages to a scheme that uses raw, uncompiled code in a dev environment but deploys compiled .class and .jar files for production / DR / QA. I'm pretty sure the same thing can be done with Perl, but as I'm saying, for our purposes, Perl sucks. (With proper apologies to Tim Faitch.)

Let me know if this helps you and what you get figured out. I WANT ADOPTERS!

-- Joe
>>I'm pretty sure the same thing can be done with Perl, but as I'm saying, for our purposes, Perl sucks. (With proper apologies to Tim Faitch.)
^^^What are the benefits of Groovy over Perl? Yes, I understand this is from the persepctive of your environment, but regardless I'm curious.

Regards,

Cameron Lackpour
Quote
Share

Joined: September 18th, 2008, 7:30 pm

July 26th, 2011, 11:53 pm #9

... with proper apologies to Tim Faitch, Larry Wall, et al,
<rant>
PERL hit the programming language scene with amazing (at that time) capabilities when I ran into it in late 1987. In 25 years, the language itself has done little to evolve itself and today hallmarks as this cryptic language that only a geek can sling.

For me, I can with other languages do volumes more work in less time with less code that is readable and maintainable by more people, so why try to do things with a language that was generally meant for extraction, string mangling, reporting, and administrative (UNIX) tasks. I like Regexes as much as the next guy, and think their pretty handy at times, but mash a few of them together in a perl script and you get what looks like the output of a military grade 256 bit pseudorandom pattern generator.

My experience dealing with PERL code left behind by someone before me has almost consistently been an exercise in rewriting _badly_ written code just so I can understand it enough to make the changes & additions requested. Anymore its been more cost effective to gather the requirements and just start over with a different language.

Here's a guy who's written "the best perl script ever": http://karwin.blogspot.com/2009/01/best ... -ever.html

map(($r=$_,map(($y=$r-$_/3,$l[24-$r].=(' ','@')[$y**2-20*$y+($_**2)/3<0]),(0..30)),),(0..24));print join("\n", map(reverse($_).$_, @l)), "\n";

I think the script prints some sort of mushy marriage proposal of sorts, but gawd.... In the Navy, we just used BCG's (Birth Control Glasses) http://s3files.core77.com/blog/images/2 ... bcgs02.jpg

</rant>


Of course this is all one guy's opinion, and I will agree that PERL still has its merits (though I'll never admit to any in public).

Regards,
Robb
Quote
Like
Share

Joe Aultman
Joe Aultman

July 27th, 2011, 12:39 am #10

>>I'm pretty sure the same thing can be done with Perl, but as I'm saying, for our purposes, Perl sucks. (With proper apologies to Tim Faitch.)
^^^What are the benefits of Groovy over Perl? Yes, I understand this is from the persepctive of your environment, but regardless I'm curious.

Regards,

Cameron Lackpour
Cameron,

Perl is a powerful, expressive, fun language that is great many purposes. I submit that Groovy's power, expressiveness, and fun rival those of Perl while its readability to mere mortals leaves Perl in the dust. That's not really my point, though. Remember I said "for our purposes". By that I mean better scripting of Essbase jobs, specifically scripting against the JAPI.

The kind of Perl scripting anyone is actually doing is dispatching MaxL calls via the Essbase module and parsing the results. Besides the fact that I have failed with some versions even to get the module to compile, the solution itself simply doesn't give me the interaction with Essbase I'm looking for. I know it's somehow possible to make actual JAPI calls from a Perl script, but that's not what I want to do. It sounds like a headache, and I want nothing to do with it -- even if it's not hard. We rejected Perl years ago as our scripting solution because we did not like our chances of finding someone to take the environment over when I finally get hit by that bus.

If I can script against Java libraries using Java, that's what I want to do, and that's what Groovy lets me do (plus it adds a dump truck full of excellent improvements!). We have in the neighborhood of a billion to one Java programmer to Perl programmer ratio here, and that's not going to be uncommon throughout the world.

I'd ask any Essbase administrator in the world to learn Groovy over Perl. I'd recommend anyone using Perl to access the JAPI (anyone?, anyone?) to switch to Groovy. I've told Tim Tow that Groovy has a place in his work.

And that's why I say, for our purposes, Perl sucks. Continued apologies to Tim Faitch.

-- Joe

P.S. You kind of know all this already, don't you? Are you just pulling my string to hear me squawk? Or did you sleep through my presentation?
Quote
Share


Confirmation of reply: