Dec 6, 2012

Thinking about creating an new Java Web framework

Why: I love playframework v1 but not v2. However play team moves their attention away from v1.

What should be kept from v1:

  • Bytecode enhancement. This is a great stuff that enable framework and plugin developer to inject logic into Application code
  • A full stack framework. This should like Play which runs on itself instead of inside a servlet container
  • Support plugins. Though API might changed
  • Handy utility libraries for application developer, like IO, Codec, Images etc.
  • Built in simple Secure framework
  • The DB layer enable plugin different implementations, JPA, EBean, Morphia etc.
  • Built in validation
  • Easy to use asynchronous handling API, like Promise and Controller.await
  • Before, After, Final, Catch intecepters to plugin logic into request handling chain
  • Render with different template based on request.format
  • JavaExtension to template
  • And most important is Simple, Simple and Simple to application developers

What needs to be improved or changed:
  • Routing mechanism. Improve the routing performance for big routing table with more than 100 routes. This might involve code generator to generate routing source code dynamically
  • Action invocation mechanism. Reduce the use of reflection, static methods and Exception. But needs to keep the API still simple though
  • Plugin API. Support partitioned plugin API set instead of all-in-one big facade
  • Replace python stuff with pure script plus Java
  • CRUD
  • Replace default Groovy template engine with Rythm
  • Replace default JPA with Ebean ???
  • JSON support

Proposed Controller API:

public class Orders extends Controller {

