Groovy vs. Compiler API JSR 199 ?

[martido]

Hi there,

I've recently seen the talk by Dierk König called 'Seven Groovy Usage Patterns for Java Developers'. He describes a pattern called Liquid Heart, i.e. the externalization of business rules/models for flexible applications. I really like the idea, but I've to admit that I'm pretty new to Groovy and it's capabilities when used as a scripting language for Java. However, I'm wondering if you cannot accomplish a similar thing with the Compiler API aka. JSR 199 that comes with Java 6?

I'm thinking about reading Java source files and compiling them on the fly at runtime in order to keep business rules flexible just like Groovy can do. Well, I've not yet tried it out. It's just a though that occured to me recently. I don't know if there's something fundamentally wrong with this idea or if Groovy provides things that the Compiler API doesn't. So I though I could ask around here if someone has thought about something similar?

Thanks very much, guys
- Martin

[Martin C. Martin]

Groovy provides a much more concise syntax, so that the business rules
can be kept by people who don't need to have deep knowledge of Java.
For example, if they have an Employee that they happen to know is
actually an object of the subclass Manager, they can treat it like a
Manager without having to do an explicit class.  They also don't have to
know the difference between manager.foo and manager.getFoo(), and why
it's a convention to use the second over the first in Java, etc.

Best,
Martin

martido wrote:

> Hi there,
>
> I've recently seen the talk by Dierk König called 'Seven Groovy Usage
> Patterns for Java Developers'. He describes a pattern called Liquid Heart,
> i.e. the externalization of business rules/models for flexible applications.
> I really like the idea, but I've to admit that I'm pretty new to Groovy and
> it's capabilities when used as a scripting language for Java. However, I'm
> wondering if you cannot accomplish a similar thing with the Compiler API
> aka. JSR 199 that comes with Java 6?
>
> I'm thinking about reading Java source files and compiling them on the fly
> at runtime in order to keep business rules flexible just like Groovy can do.
> Well, I've not yet tried it out. It's just a though that occured to me
> recently. I don't know if there's something fundamentally wrong with this
> idea or if Groovy provides things that the Compiler API doesn't. So I though
> I could ask around here if someone has thought about something similar?
>
> Thanks very much, guys
> - Martin

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

    http://xircles.codehaus.org/manage_email

[martido]

Hi Martin,

thanks for your reply. So the advantage of using Groovy as a scripting language for Java is not only the gained flexibility alone but also the syntactic superiority of Groovy. Ok, I got that and I totally agree.

However, leaving the latter aside, I'm trying to understand if the goal of flexibility is actually achievable with something like JSR 199 and, what is more important, comparable to what Groovy can do. The reason I'm asking is because the clients that I work for are usually *very* conservative in what technologies they allow to be used in their systems. I'm sure you know a bunch of them yourselves. They want agility and flexibility, but they don't want to introduce Groovy (or any other language other than Java for that matter) without a killer argument. The argument of syntax is often not enough unfortunately.

-Martin

Martin C. Martin-2 wrote:

Groovy provides a much more concise syntax, so that the business rules
can be kept by people who don't need to have deep knowledge of Java.
For example, if they have an Employee that they happen to know is
actually an object of the subclass Manager, they can treat it like a
Manager without having to do an explicit class.  They also don't have to
know the difference between manager.foo and manager.getFoo(), and why
it's a convention to use the second over the first in Java, etc.

Best,
Martin

martido wrote:
> Hi there,
>
> I've recently seen the talk by Dierk König called 'Seven Groovy Usage
> Patterns for Java Developers'. He describes a pattern called Liquid Heart,
> i.e. the externalization of business rules/models for flexible applications.
> I really like the idea, but I've to admit that I'm pretty new to Groovy and
> it's capabilities when used as a scripting language for Java. However, I'm
> wondering if you cannot accomplish a similar thing with the Compiler API
> aka. JSR 199 that comes with Java 6?
>
> I'm thinking about reading Java source files and compiling them on the fly
> at runtime in order to keep business rules flexible just like Groovy can do.
> Well, I've not yet tried it out. It's just a though that occured to me
> recently. I don't know if there's something fundamentally wrong with this
> idea or if Groovy provides things that the Compiler API doesn't. So I though
> I could ask around here if someone has thought about something similar?
>
> Thanks very much, guys
> - Martin

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

    http://xircles.codehaus.org/manage_email

[Jochen Theodorou]

martido schrieb:

> Hi Martin,
>
> thanks for your reply. So the advantage of using Groovy as a scripting
> language for Java is not only the gained flexibility alone but also the
> syntactic superiority of Groovy. Ok, I got that and I totally agree.
>
> However, leaving the latter aside, I'm trying to understand if the goal of
> flexibility is actually achievable with something like JSR 199 and, what is
> more important, comparable to what Groovy can do. The reason I'm asking is
> because the clients that I work for are usually *very* conservative in what
> technologies they allow to be used in their systems. I'm sure you know a
> bunch of them yourselves. They want agility and flexibility, but they don't
> want to introduce Groovy (or any other language other than Java for that
> matter) without a killer argument. The argument of syntax is often not
> enough unfortunately.

May I ask who is going to write those "scripts"? If it is novices, then
Java will be overkill. Groovy can provide a subset that allows you to
write small programs without thinking about classes and types. If you
try that in Java the compiler complains all the time. This is not alone
syntax, this is also semantics.

If it is experienced Java programers who will write that stuff, then
well, go for jsr199.

bye blackdrag

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


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

    http://xircles.codehaus.org/manage_email

[martido]

Jochen Theodorou wrote:

May I ask who is going to write those "scripts"? If it is novices, then
Java will be overkill. Groovy can provide a subset that allows you to
write small programs without thinking about classes and types. If you
try that in Java the compiler complains all the time. This is not alone
syntax, this is also semantics.

If it is experienced Java programers who will write that stuff, then
well, go for jsr199.

bye blackdrag

Well, those "scripts" would be written by (more or less) experienced Java programmers. But I understand what you mean. Using Java for this kind of stuff brings a lot of complexity to the table that you'd probably like to avoid under the constraints of a tight budget. I'd gladly use Groovy because of all the advantages already mentioned. However, I was hoping that somebody had actually tried to "adapt" Dierk's Liquid Heart pattern to pure Java using for example JSR 199 and could have shared his/her experience compared to Groovy. On the other hand ... maybe nobody's got the time to reinvent the Groovy wheel =)

-Martin

[Jochen Theodorou]

martido schrieb:
[...]
> Well, those "scripts" would be written by (more or less) experienced Java
> programmers. But I understand what you mean. Using Java for this kind of
> stuff brings a lot of complexity to the table that you'd probably like to
> avoid under the constraints of a tight budget. I'd gladly use Groovy because
> of all the advantages already mentioned. However, I was hoping that somebody
> had actually tried to "adapt" Dierk's Liquid Heart pattern to pure Java
> using for example JSR 199 and could have shared his/her experience compared
> to Groovy. On the other hand ... maybe nobody's got the time to reinvent the
> Groovy wheel =)

I think it makes not really sense for someone who is used to Groovy to
do that. liquid heart means you have an existing infrastructure and you
want to modify it by a "script". But for this you have to either give in
some values or provide a context to get those.

In Groovy you can do that:

println foo

In Java you would have to do for example:

public class C implements I {
   public void run(T foo) {
     System.out.println(foo);
   }
}

I won't point at the groovy version needing only one line and the java
version needing 5, I want to point much more to the types C,I and T that
are needed here. If T is something internal, then an import is needed.
Of course a simple import is not bad, but that means additional context
information you need. If you make T into Object, you will most probably
need a cast later(in Groovy you most probably won't need the cast), not
allowing you to avoid the problem. It just avoids overspecialized
declarations of I, where I see the next problem. Again you have here
useless context information. And finally there is C. What name will you
give to C? In Groovy Groovy can choose that for you and the class will
be i the class loader. That of course means in Groovy we can have more
than one C. Java won't care about that too, unless it sees the other
class. This doesn't give any unresolveable problems, it just means for
you to spend more time on the implementation of the pattern and of
course more time during writing the scriptlet.

Now we could try to make that more easy by just copying the surrounding code

System.out.println(foo)

and letting the environment choose the class name and do the stuff for
I... but what about T? What about the cast I mentioned? What about
methods, other classes and imports? If you want to solve all those
problems, then congratulations, you just made your own little language.
And that language is not Java.

The usage pattern for a Java developer will most probably be to write
the code in an IDE and then copy it over. The usage pattern from Groovy
to directly write those in a kind of console won't happen for Java,
since Java is simply too complex. Only the question is then... if you
write them in an IDE anyway, why do you need source code?

I would say the answer here is to make small changes and adjustments.
But if you have a script containing several hundred lines (with Java you
are very fast in that magnitude, just think about all the imports the
IDe will add) then you want to make a change in a text without any
syntax highliting and IDE support? I don't think so. The usage will be
to copy the code over again and make the change in the IDE to then copy
the changed code back.

If anything will happen through an IDE anyway, then why not instead
provide an easy deployment way? I mean the IDE is *that* argument to
turn Java into a good language. Why now loosing it?

bye blackdrag

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


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

    http://xircles.codehaus.org/manage_email

[martido]

Ah, ok, that makes sense. Groovy provides the "infrastructure" that you would have to implement yourself in Java. Thanks for explaining.

Sorry, but I didn't quite get your IDE argument. What do you mean by "easy deployment way"? Do you mean to say that if you *would* write "scripts" in Java you would need an IDE anyway. And if you need an IDE then why use "scripts" at all and not go for some other architecture? Hope that makes any sense, but is that about right?

Cheers
-Martin

Jochen Theodorou wrote:

martido schrieb:
[...]
> Well, those "scripts" would be written by (more or less) experienced Java
> programmers. But I understand what you mean. Using Java for this kind of
> stuff brings a lot of complexity to the table that you'd probably like to
> avoid under the constraints of a tight budget. I'd gladly use Groovy because
> of all the advantages already mentioned. However, I was hoping that somebody
> had actually tried to "adapt" Dierk's Liquid Heart pattern to pure Java
> using for example JSR 199 and could have shared his/her experience compared
> to Groovy. On the other hand ... maybe nobody's got the time to reinvent the
> Groovy wheel =)

