Published: Oct 20 2009 / 01:02
I think the most interesting thing about this framework is Java isn't used at development time (http://www.playframework.org/documentation/1.0/main):
"Don’t look for compiled Java classes. The framework compiles the Java source code at runtime and only keep compiled classes in a bytecode cache under the tmp directory. The main executables artifacts in a play application are the .java source files, not the compiled classes."
And the Servlet API isn't used either (http://www.playframework.org/documentation/1.0/faq):
"Play is standard Java, so any standard Java library can easily be used. However keep in mind that Play does not use the Servlet API (even if you can get it work in a standard servlet container using the WAR export)."
Well, I'm wonder if you are ironic, Matt ? :)
No, I (genuinely) am curious to know how the Java files are read and executed. I haven't made the time to read through the source to see, but I'm sure it's pretty slick.
Well, it is pretty simple in fact. Play just has it own application ClassLoader. And when the JVM asks this classloader for a Class, it just search for a .java file instead of a .class file and give it to the eclipse compiler (we embed it).
And after the classic compilation we do a little of bytecode enhancement (using Javassist); yes we need a little of black magic to retrieve local variable names at runtime, or transform all the static methods of the Model superclass to polymorphic methods.
In a way like the Resin feature where the app server takes care of compiling? So instead of the IDE or 3rd party builder the container/framework monitors the .java timestamps.
People can't be ironic. Situations are ironic. People are sarcastic.
But back to the actual subject. Play! certainly looks interesting. You guys did a good job on the "5 minute test" of stating why someone might want to take a closer look. You have some unique features there. It's great to see Java web frameworks come out that are focused on simplicity, agility, little configuration, and giving more to the developer than the developer has to give to the framework!
Congratulations on your release. I'll be checking it out, being a web framework junkie ;-)
PHP must be shifted by either Java or .NET languages like C# and ASP
It's been a long time coming. I have a similar concept for my custom framework - stateless, java based, supports openid, method execution from views thanks to el-functors... Mine doesn't expose restful urls, and embeds spring for convenience but at the day its the same concept - better Java development through a stateless, no-hassle development paradigm.
It's the future of Java web definitely. The next layer will simply add components to it.
Looks good but there are somethings I didn't like it for example the template uses something based on Groovy? whats that. I would prefer something that everybody knows as Velocity or Freemarker are superior and easy to use. Then Java it feels static to this way of development, I would prefer to use Groovy and Grails or Python and Django or Ruby and Rails. Its amazing what they are trying to do but I don't feel it natural as the dynamic languages. With Java I prefer to use straight Spring MVC or Wicket etc. This is just my opinion.
But I want to say Congratulations for this great job to the team.
Velocity or Freemarker are great for sure, but I don't think they are superior. The play template stuff is very very cool. Moreover we needed some things that doesn't exists in other templating engine as the integrated reverse routing or i18n capabilities.
I have to admit Java is not as cool as Ruby. But it has some advantages. Way more faster and robust. A lot of tools. And of course a lot of developers. Moreover when we'll support Scala I think it will be even cooler than Ruby;
Html tags not supported. Reply is editable for 5 minutes. Use [code lang="java|ruby|sql|css|xml"][/code] to post code snippets.