Google App Engine Adds Java Support, Groovy Meta-Programming 168
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."
Awesome (Score:3, Insightful)
This really opens the floodgates for cloud computing. I can't wait to port to this platform.
Re:cash cow (Score:5, Insightful)
Re:cash cow (Score:4, Insightful)
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 [snaplogic.org]. 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:cash cow (Score:3, Insightful)
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 [google.com]
with this: http://code.google.com/appengine/docs/python/datastore/entitiesandmodels.html [google.com]
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:Looks like Python (Score:3, Insightful)
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:cash cow (Score:3, Insightful)
*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:Groovy? Why not java? (Score:5, Insightful)
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 (Score:3, Insightful)
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.