I think it makes not really sense for someone who is used to Groovy to
do that. liquid heart means you have an existing infrastructure and you
want to modify it by a "script". But for this you have to either give in
some values or provide a context to get those.

In Groovy you can do that:

println foo

In Java you would have to do for example:

public class C implements I {
   public void run(T foo) {
     System.out.println(foo);
   }
}

I won't point at the groovy version needing only one line and the java
version needing 5, I want to point much more to the types C,I and T that
are needed here. If T is something internal, then an import is needed.
Of course a simple import is not bad, but that means additional context
information you need. If you make T into Object, you will most probably
need a cast later(in Groovy you most probably won't need the cast), not
allowing you to avoid the problem. It just avoids overspecialized
declarations of I, where I see the next problem. Again you have here
useless context information. And finally there is C. What name will you
give to C? In Groovy Groovy can choose that for you and the class will
be i the class loader. That of course means in Groovy we can have more
than one C. Java won't care about that too, unless it sees the other
class. This doesn't give any unresolveable problems, it just means for
you to spend more time on the implementation of the pattern and of
course more time during writing the scriptlet.

Now we could try to make that more easy by just copying the surrounding code

System.out.println(foo)

and letting the environment choose the class name and do the stuff for
I... but what about T? What about the cast I mentioned? What about
methods, other classes and imports? If you want to solve all those
problems, then congratulations, you just made your own little language.
And that language is not Java.

The usage pattern for a Java developer will most probably be to write
the code in an IDE and then copy it over. The usage pattern from Groovy
to directly write those in a kind of console won't happen for Java,
since Java is simply too complex. Only the question is then... if you
write them in an IDE anyway, why do you need source code?

I would say the answer here is to make small changes and adjustments.
But if you have a script containing several hundred lines (with Java you
are very fast in that magnitude, just think about all the imports the
IDe will add) then you want to make a change in a text without any
syntax highliting and IDE support? I don't think so. The usage will be
to copy the code over again and make the change in the IDE to then copy
the changed code back.

If anything will happen through an IDE anyway, then why not instead
provide an easy deployment way? I mean the IDE is *that* argument to
turn Java into a good language. Why now loosing it?

bye blackdrag

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


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

    http://xircles.codehaus.org/manage_email

[Jochen Theodorou]

martido schrieb:
[...]
> Sorry, but I didn't quite get your IDE argument. What do you mean by "easy
> deployment way"? Do you mean to say that if you *would* write "scripts" in
> Java you would need an IDE anyway. And if you need an IDE then why use
> "scripts" at all and not go for some other architecture? Hope that makes any
> sense, but is that about right?

Short answer: yes... only that *I* would use Groovy of course ;)

Think about it, if you write programs in Java and even if they are just
a few lines long, do you want to do this without IDE? I mean without the
autocompletion stuff, without compiler checks? Usually Java developers
that are static typing fascists don't want only the compiler spitting
errors out at compile time. With JSR199 compiletime and runtime would
become one anyway. No, they want to be able to use an IDE. I don't mean
you would need an IDE in that general term. I mean for Java developers
to be as productive in your scripting application as they are in Java,
they need an IDE, because they are so used to the IDE, that working
without it will slow them down quite a bit and also because Java
developed into a language that is really usable only with IDE.

So I think the IDE will still be the central point of development. But
from there you don't need to deploy source. Then it is just a question
of how to get the source and put it back afterwards, which I used the
term deployment for.

bye blackdrag

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


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

    http://xircles.codehaus.org/manage_email