  // --- Parameters used in action handling methods
  @Bind(method = Bind.ByID)
  protected Order order; // will bind to http request params with Order.findById(params.get("orderId"))
  @Bind(method = Bind.ById)
  protected User user;
  // -- eof Parameters
  // this use new return style API
  public Result show() {
    return new Render(order);

  // this use old style API
  public void saveUpdate() {
    render(order, user);
  // this action method will be executed in a separate thread
  public Result report() {;
    List orders = ...
    return new RenderPDF(orders);

Sample route file:

GET /orders/{orderId}
POST /orders/{orderId} Orders.saveUpdate
GET /orderReport

What do you think?


orefalo said...


This sounds like a great idea. I actually left the java/play ecosystem when play 2.0 released. The new framework didn't match my expectations - it wasn't playful anymore.

After a few back and forth between technologies, I finally settled on Node.js

What I discovered is a very light set of technologies that work together like charm and make development fun again.
I was just getting up to speed with npm, express, assert-pipeline, when I discovered something really interesting: Meteor (
Built on top of node, Meteor is something really different from the typical MVC page model I was familiar with. Take a look, it may give you some ideas...

Back to your point, a new framework has to fill a gap.

Asynchronous IO in Java? You already have Vert.x and Play 2.0
Fun? that's hard to quantify because we all have different expectations, I am sure people enjoy Wicket
Corporate support? you have fat J2EE+Spring, it's going to be hard to grab attention.

Developing a framework is a full time job, it might be easier to build on top an existing one like (Vert.x)

Hope this helps,

Unknown said...

Hi Olivier,

Thanks for your comments. Yes the effort is the biggest concern. I should take it into serious consideration. The reason I want to create an new framework instead of moving to others like Django, Rails or Meteor is I still love play1.x 's idea, that is to provide fun experience to pure Java programmer.

I feel it is a bit similar to my last year at the same time, when I was thinking about creating an new template engine for Java programmer, it must be easy to use and it should be Razor like. I was not sure if I can make it by that time coz I had zero experience on template engine and I know it's going to take a lot of my time to do that. I should be in better position now :)

So in the end the gap I want to fill is the gap left by play version one, a simple elegant and powerful web framework for Java person.


Bijan said...

Hey Green,

I am with you. Play2 forgot about the values that Play1 was standing for.

I jumped on the node.js train by using meteorjs as it's really a revolutionary paradigm shift in webapp creation.

Why not fork play1, copy the old website and start improving instead of starting from scratch?

Cheers Bijan

R. Rajesh Jeba Anbiah said...

Green, I appreciate your efforts to revive Play1.

While I can't understand your idea/architecture 100%, I think, it would be better to keep the framework more like RoR or CakePHP (100% if not 99% clone).

In Java, Scooter framework is more like RoR, but when I had some questions posted that couldn't get any answers Personally, I find Scooter easier to adopt than Play!, but it seems to be missing few things like render partials and REST routing as in CakePHP (so that any extensions like .json, .xml... can easily be routed to different view).

Why I'm mentioning about Scooter framework is that from my *illiterate* point of view, it could better be enhanced than to enhance Play1.

If we take Play1, I'm not very sure about Ebean Vs JPA, but I'm very comfortable with JPA. For routing, I think, it would be better to keep default routing with strict naming conventions--to avoid bloated routing definitions.

Regarding the need for new framework... for our team, we've now somewhat settled in Play1, but may prefer more RoRish or Nodeish (like Vertx). I'm finding that some "Play! fans" seem to pickup Play2 for the sake of brand Play!. I personally feel that the bullish Play! community has killed (IMHO) better frameworks like ActiveWeb and Scooter... So, please be cautioned about your precious time! If possible, create a github and see how the feature requests are coming up... and then it may be better to proceed your journey. All the best!

bendanpa said...

I am very glad for your idea. One important thing is don.t forget google app engine support. The new framework should have better and continous (and built in?) GAE support. That way most previous and current play/gae developer will migrate. And that will be a very big user base.


Hi Green.

+1 to your idea.

In our company I was thinking of recommending Play! to our company when play2.0 was just out and the dilemma of 1.0 and 2.0 stopped us from using it.

Play 1.x is the best Java Web framework but not supported any more; Play 2.0 is in Scala and no one in our company actually understand it.

Now that you if you are able to gather a force to push play 1.x forward, we could again think about adopting it :-)

But that means, we want solid quality of play 1.2.x. I think it would be better if we fork play1.x and evolve it JUST AS what was expected if play 2.0 never happened. Keep the steady and playful pace once we all enjoyed.

You don't have to write the new framework from scracth, which would take too much time and effort, and will keep away play1.x users.

So at first we don't have to introduce any new features. I think making Rythm as the default template engine would be great.

This comment has been removed by the author.
romka said...

As far as I understand they haven’t refused to develop v1.x, they are planning to release 1.3 with the new hybernate soon.

So, is there any sense? They already have open source. One can just change what you want and make pull request to Play Framework.

Or to make one’s own compilation on the base of Play, that’s the best variant. It means that it will be the core of play 1.3 with the support of morphia and built-in rythm. It will be more comfortable for the beginners as they will receive the functioning product with the best solutions and the users won’t have to think, how it can be installed or what option to choose.

But it will not let to get rid of such things as static methods… (

Anyway the development of the framework is a team task. There are different life circumstances, but there always should be someone, who won’t let the project die, if one member of the team leaves.

All in all, what you want to do is awesome, but I feel a bit worried about this idea, because you will put a lot of work in smth alone, that probably will not bear fruit, as the task is really very complicated.

Good luck, no matter what decision you take, we will support you)

The team of the developers, actively using your solutions. Moscow, Russia

Unknown said...

The situation is play-1.x marked as maintenance in lighthouse, there are 583 open tickets and 495 tickets waiting for triage. I have 11 new open tickets and some of them is 1 years old already.

As you said keep on 1.x line won't change the static methods, neither will they change the plugin mechanism, and some good stuff in play 2, let's say async actor model and non-blocking IO etc.

So all in all I want an new play 2 which favour play 1.x programmer instead of typesafe...

Léo Douglas Padilha said...

+1 to your idea.

Léo Douglas Padilha said...

Could you add the project lombok native

Unknown said...

Hi Green,

I think maybe the most important thing we could do is gather all the 1.x enthusiasts left so even basic development and bug fixing can continue. I'd be interested in just starting with a maintenance branch at least so we can start addressing some issues we're all experiencing.

Perhaps the best way is to just fork 1.x and run everything on github? Unless there's already a popular 1.x branch out there we could join.


Léo Douglas Padilha said...

I agree with you Matt.

Roman Dolgushin said...

I have a different opinion. Building a new framework from stratch is an easier, faster and more enjoyable way than change a huge part of already written code. However, sources of Play 1.x will be very useful as examples and can save most part of development time.

Unknown said...

Nice idea, but I would not change the default template engine to rythm. I would make usage of other engines simplier instead.
Think of following situation:
#{if !request.isAjax()}
#{extends 'main.html' /}
when reloading a part of your site via ajax, you don't want unnecessary parts rendered and you probably don't want to write extra tempate/action for that.
As far as I know rythm does layout-handling at compile time.

Unknown said...

Is there any (simpler or not) template engine process "layout/extends" at runtime?

Usually ajax requests are called to get data (in json most probably), or to retrieve part of a page, e.g. a dialog content. neither one would touch the template layout dispatch at runtime. Instead I prefer to put something like the follows in a controller:

if (!request.isAjax()) {
Applicatin.index(); // redirect to the home page.

Unknown said...

Often I have to reuse templates for a complete detail page and a small informational dialog.
With other engines i need two templates: The view itself and one including the view and extending a layout, because they cannot process "layout/extends" at runtime.
The groovy engine does, so I can do an #{if expr} around layout/extends.

But that is only a nice feature. There is another reason to not change the default engine and that is because the players know their groovy engine. The players who choosed another engine can do that in future, too.

Spikes of Nothingess said...

Hey there - in case you have some spare time, please have a look at (µ)Micro. It is an open source Java framework I created recently with the very same hope of bringing the fun back into the Java web development. Right now I am focusing on integrating various Template engines. Engines supported out of the box so far: Velocity, Freemarker, StringTemplate and Markdown, and I am about to finish the integration with the You can create Controllers using Java classes or scripting; using Beanshell or RhinoJS. The source, the docs and the examples are all on Github, if you guys are interested to contribute or simply fork. Also, I was curios to see how a simple "Hello World" app using Micro compares with a similar one using Ruby/Sinatra, and the results are here:, just in case. Your feedback will be greatly appreciated, thank you!

Unknown said...

So three years passed since I write this post. And the framework I am working on for more than one year is right over there! Although I am still working on polishing the product, writing documents, but it is put into real usage in my company, and I super happy with it.

You guys can have a look at

And I am about to speak on it in the incoming JVM meetup in Sydney at 4/Mar/2016. Exciting about Act!

R. Rajesh Jeba Anbiah said...

Congrats Green for your new framework!

Unknown said...


thanks. You can checkout this blog: