[prev in list] [next in list] [prev in thread] [next in thread] 

List:       groovy-user
Subject:    Re: [groovy-user] Groovy vs. Compiler API JSR 199 ?
From:       Jochen Theodorou <blackdrag () gmx ! org>
Date:       2009-10-29 23:10:21
Message-ID: 4AEA20DD.8030609 () gmx ! org
[Download RAW message or body]

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


[prev in list] [next in list] [prev in thread] [next in thread]