Google App Engine Adds Java Support, Groovy Meta-Programming

Zarf writes "Yesterday Google announced that the Google App Engine now supports Java development, and fast on the heels of the Java announcement is an announcement for Groovy support! Groovy is a dynamic programming language for the JVM that is a near super-set of Java. Much Java syntax is valid Groovy syntax, however, Groovy adds powerful meta-programming features, and the new functionality will bring these meta-programming features to App Engine development. Groovy got special attention from the SpringSource Groovy team and the Google App Engine Java team, and it was this collaboration that helped create the changes that were the big secret in the recent Groovy release of 1.6.1."

Comments

Awesome

[coldtone]

This really opens the floodgates for cloud computing. I can't wait to port to this platform.

Re:Awesome

[jlp2097]

Exactly! We just need to proactively monetize the synergistic potential of this new paradigm of cloud computing and meta-programming by thinking outside the box and leverage these tools to enable a better strategic fit in our forward-thinking, customercentric enterprise.
 
;-)

Re:Awesome

[AKAImBatman]

Even more to the point, it opens the flood-gates for secure webapps. PHP has the advantage of providing a number of great apps off the shelf that all run on cheap hosting providers. The flip-side to those apps is that you're stuck on the upgrade treadmill as security issues pour out of those apps.

No offense to the people writing these apps. The ease of the platform is a double-edged sword. It's not hard to accidentally introduce security holes in the application. Especially on projects with dozens of developers.

The Java platform is built with security as a core concern and thus tends to have fewer security issues. (Note that I said *fewer*. There's no perfect system, and there's no accounting for poor practices.) Deploying Java-based apps could end up being a boon for getting off this breakneck upgrade cycle.

In addition, Java has a much better system for componentization. PHP apps are often deployed as large sets of files. This has its advantages, but it also means that plugins are often achieved by modifying PHP code. The Java platform is a more dynamic platform that allows for components to easily be plugged in. With Java, adding new features to your blog or forums can be as easy as clicking the "install" button in the admin console.

In short, yay for Google! This is great news!

Re:Awesome

[fictionpuss]

Buzzwords aside, the ability to try GAE for free and use it for your own tests and experiments is a good thing. I've been much more productive hacking with python/GAE than php/mysql.

Re:Awesome

[Anonymous Coward]

Whoa, FABULOUS acronym!

Re:Awesome

[Blue Stone]

I'm concerned that my blue-sky thinking will be obscured by your cloud computing. Any advice?

Re:Awesome

[fictionpuss]

Whoa, FABULOUS acronym!

Dude, php and sql are acronyms too. WAIAFOA (We are in a field of acronyms). What's your point?

Re:Awesome

[Larry Clotter]

WHOOSH? I think he was making a joke about how you would say "GAE" like "gay" and then was saying it was a "FABULOUS" acronym (as in the stereotype of gay men saying "fabulous" a lot).

Re:Awesome

[Camann]

Shh! I was enjoying the breeze.

Re:Awesome

[fictionpuss]

Whoosh indeed, thanks for clarifying. I guess I need to find me some immature co-workers, cause I'm evidently out of touch.

Re:Awesome

[Fujisawa Sensei]

Exactly! We just need to proactively monetize the synergistic potential of this new paradigm of cloud computing and meta-programming by thinking outside the box and leverage these tools to enable a better strategic fit in our forward-thinking, customercentric enterprise. ;-)

Forget funny, mod parent as Insightful, that one was Brilliant!

I may have to quote you on that!

I may even have to drop it in the "suggestion box", that should be worth at least a couple of points on my Balance Score Card.

Re:Awesome

[fictionpuss]

Don't worry, in my head I pronounced it G-A-E and only went back to it when I was "wtf FABULOUS?"

I'm curious now how Google refer to it internally. Google Widget Toolkit is apparently pronounced "gwit".. so it follows that we both might be doing it wrong.

Any Googlers care to illuminate?

Re:Awesome

[NeoSkandranon]

Bingo!

I got:
monetize
paradigm
leverage
strategic
enterprise

Re:Awesome

[phaggood]

> plugins are often achieved by modifying PHP code.

Yeep. Tell me about it. A sci-fi writer friend of mine asked me to implement paypal on her RUNNING site; I purch'd a $40 Joomla plugin for the purpose, sat down and started to install it, figuring it to be an hour's effort, tops. As soon as I read 'execute this install script to begin patching [multiple] source files' I ran like an 8yr old Galifreyan from a Time Vortex.

Joomla. Brrrrrrrr. Still gives me the willies.

Re:Awesome

[Luke has no name]

I grasp the message of that sentence. Oh no.

Re:Awesome

[styrotech]

In addition, Java has a much better system for componentization. PHP apps are often deployed as large sets of files. This has its advantages, but it also means that plugins are often achieved by modifying PHP code. The Java platform is a more dynamic platform that allows for components to easily be plugged in. With Java, adding new features to your blog or forums can be as easy as clicking the "install" button in the admin console.

Nonsense.

What you are seeing that typically Java developers are more likely to be "architecture astronauts" and architect their apps towards componentisation etc sometimes at the expense of simplicity and clarity.

And typically PHP developers under-architect their apps and write them as kludgy non modular spaghetti code.

There is nothing more dynamic than PHP about Java itself - if anything it is the opposite. A lot of the common design patterns in Java are to get around the non dynamic nature of it, and I suspect it is this that makes Java devs far more conscious of architecture than PHP developers.

eg Drupal (PHP) has a very modular architecture and has thousands of plugin modules and has a culture that strongly discourages changing the core codebase. And whaddya know, a lot of the core devs are or have been Java developers and the founder even did a Phd in it.

Either way, if you want to use a pluggable component based architecture for your app you have to design it that way - the language won't do it for you.

Re:Awesome

[gnud]

Well if they follow the tradition of 'gwit', it would be 'gape'.

Re:Awesome

[rackserverdeals]

So what you are basically saying is that Java isn't better than PHP, instead, Java developers are better than PHP developers on the whole.

Re:Awesome

[styrotech]

No, I'm not claiming Java isn't better than PHP, just that Java isn't more dynamic than PHP (as was claimed).

Although its probably true overall, I wasn't even claiming that Java devs are better overall than PHP devs, just that they tend focus more effort on architecture. Even to the point of going too far and over complicating things sometimes.

I'd even hazard a guess that being in a less dynamic environment requires them to put more effort into architecture. Compared to PHP it is much harder to "just make it up as you go along" in Java.

Flexible modular apps are possible in PHP if the developers design them like that though. Likewise a Java app that isn't designed to be flexible and modular won't be flexible and modular.

Re:Awesome

[williamhb]

I'm concerned that my blue-sky thinking will be obscured by your cloud computing. Any advice?

We're hoping the collision of the different cloud paradigms will cause them to coalesce into a more tangible form, precipitating the knowledge and tools across the umbrella of all the technology community, from where it will flow into a deep reservoir of accumulated experience that can be processed, filtered, and piped out to the wider business community on tap. (To complete the water cycle analogy, the business suits will then piss it away, it'll all go down the sewer, and the industry will be all at sea until finally everything we've all worked on just evaporates.)

Re:Awesome

[rackserverdeals]

Oh. So Java makes them want to be a better programmer :)

Re:Awesome

[fractoid]

You need to harmonise your synergies to leverage optimal domains. It's simple when you think about it.

Re:Awesome

[A Pressbutton]

Grab the silver lining with both hands!

Re:Awesome

[Pravetz-82]

My buzz-o-meter just got off the scale...

Re:Awesome

[badkarmadayaccount]

Mod parent up,
+1 Heavily Drugged Analogy

Re:Awesome

[Blue Stone]

Well played, sir.

Looks like Python

[HandleMyBidness]

After a cursory glance around the Groovy site the syntax seems like python with brackets, yuck.

Re:Looks like Python

[hansamurai]

Well, it's biggest advantage is that it is a language written to run on the JVM*. You can talk to Java classes when you need to, but it's really a dynamic language that Java developers can easily learn and use. Type can be strong or weak depending on what you want/need, you can write Groovy unit tests against Java code, etc.

*of course there's Jython, but Groovy was designed from the ground up to be used by Java developers.

Re:Looks like Python

[Keyper7]

I played a little with Groovy some time ago to see what the fuss was all about. Comparing it to Ruby is better than comparing it to Python because Groovy relies on closures in a way very similar to the way Ruby relies on code blocks. The syntax is also closer to Ruby with respect to the "everything is an object" philosophy (numbers have callable methods, etc.)

The main problem I had during my small test drive is that Groovy has a lot of subtleties involving variable scoping that take a while to get used to and it's very, very slow. But the whole concept of using a dynamic language while having all the resources of Java available is quite nice.

Re:Looks like Python

[Zarf]

Just goes to prove that Python is the best language ever. Clearly you don't ever need to learn anything else. I strongly encourage you to not learn Groovy as it would poison your mind.

Obviously there's nothing the JVM has to offer you.

Re:Looks like Python

[vastabo]

Here is a writable closure for some KML:

def kmlDocument = new groovy.xml.StreamingMarkupBuilder().bind{
    mkp.xmlDeclaration()
    mkp.declareNamespace('': 'http://www.opengis.net/kml/2.2')
kml{
Document{
    Folder{
        name('*** stations')
        description('http://some.place.on.teh.webs/qry')
        open('1')
        stationTypes.each({type ->
            Folder{
                name(type[0])
                description('Station Type: ' + type[0])
                type[1].each({platform ->
                    Folder{
                        name(platform)
                        description('Platform: ' + platform)
                        stations[type[0] + platform].each({station ->
                            Placemark{
                                name(station.name)
                                description('http://some.place.on.teh.webs/qry/station?idtypeabbr=stnid&idvalue=' + station.stnidnum)
                                styleUrl(station.getIcon())
                                Point{
                                    coordinates(station.coord)
                                }
}})}})}})}}}} //lameness filter ate my whitespace; doesn't look like LISP in real life
def f = new File('doc.kml')
f.delete()
f << kmlDocument

The cool thing is that I get all this plus seamless Java integration (i.e. every class in the standard library -- GregorianCalendar, for instance), all my Java tools work, and I can replace lots and lots of boilerplate Java code with one and two liners of Groovy.  So:

ArrayList<String> list = new ArrayList<String>();
list.add("Blah");
list.add("Blah");
list.add("Blah");
list.add("Blah");
System.out.println(list);

Becomes:

def list = ["Blah","Blah","Blah","Blah"]
println list

And hey, with closures, if you want to do something like capitalize the first character of each string in that list it's really easy:

println list.collect({
    it[0].toUpperCase() + it[1..it.length() - 1] //there's a better way to do this; I'm being pedantic
})

Which is not to say that Python couldn't do all that, but Groovy makes life for Java monkeys much easier.

Re:Looks like Python

[Zarf]

I encourage you to spend your time in Clojure and port it to the Google App Engine.

Re:Looks like Python

[Lord Ender]

Anyone who has ever maintained perl will tell you that it isn't always the best idea to give programmers the choice of how to do things. If there is a right way, don't give them the option of doing it the wrong way, because many will do so. And if two ways are equally good, just pick one--there's no reason to give people an option!

Re:Looks like Python

[Tack]

I don't think the point was not to bother with Groovy, but that Python mightn't be as useless as you recall.

Re:Looks like Python

[Zarf]

I don't recall calling Python useless...

Re:Looks like Python

[SanityInAnarchy]

There's also JRuby, which is much more complete than Jython (I believe). And yes, Rails runs on JRuby, and Rails+JRuby runs on App Engine.

Re:Looks like Python

[quanticle]

I don't know about that. My philosophy is that there should be two ways to do everything - one way that's obvious and handles the "easy" cases, and a more "advanced" method that handles edge conditions that come won't come up in the commonly intended uses.

That way one makes the easy things easy while not making the hard things nearly impossible.

Re:Looks like Python

[DocHoncho]

The syntax is also closer to Ruby with respect to the "everything is an object" philosophy (numbers have callable methods, etc.)

Hmm?

Python 2.5.4 (r254:67916, Dec 23 2008, 15:10:54) [MSC v.1310 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> t=1
>>> t.__add__(1)
2
>>> (1).__add__(1)
2

The only caveat I see here is that Python doesn't like it when you try to call methods from an integer literal.

Re:Looks like Python

[ravster]

Python with brackets???

Whats the point of it all then, does this mean that it wouldn't take a look at white-space?

But...

[MrEricSir]

But Groovy is NEW! And new is better! Just ask any developer!

Re:But...

[ari_j]

Offer not valid where Lisp is sold.

Re:But...

[SanityInAnarchy]

Next step: Groovy on Grails?

I don't know if you're joking, but that is a real thing, and I wouldn't be surprised.

What may actually surprise you is that JRuby works on this, and Ruby on Rails works on JRuby. And, yes, someone has put it all together and Rails works on App Engine.

Which APIs? Any Database Functionality.

[c0d3r]

I'm curious to know which api's they support.. Sounds like only servlets and mail.. I wonder if its a complete J2EE container, which is pure bloat. Also do they have any standard sql functionality in their hosting solution?

Re:Which APIs? Any Database Functionality.

[nothing2seehere]

Reading TFA, it looks like a scalable servlet container. No J2EE as far as I can tell.

Re:Which APIs? Any Database Functionality.

[PotatoFarmer]

According to the linked page, it isn't a complete J2EE implementation, which kind of makes sense given the threading and io restrictions specified.

Also, no SQL. Data access is mediated through JDO or JPA. Which also makes sense, given that it's highly likely that the back end isn't a traditional RDBMS.

Re:Which APIs? Any Database Functionality.

[Anonymous Coward]

if they can get as functional as tomcat then you can run Spring on it. That counts as J2EE. They also have this thing called Grails which seems to be a web-dev system built around Groovy.

Re:Which APIs? Any Database Functionality.

[FatherOfONe]

Spring isn't really J2EE. It will be with the new J2EE because (I believe), they will make the spec more modular, in that you won't have to have a EJB container. Spring does a bunch of crap, but what most people mean is that it is a light weight container that doesn't require a EJB container to run in. On a personal note why is it that the Spring fanboys are such jerks. I really want to love Ruby and Spring but man their fanboys really wear on me.

None the less, this is fantastic news! Thank you Google.

Re:Which APIs? Any Database Functionality.

[daBass]

Servlets are part of J2EE, not Java SE. So is JPA.

By definition, any servlet container is a J2EE implementation.

When does something become "J2EE"? Session Beans? They are nice for client server apps, but their use in a web stack is rather limited and adds tons of overhead. POJOs, JPA, Servlets and an MVC framework will suit me just fine.

Re:Which APIs? Any Database Functionality.

[DuckDodgers]

I don't understand the love of Spring. One of Java's core strengths is supposed to be strong static typing, which lets you catch a large class of errors at compile time instead of run time.

When you move larger and larger amounts of your application into XML files and replace explicit class references with dependency injection, haven't you just tossed that out the window? At some point don't you decide that Spring has taken you so far away from Java itself that your real solution is a different programming language? Wouldn't it make more sense to use Perl, Python, or Ruby right out of the gate?

Re:Very cool

[DragonWriter]

but is this new?

Uh, yeah, the actual support for Java, while non-Python language support had been discussed as a possibility for the future previously, is new.

Re:Can't spawn threads or make network connections

[TomRK1089]

Those are the same restrictions Java Applets have due to the Security Manager, and somehow programmers manage to develop useful applets.

Re:Very cool

[Presto Vivace]

my mistake

Re:How about Ruby?

[swurley]

Running Ruby using Jruby on Google AppEngine.
http://blog.bigcurl.de/2009/04/running-sinatra-apps-on-google.html
Should get you started.

Re:cash cow

[jaydonnell]

java is extremely efficient so I have no idea what you're talking about. It's far more efficient than python which is the original GAE platform. I know it's fashionable to bash java on /., but you should at least know what you're talking about. Or, are you suggesting that everyone write their web apps in C?

Re:cash cow

[That's Unpossible!]

Really, do you think Google is going to deploy an inefficient design to make money on cycles? That seems incredibly short-sighted, far better to offer great performance and sign up more customers.

But that's why they're a company and you're posting anonymous snarky comments from the peanut gallery.

Re:How about Ruby?

[ESqVIP]

http://olabini.com/blog/tag/gae/

In fact, you should thank ThoughtWorks guys for several of the recent blog posts on GAE involving JRuby, Groovy and also Clojure.

Re:cash cow

[Camann]

Well it would be a great improvement over t

Segmentation Fault

Re:Can't spawn threads or make network connections

[AKAImBatman]

Can't get very far without these forbidden features...

Incorrect. The Servlet platform imposes those restrictions already, with the container handling all the messy details of threading and networking. It works just fine in 90%+ of the cases.

Groovy? Why not java?

[WankersRevenge]

I'm not sure I fully understand the reason for Groovy? I've read a lot of the documentation, but it doesn't answer the fundamental question ... as a java developer, why would I learn this language when I can just use java? Is it just for the new language features? Can someone illuminate?

Re:Groovy? Why not java?

[Anonymous Coward]

Java is my main language, but I definitely see the value in Groovy. For instance, how do you pass functions or other code blocks around in java? You either use very clumsy and verbose anonymous inner classes, or.. or nothing. Groovy handles this gracefully.

Basically Groovy is a scripting language that lets you use java classes. It's not really much different than Jython or JRuby, it's just more java-like in syntax.

Re:cash cow

[EgoWumpus]

While your two links are interesting, I think you have to do more work to make your point. Can you cite why those links prove the superiority of Python? And what specifically do you mean by 'rewrite the bible'?

Regarding efficiency, I give you this. The relevant sentence: "I decided to redo several of the tests with updated versions of Python (2.5) and the JDK (Java 6). And indeed, my suspicions were confirmed: Java has made huge speed improvements, and is now faster than Python in almost all cases."

Re:Groovy? Why not java?

[Yold]

RTFA, its from meta-programming! How else would you write meta-programs to run on GAE in the cloud? Just kidding =).

Although I could be way off, I'd assume it allows end-users of your web-app to script additional functionality onto it.

Re:cash cow

[Anonymous Coward]

Let me just say that you don't need to rewrite the bible every time you want to do any operation on python (or pretty much any other language)

Compare this http://code.google.com/appengine/docs/java/datastore/dataclasses.html

with this: http://code.google.com/appengine/docs/python/datastore/entitiesandmodels.html

Yes, because it's so hard to use the 2 click, automated IDE function to generate all those getters and setters. They aren't required by the language, btw, just for encapsulation. You know, that thing that's one of the selling points of OO.

You write exactly as much code as you do in Python, autogenerate convenience methods (getters, setters, toString, etc.), and end up with your beans. Besides, who cares how hard it is to write a bean class. This isn't exactly the core effort during app development, now is it? How many awesome libraries are there in Java for things like IOC, data access, web frameworks (MVC and otherwise)? There's piles and piles. Are some of them stinkers? Yes, but there's tons of robust, usable, and EFFICIENT frameworks out there. There's tons of free stuff, free app servers, free IDEs, free plugins, free libraries. Some of the best stuff in development was written in Java first (e.g. JUnit, Spring, etc.). This stuff is so good it's been ported to other platforms.

And to boot, the "slow and bloated" Java arguments are belied by the sheer volume of apps out there that are written in Java and you likely have no idea. Check out the networking portion of your favorite MMO game, it's likely written in Java, server side. Tons of banking software is written in Java once you get past the big iron portion. Tons of sites on the web are as well. Some of the biggest, custom forums in the world are Java (WOW forums are).

Yeah, the GP was right, you are ignorant, and don't seem to know what you're speaking about.

Re:cash cow

[jaydonnell]

You completely missed the point. The person I replied to was stating the the jvm is slow and that google would make a fortune because they charge for processing time. Your comment has absolutely no relation to the issue at hand.

Making Java as unreadable as Perl

[heroine]

Surely there is a way to make Java even less readable than Groovy. Maybe make the entire language pure regular expressions or allow every character including the . to be an object.

One outcome of Sun's future liquidation is that no-one is around to promote the 1 Jesus language & Java ends up fragmenting into thousands of derivatives like Linux or Fortran.

Re:Making Java as unreadable as Perl

[Luke has no name]

I don't know if you're trolling or not, because I don't know what you're trying to say.

Sun isn't going to die, it will survive or get bought by someone whose interests are in making money off Java and Sun's other product offerings better than Sun could.

Re:Groovy? Why not java?

[LarryRiedel]

To the extent Groovy is a "superset" of Java, it is a way to have a shell for doing things in Java without having to build; just type in commands at the prompt, or stick them in a file. One way to look at things might be to think of Java as a way to have compiled Groovy, sort of like Cython is a way to have compiled Python. Whether or not the extra non-Java features Groovy provides are worth using... that is debatable.

Larry

Re:cash cow

[codepunk]

True that I suppose that if I had never written python applications and only knew java I may think it is the greatest
thing since sliced bread also. However since I have written large applications in both java and python I know better. I absolutely hate
crufty languages and when it comes to cruft java is the king.

Re:cash cow

[EgoWumpus]

*shrug* I'm not convinced that Java is all that more complicated or time-consuming for the developer. And since 1.6, with annotations and generics, I'm not sure that the complaint about inflexibility is really there.

Suffice to say, I don't think that Python is the crystal clear choice. On the other hand, I'm not sure the differences are significant - so it probably is up to your coding (team's?) preference and style.

Re:cash cow

[theCoder]

Sure, Java is more efficient than Python. But is it more efficient than native code? http://shootout.alioth.debian.org/ has statistics and comparisons for many languages. They wrote the best programs they could to perform different tasks in each language and compared the results.

Java compared to Python
Java compared to C
Java compared to C++

C++ is slightly faster on all the tests, but not by as much as I'd expect, and Java is faster than some of the C implementations. At best, C++ is 3x faster and at worst it's about the same. Java does have a 10 to 30x memory footprint, though.

So I hope GAE charges by the CPU hour and not the amount of memory used :)

Re:cash cow

[JamesP]

I saw your original post, I don't disagree with you, even though the point is moot, efficiency in GAE has more to do with libraries and the code than anything else.

I don't dislike the JVM (ok, I dislike, but it's not the case here), I dislike the Java language

Re:cash cow

[JamesP]

And since 1.6, with annotations and generics, I'm not sure that the complaint about inflexibility is really there.

Suffice to say, I don't think that Python is the crystal clear choice.

I guess what matters in the end is developer knowledge of the language. :)

I would say one of the biggest advantages of GAE using Java is support for all the JVM languages (like JRuby, Groovy, etc, you could try running Jython as well, just for laughs)

Re:cash cow

[dfdashh]

Or, are you suggesting that everyone write their web apps in C?

YES. And you'll like it too, dammit!

groovy? why!?

[recharged95]

They would be better served if they offered scala support. I notice a movement toward scala/groovy code frameworks vs. the Ruby/PHP ones lately.

Then again, Groovy is very popular now, where as Scala is becoming (as per the twitter announcement yesterday).

Re:groovy? why!?

[pohl]

Scala

- Scala works out of the box.
- Scala Actors do not work, because they are implemented using Threads (which are not supported).
- The Lift web framework does not work out of the box, because it depends on Actors and JDBC.

Re:Groovy? Why not java?

[dfdashh]

I was forced to learn it for the job (Quest Foglight uses Groovy for its internal ruleset), but I ended up liking it for its:

• Interactive console
• Perl-like regular expression support
• Optional typing
• Support for "for i in $array" syntax

Google App Engine now with PHP

[Anonymous Coward]

For all you PHP folks out there, GAE + Java + Quercus means PHP is now on Google App Engine: http://weirdhenge.appspot.com/test.php ... once you have Java on a platform a whole world of tools just opens up!

Re:Groovy? Why not java?

[jekewa]

Still funny.

Groovy is to Java as PERL is to C. Many similarities, plenty of points of comparison, some interactivity, arguably some interchangeability. It is not a "super set" or even an extension. It's a new language, written in another language. It's a scripting tool, written in Java, that optionally generates Java for execution not in a Groovy engine.

It doesn't give you "compiled Java" any more than Java gives you compiled Java, and other tools (like gjc) give you native executables from software written in Java.

It's got good. It's got bad. It's new. It leverages old. If you're going to use it, you've got to learn it.

No magic, just different.

Re:cash cow

[jaydonnell]

Let me see if I understand. You read the original comment about cash cows and efficiency. You then read my reply about the jvm being efficient (in the processor time sense) and you decided to laugh at me because java as a language has poor libraries. Really? Please keep talking because your simply digging a deeper hole. Btw, there are many languages on the jvm. I happen to use jruby and would use that on GAE not java. I'm not a fan of java either, but the jvm is a great platform. This past week I wrote a threaded indexer in jruby using java's util.concurrent library. Try that with regular ruby and C then get back to me.

Re:cash cow

[JamesP]

Yes, because it's so hard to use the 2 click, automated IDE function to generate all those getters and setters.

I don't depend on a smart IDE to write python code

You know, that thing that's one of the selling points of OO.

You write exactly as much code as you do in Python, autogenerate convenience methods (getters, setters, toString, etc.).

"Write exactly as much" NOT BY A LONG SHOT.(MyClass class1 = new MyClass() versus class1 = MyClass() just for a start) No need for getters and setters in python. Very rarely used, and you can do without (yes, you can write class1.x = 1 and that's calling a setter function)

How many awesome libraries are there in Java for things like IOC, data access, web frameworks (MVC and otherwise)?

Like Django? ORM and MVC for web. IOC? Try first-order functions.

Some of the best stuff in development was written in Java first (e.g. JUnit, Spring, etc.).

Agreed

Check out the networking portion of your favorite MMO game, it's likely written in Java, server side. Tons of banking software is written in Java once you get past the big iron portion. Tons of sites on the web are as well. Some of the biggest, custom forums in the world are Java (WOW forums are).

Well, so!? This site is Perl, twitter is Scala/Ruby, Pownce is (was) Django, etc, etc And yes, my bank uses Java, I know that.

Yeah, the GP was right, you are ignorant, and don't seem to know what you're speaking about.

Go learn about first-order functions and closures first.

Re:Groovy? Why not java?

[JediTrainer]

Support for "for i in $array" syntax

Agreed with most of your points, but this one has at least been improved in Java (6?) with:

MyObject[] myObjectArray;

for ( MyObject o : myObjectArray ){

}

What about Jython now?

[Kensai7]

Does this Groovy implementation mean now the end of Jython? If Groovy is so "Pythony", is there a real need to further develop Jython?

What are the relative advantages/disadvantages of Groovy over Jython?

Re:What about Jython now?

[shutdown -p now]

The obvious advantage of Jython is that it is Python - so you get to use the existing Python code and libraries.

If you just want a modern dynamic language that runs of JVM, there's no reason to go for Jython over Groovy. Groovy offers much smoother integration with Java platform and libraries, since it was originally designed to do just that.

Re:What about Jython now?

[shutdown -p now]

Totally agreed, which is why I was careful with my wording there:

If you just want a modern dynamic language that runs on JVM ...

Personally, I do not much like dynamic languages for general-purpose programming, and in those very rare cases where dynamic typing is genuinely useful, I prefer it to be opt-in rather than opt-out (such as "dynamic" in C# 4.0). Furthermore, I think that FP languages had many neat ideas (such as variant types and pattern matching) that I also find very useful. So when it comes to JVM, I definitely prefer Scala over Groovy.

Re:What about Jython now?

[LarryRiedel]

Does this Groovy implementation mean now the end of Jython?
If Groovy is so "Pythony", is there a real need to further develop Jython?
What are the relative advantages/disadvantages of Groovy over Jython?

I do not find Groovy to be very Pythony. To me Python seems like a language which has been painstakingly evolved over literally decades to conform to some clear simple principles which make developing software easier. And to me Groovy seems like a hodge-podge mish-mash of stuff thrown together to provide some sort of feature set.

So I hope Jython will continue to be actively developed to provide an implementation of Python for the JVM which is as good as, or maybe better than, the CPython implementation.

Larry

Re:cash cow

[JamesP]

and you decided to laugh at me because java as a language has poor libraries. Really?

You didn't say JVM, you said Java. :) I'm sorry

Still, saying that the JVM is 'far more efficient' than Python is a little exaggeration.

Btw, there are many languages on the jvm. I happen to use jruby and would use that on GAE not java. I'm not a fan of java either, but the jvm is a great platform. This past week I wrote a threaded indexer in jruby using java's util.concurrent library. Try that with regular ruby and C then get back to me.

I couldn't agree more, and I believe that's THE reason Google picked Java, not for "Java" but for everything else on the JVM.

Re:Can't spawn threads or make network connections

[Furry Ice]

Servlets don't restrict network connections, and people do it all the time to talk to their database. I know you're not supposed to spawn threads with EJB (because transaction information is kept in thread local storage), but I don't recall anything about not spawning threads being in the servlet spec. I know of a lot of code that does it in various containers without problems.

Re:Does Groovy...

[dyefade]

Yes, apparently you can now use it on the Google App Engine!

Re:cash cow

[JAlexoi]

What don't you agree about the stated fact that Java is one of the most efficient VMs out there? Python maybe extremely good, but long running applications JVM wins out.
Development speed could be better, but IDE's and other tools make it easier.

Re:cash cow

[owlstead]

It's rather a different thing to compare speed and memory use for *algorithms*. Of course Java uses more memory for the same structures because of overhead, but the 10x to 30x that you see here are of course not something you see when running any reasonably sized application. And I presume they run only one VM per machine - Java applications may safely run in the same memory space, so the initial overhead just stays a couple of MB.

That said, for smaller applications that have to run on many processors, it may make sense to go for C/C++. This is a place where you may put a *lot* of effort to code a rather limited program. Then again, with C/C++ you have a higher risk messing things up, so you would have to use static code analyzers and unit tests before distributing your app over XXX processors (unless you are that superb C/C++ application programmer everybody keeps talking about).

Re:cash cow

[jaydonnell]

You didn't say JVM, you said Java. :) I'm sorry

Clearly in the context of processor efficiency. So now you're claiming that my use of java instead of jvm in the context of processor efficiency leads to a logical reply about poor java libraries?

I know most people that are reading at this point think I should drop this, but I'm endlessly fascinated at the lengths people will go to avoid admitting any form of mistake or oversight.

And the jvm is far more efficient than python. The stuff done with the jit is very impressive.

Re:cash cow

[Luke has no name]

My beef is with the amount of code that has to be written, and the inflexibility of Java.

You just build a class on python, few includes, you're done. Not like Java. Also, no Expando in Java.

There's Expando in Groovy. And Groovy seeks to remove a lot of the syntactic clutter of Java. Read a Groovy book or intro and you'll see its benefits; it's got a lot (most) features of Python/Ruby, etc., while using and being completely compatible with Java.

Re:Does Groovy...

[Luke has no name]

It's open source and not half-assed open spec in a thinly veiled excuse to call itself cross-platform.

It's dynamically typed, which C# doesn't have, though C# 4.0 will have the static type "dynamic".

Other than that, I don't know. P.S., I don't really hate C#.

Re:cash cow

[jaydonnell]

these micro benchmarks don't mean much of anything in all honesty. I'm not sure what you mean by "native code". Java uses a jit so it uses native code for many things. Also, the jvm can make optimizations at run time that no static compiler can.

I'm not a fan of java the language, but the jvm is an awesome piece of software. Sadly I think java the language has given the jvm a bad name.

Re:Can't spawn threads or make network connections

[AKAImBatman]

I don't recall anything about not spawning threads being in the servlet spec.

From the spec:

For example, high-end application servers may limit the creation of a Thread
object to insure that other components of the container are not negatively
impacted.

[...]

It is now a recommendation, instead of a requirement, that the reference to the
request and response object should not be given to the object in other threads -
based on the requirement from JSR-168. Warnings are added when the thread
created by the application uses the objects managed by the container.(2.3.3.3)

You are right, though. I was thinking about the EJB spec, which explicitly disallows threading. With servlets, it's not forbidden but highly discouraged.

Interestingly, the current spec seems to have lightened up on network connections:

Servlets typically run inside multithreaded servlet containers that can handle
multiple requests concurrently. Developers must be aware to synchronize
access to any shared resources such as files, network connections, and as well as the servlet's class and instance variables.

Back before the complete J2EE spec existed, I recall there being a prohibition on making network connections as part of the servlet itself. Generally, you were supposed to use a service of some sort to accomplish tasks that required networked resources. J2EE, of course, provided a number of the required services.

people do it all the time to talk to their database

The proper way to do this in a J2EE environment is to configure the connection in the Directory Server, then do a lookup to obtain a reference to the connection pool. I don't have docs yet for how Google is doing DB connections (something about JDO is mentioned in the brochure), but I imagine it's similar.

Re:cash cow

[Anonymous Coward]

There are plenty of situations where Java is more efficient and better to develop in than Python...

Java has the memory overhead and startup time of the JVM, but once it gets going it wipes the floor with Python - 5-10x faster for any intensive workload.

The Java API is better documented and thought out - and stays backwards compatible. Sure, Python's is more minimalistic, but that's only because it's a bit of a hack job. I like Python, but it's frustrating when they can't even get basic stuff right in the API like having a consistent interface for bzip2 and gzip compression...

It's generally easier, in my experience, to verify the correctness of Java - given that it's a static strongly typed - and the development tools are more mature.

Python's usually better for toy projects, and as a scripting language in the real world, but if you're actually engineering a system... Java (or C/C++, etc) has some serious advantages.

Re:cash cow

[shutdown -p now]

And since 1.6, with annotations and generics, I'm not sure that the complaint about inflexibility is really there.

Annotations and generics have been there since 1.5. However, yes, this is still quite inflexible - what about lambdas, for example (which Python has)?

Re:Groovy? Why not java?

[shutdown -p now]

as a java developer, why would I learn this language when I can just use java?

Dude, like, because it has a totally groovy name! ~

Seriously though, mostly because it has some nice language constructs and syntactic sugar for stuff that is painful in plain Java. If you've ever coded in Python and Ruby, you know what I mean. If you haven't, then you should probably give it a try - getting stuck with a single language, even if presently the most popular one, isn't good for career in long-term.

Re:cash cow

[DragonWriter]

Yes, because it's so hard to use the 2 click, automated IDE function to generate all those getters and setters.

If the idea is that simple that it takes only two commands to fully specify what you need to do, why should those commands have to be to a separate program, rather than your language implementation? To me, the need for that kind of tooling support is a sign that the language is poorly designed for expressiveness. Essentially, your using a "language" that you read, but using a separate visual language (the IDE UI) to actually write it (or using a mix of that and the native language.)

Its better, all other things being equal, for the language you read to be the one you use to write.

How many awesome libraries are there in Java for things like IOC, data access, web frameworks (MVC and otherwise)? There's piles and piles. Are some of them stinkers? Yes, but there's tons of robust, usable, and EFFICIENT frameworks out there.

Yes, there is plenty of great existing Java code. Which is why having language implementations that can interface with and leverage that code is a good thing. Of course, there are plenty of JVM-based languages that do that quite well -- JRuby, Scala, Groovy, Jython, etc. The existence of lots of useful existing Java code is definitely an argument for leveraging the Java platform, but that generally doesn't require using the Java language.

Re:cash cow

[daBass]

Well, there are lies, damn lies and statistics. We'll have to wait and see to find the truth.

I agree Java is very fast and efficient, any algorithm you implement in Java and Python, the Java will run rings around the Python one.

But that is not all there is to it. Modern Java apps tend to use memory and CPU cycle hogging frameworks like Spring and Hibernate.

Then there is the network layer. It is entirely possible to have a very fast server implementation in C running a slower dynamic language and have the sum of the parts outperform a J2EE server.

I am sure a lightweight JSP/Servlet/POJO only Java app on the App Engine can be just as a efficient as an equivalent Python one. But I fear many will use the heavy frameworks and will on average rack up higher utilization charges than those deciding to go with Python.

Let's wait and see...

Re:cash cow

[jedwidz]

If large swathes of your code are auto-generated, that's a clear sign that you're coding at the wrong level of abstraction. And unfortunately Java isn't powerful enough to allow code that is both idiomatic and terse.

Don't forget that most of the development workload is in maintenance, for which all the generated code *does* add significant overheads.

BTW, have you noticed that your auto-generated JavaDocs suck?

Re:Groovy? Why not java?

[zuperduperman]

Dynamic languages are gaining popularity extremely fast for a whole host of reasons. If you haven't used a dynamic language then you probably won't understand why they are attractive very easily, but if you have it will probably seem obvious. They do have a lot of downsides and I think the jury is still out to some extent whether the reams of code now being written in them is going to be maintainable down the track.

Groovy is Java made into a dynamic language and with innumerable convenience features added. The best way to describe it is to imagine if java was turned into Ruby.

I suspect one reason Google has focused on it is because of Grails, which is java's main player in the RAD web-app development arena (more or less the equivalent of Django, which they also support for the Python app engine). It doesn't work on App Engine yet, but I strongly suspect that is where they are headed.

Re:cash cow

[JamesP]

Clearly in the context of processor efficiency. So now you're claiming that my use of java instead of jvm in the context of processor efficiency leads to a logical reply about poor java libraries?

Well, efficiency is a broad word.

I'm endlessly fascinated at the lengths people will go to avoid admitting any form of mistake or oversight.

Well, don't need to go further, it was my mistake and I'm sorry.

And the jvm is far more efficient than python. The stuff done with the jit is very impressive.

Yes, jit is impressive.

Re:Groovy? Why not java?

[jjohnson]

This is ./. We don't want your cogent analogies and your evenhanded, unhypeful treatment here. If one half of your X technology vs. Y technology comparison isn't "users of X will burn in hell", then this is no place for you, and you'd better be moseying along, lest something unfortunate were to occur, you filthy centrist.

Re:cash cow

[Zarf]

And since 1.6, with annotations and generics, I'm not sure that the complaint about inflexibility is really there.

Annotations and generics have been there since 1.5. However, yes, this is still quite inflexible - what about lambdas, for example (which Python has)?

I don't know much about these things but supposedly that's why Groovy Closures are a big deal.

from the link ...

Since Groovy doesn't provide a way to define a closed lambda function and a block of code might not be a closed lambda function at all (because it has free variables), we refer to both as closure - even as syntactic concept.

... which gives Java programmers the ability to use Lambdas or at least lambda like things conceptually ... albeit not in the same ways.

Re:cash cow

[SanityInAnarchy]

For what it's worth, Ruby (and Rails) runs on it now, via JRuby.

But I'm not sure what you're suggesting -- would it be more fair if App Engine offered a C API? Are you wanting x86 (or x86_64) ASM?

Java is one of the more performant languages that isn't actually pre-compiled to binary. Every now and then, people find a benchmark of one little thing that Java actually does faster than C.

Re:Can't spawn threads or make network connections

[rackserverdeals]

I just took a quick look. It's not really a RDBMS but it's more just a persistent object store. It's schemaless and uses JDO to access objects.

This seems to be the type of databases that cloud application service providers are going to. Likely because it's easier to scale these than to scale a real RDBMS.

Re:cash cow

[Coryoth]

Python's usually better for toy projects, and as a scripting language in the real world, but if you're actually engineering a system... Java (or C/C++, etc) has some serious advantages.

If you actually want to engineer a system then Eiffel or Ada have some serious advantages (certainly over C and C++; with Java you might use JML or similar to help).

Re:Does Groovy...

[Bill, Shooter of Bul]

Yeah, it can by dynamically loaded into Java. So you can have this wonderful crazy java application that can modify its own behavior by creating a groovy file and then running it. Self modifying code is awesome. Or alternatively, its runtime behavior can be modified while its running, if you'd prefer. Fix the bug with out taking down the app! Not sure if this would be a good thing in most peoples assessment, but it is in my crazy world.

Re:Can't spawn threads or make network connections

[AKAImBatman]

That's pretty much what I saw as well. (Just got my account approved. Whoohoo!) It looks like the object store is flexible enough to pretend to be a database, so they wrapped it in JDO. Technically, it should be possible to create JDBC drivers for legacy apps as well. Personally, I'm somewhat interested in accessing the object store directly. The API is simple enough to where all the JDO stuff is just cruft when it comes to purpose-built applications. (Good for portability, though.)

Re:Can't spawn threads or make network connections

[rackserverdeals]

Do people still use JDBC directly for webapps? I thought most people were using either JDO/JPA. Most of the JDBC stuff is boilerplate and takes a long time if you have a large database.

I have used this DAO Generator a few times and it really cut down development time when using postgresql databases.

Only free one I found that seems to follow the DAO pattern closely. It's a little rough but it works.

Using Google App Engine I guess is a little more like Hibernate, where it's and object relational store, except without the relational part. You need to handle the relations in your code.

Looks like it also supports JPA.

Re:cash cow

[tordon]

If large swathes of your code are auto-generated, that's a clear sign that you're coding at the wrong level of abstraction.

Err, a human generated getter is the same as a machine generated getter. Abstract that...

BTW, have you noticed that your auto-generated JavaDocs suck?

If you need javadocs to understand machine generated getters and setters, then you are an idiot.

Re:cash cow

[ynef]

Sure, Java is more efficient than Python. But is it more efficient than native code? http://shootout.alioth.debian.org/ has statistics and comparisons for many languages. They wrote the best programs they could to perform different tasks in each language and compared the results.

Your claim that "[t]hey wrote the best programs they could to perform different tasks in each language and compared the results" is incorrect. That is not how the Language Shootout works, unfortunately.

From the FAQ (emphasis theirs):

We are trying to show the performance of various programming language implementations - so we ask that contributed programs not only give the correct result, but also use the same algorithm to calculate that result.

To me, at least, this makes the test results quite useless, unless you want to compare two languages that are very similar to begin with. Thus, comparing a functional language that is amazing at dealing with parallelism (e.g. Erlang) to a procedural one (e.g. C/C++), for instance, is likely very unfair if the same algorithm must be used.

The question, then, is whether Java and C/C++ are similar enough so a comparison like this one can be made. Given their close score (for time consumption, not memory usage) I would say yes, but that is also the only thing these tests show.

Re:cash cow

[tkinnun0]

"Write exactly as much" NOT BY A LONG SHOT.(MyClass class1 = new MyClass() versus class1 = MyClass() just for a start)

Write new MyClass(), press Shift-Home, Shift-Alt-L, Enter produces MyClass myClass = new MyClass(); That's less key presses and the IDE will automatically create an unused name.

Re:cash cow

[tkinnun0]

To me, the need for that kind of tooling support is a sign that the language is poorly designed for expressiveness.

You don't need to do it and how you use it tells something to the reader. An unencapsulated field says "this is a throwaway class, do not reuse". An encapsulated field with default getters and setters says "this class participates in a bean framework, renaming the field and its getters and setters may break code without compile-time errors". Customized getters and setters, with or without an associated field say something else.

In every case, IDE support for generating those getters and setters is something you either don't use, use as-is or use as a basis to build on. Which brings us to the age-old debate on whether the reduction in source code size is worth the reduction in IDE support.

Re:Can't spawn threads or make network connections

[AKAImBatman]

Do people still use JDBC directly for webapps?

There are tons of examples of roll-your-own O/R mapping tools out there. JDBC is the basis for all of them. So if you support JDBC, you know that you can support everything from raw access to JDO and everything in-between. :)

Re:Can't spawn threads or make network connections

[jsight]

Those are the same restrictions Java Applets have due to the Security Manager, and somehow programmers manage to develop useful applets.

Applets can spawn threads and make network connections (as long as the follow the same origin policy).

Ow...

[ravster]

My brain hurts.

I'm just going to curl up now

Re:cash cow

[shutdown -p now]

... which gives Java programmers the ability to use Lambdas or at least lambda like things conceptually ... albeit not in the same ways.

But it doesn't. It only gives Groovy programmers the ability to use closures. And Scala does the same thing, too.

Anyway, the original point to which I was replying was, "since 1.6, with annotations and generics, I'm not sure that the complaint about inflexibility is really there."

Re:Groovy? Why not java?

[flumps]

I've been delving into Groovy... it's a paradigm shift and it's very hard not to be so verbose.

It isn't, as the article suggests, a superset of Java .. there are things you cannot do in it (yet) but lots of things you can.

What I mainly thought when I saw it was "finally, Java has caught up with the rest of the programming world and has a scripting language at last".

When I used it, it became apparent that this was more than a perl to meet C's needs. It was like the cheeky bastard child of Java who can do what his dad can but faster... and you get properly compiled class files out of the compiler.

Anyway I wrote a mud engine that runs groovy scripts to teach myself. The main failing of the groovy package is the Groovy Script Engine. It promises so much and doesn't always deliver. Unfortunately my mud engine is based around the darned thing, so until they fix it properly I'm stuck with it being a bit clunky.


Check it out, and you can muck about with groovy too (please don't laugh at my programming :):

http://code.google.com/p/groovymud/

:P

Re:Groovy? Why not java?

[badkarmadayaccount]

<joke>C'mon Stallman, get an account already!</joke>

Re:Does Groovy...

[badkarmadayaccount]

No strings (no pun intended) attached, for instance.

Re:Does Groovy...

[badkarmadayaccount]

I was insinuating something about their agreement with Novell.
Call me paranoid, but there is not much business sense behind such pure altruism. They are up to something.

Re:Does Groovy...

[badkarmadayaccount]

I don't know dude, irrational decisions are characteristic of M$, and I'm just being healthily suspicious.

PHP now on the GAE

[whoisthis]

Run PHP on your google app engine. See details http://www.webdigi.co.uk/blog/2009/run-php-on-the-google-app-engine/