Introducing Play 2.0

2427 views
Skip to first unread message

Guillaume Bort

unread,
Sep 7, 2011, 5:39:15 AM9/7/11
to play-fr...@googlegroups.com
Hi everyone,

Since 2007, we have been working on making Java web application
development easier. Play started as an internal project at Zenexity
and was heavily influenced by our way of doing Web projects: focusing
on developer productivity, respecting Web architecture, and using from
the start a fresh approach to packaging conventions - breaking where
it made sense the so-called JEE best practices.

In 2009, we decided to share these ideas with the community as an open
source project. The immediate feedback was extremely positive and the
project gained a lot of traction. Today - after two years of active
development - Play has several versions, an animated community of
3,000 people, with a growing number of applications running in
production all over the globe.

Opening a project to the world certainly means more feedback, but it
also means discovering and learning about new use cases, requiring
features and un-earthing bugs that we were not specifically considered
in the original design and assumptions. During the two years of work
on Play as an open source project we have worked to fix all of these
kind of issues, as well as to integrate new features to support a
wider range of scenarios. As the project has grown, we have learned a
lot from our community and from our own experience - using Play in
more and more complex and varied projects.

In the meantime, technology and the Web have continued to evolve. The
Web has become the central point of all applications. HTML, CSS and
Javascript technologies have evolved quickly - making it almost
impossible for a server side framework to follow. The whole Web
architecture is fast moving towards real-time, and the emerging
requirements of today's project profiles means SQL no longer works as
the exclusive datastore technology. At the programming languages level
we've witnessed some monumental changes with several JVM languages,
including Scala, gaining popularity.

That's why we think it's now time to move on, and to consider the next
major version of Play. Welcome Play 2.0!

Native support for Java and Scala
---------------------------------

In Play 1.1, we started exploring the possibility of using the Scala
programming language for writing Play applications. We initially
introduced this work as an external module to be able to experiment
freely without impacting the framework itself.

Properly integrating Scala into a Java-based framework is not trivial.
Considering Scala’s compatibility with Java, one can quickly achieve a
first naive integration that simply uses Scala’s syntax instead of
Java’s. This, however, is certainly not the optimal way of using the
language. Scala is a mix of true object orientation with functional
programming. Leveraging the full power of Scala requires rethinking
most of the framework’s APIs. After several versions we now have a
clean Scala module that allows the use of most of Play's features from
Scala, in a Scala-ish manner.

Now, we are reaching the limits of what we can do with Scala support
as a separate module. Initial design choices we made in Play 1.x,
relying heavily on Java reflection API and byte code manipulation,
have made it harder to progress without completely rethinking some
essential parts of Play’s internals. Meanwhile, we have created
several awesome components for the Scala module, like the new
type-safe template engine and the brand new SQL access component
Anorm. So we have decided that, to fully unleash the power of Scala
with Play, we are moving Scala support from a separate module to the
core of Play 2.0, which will be designed from the beginning to
natively support Scala as a programming language.

Java, on the other hand, is certainly not getting any less support
from Play 2.0; quite the contrary. The Play 2.0 build provides us with
an opportunity to enhance the development experience for Java
developers. Backed by our experience throughout the project we have a
clear idea of what we need to achieve and what mistakes we have to
avoid.

Powerful build system
---------------------

From the beginning we have chosen a fresh way to run, compile and
deploy Play applications. At the time it may have looked like an
esoteric design - but it was crucial to providing an asynchronous HTTP
API instead of the standard Servlet API, short feedback cycles through
live compilation and reloading of source code during development, and
promoting a fresh packaging approach. Consequently, It was difficult
to make Play follow the standard JEE conventions.

Today, this idea of container-less deployment is more and more
accepted in the Java world. It's a design choice that has allowed the
Play framework to run natively on platforms like Heroku, which
introduced a model that we consider the future of Java applications
deployment on elastic PaaS platforms.

Existing Java build systems, however, were not flexible enough to
support this new approach. Since we wanted to provide straightforward
tools to run and deploy Play applications, in Play 1.x we created a
collection of Python scripts to handle all build and deployment
related tasks.

But developers using Play for more enterprise-scale projects, which
require build process customization and integration with their
existing company build systems, were a bit lost. The Python scripts we
provide with Play 1.x are in no way a fully featured build system and
are not easily customizable. That's why we've decided to go for a more
powerful build system for Play 2.0.

As we need a modern build tool, flexible enough to support Play
original conventions and able to build Java and Scala projects, we
have chosen to integrate SBT in Play 2.0. This, however, should not
scare existing Play users who are happy with the simplicity of Play
build. We are leveraging the same simple play new, run, start
experience on top of an extensible model: Play 2.0 will come with a
preconfigured build script that will just work for most users. On the
other hand, if you need to change the way your application is built,
deployed, etc., a Play project being a standard SBT project will hand
you all the power to customize and adapt it to your special needs.
This also mean better integration with Maven projects out of the box,
the ability to package and publish your project as a simple set of jar
files to any repository, and especially live compiling and reloading
at development time of any depended project even for standard Java or
Scala libraries projects.

Focused on type safety
----------------------

One benefit of using Java as programming language for writing Play
applications is that the Java compiler can check certain parts of your
code. This is not only useful for detecting mistakes early in the
development process, but it also makes it a lot easier to work on
large projects with a lot developers involved.

Adding Scala to the mix for Play 2.0, we will clearly benefit from
even stronger compiler guarantees - but that’s not enough. In Play
1.x, the template system is dynamic, based on the Groovy language, and
the compiler can’t do much for you. As a result, errors in templates
can only be detected at runtime. The same goes for verification of
glue code with controllers.

We really want to push further this idea of having Play check most of
your code at compilation time in the 2.0 version. Accordingly, we have
decided to use the Scala based template engine as the default for Play
applications - even for developers using Java as the main programming
language. This doesn't mean that you have to become a Scala expert to
write templates in Play 2.0, just like you were not really required to
know Groovy to write templates in Play 1.x. Scala will be mainly used
to navigate your object graph in order to display relevant information
with a syntax that is very close to the Java one. However if you want
to unleash the power of Scala to write advanced templates
abstractions, you will quickly discover how Scala, being expression
oriented and functional, is a perfect fit for a template engine.

And that's not only true for the template engine: the routing system
will also be fully type-checked. Play 2.0 will check all your routes'
descriptions, and verify that the everything is coherent, including
the reverse routing part.

As a nice side effect, being fully compiled, the templates and route
files will be easier to package and reuse and you can expect high
performance gain on these parts at runtime.

Built for asynchronism
----------------------

Today's web applications are integrating more concurrent realtime
data, so web frameworks need to support a full asynchronous HTTP
programming model. Play 1.x was initially designed to handle classic
Web applications with many short lived requests. But now, the event
model is the way to go for persistent connections - though comet,
long-polling and WebSockets.

Play 1.2 already provides great asynchronous HTTP support and
WebScokets using continuations. Play 2.0 will be architected from the
start under the assumption that every request is potentially long
living. We want, for instance, to generalize Controller and
WebsocketController concepts into one single simple model that fits
all needs.

But that’s not all: we also need a powerful way to schedule and run
long running tasks. Although the original Play 1.0 Jobs model was
introduced for this, we really need something more powerful and
robust. The Actor based model is unquestionably the best model today
to handle highly concurrent systems, and the best implementation of
that model available for both Java and Scala is Akka - so it's going
in. We will be introducing native Akka support for Play applications,
making it possible to write highly distributed systems.

Datastore and Model integration
-------------------------------

Datastore is no longer synonymous with "SQL database", and it probably
never was. A lot of interesting models of datastores are becoming
popular, providing different properties for different scenarios. For
this reason it has become difficult for a Web framework like Play to
make bold assumptions regarding the kind of datastore that will be
used by developers. A generic play.db.Model concept in Play no longer
makes sense, since it is almost impossible to abstract over all these
kinds of technology with a single API.

We want to make it really easy in Play 2.0 to use any datastore
driver, ORM, or any another database access library without any
special integration with the Web framework. We simply want to offer a
minimal set of helpers to handle common technical issues, like
managing the connection bounds. We also want, however, to maintain the
full-stack aspect of Play framework by bundling default tools to
access classical databases for users that don't have specialized
needs.

Today, the preferred way for a Play Java application to access an SQL
database is the Play Model library that is powered by Hibernate. But
since it's annoying in a stateless Web framework like Play to manage
stateful entities such as the ones defined in the official JPA
specification, we have provided a special flavor of JPA keeping things
as stateless as possible. This forced us to hack Hibernate in a way
that is probably not sustainable in the long term. To address this, we
plan to move to an existing implementation of stateless JPA called
EBean. If you don't care too much about what is used under the hood
then it will change almost nothing for you, but if you really want to
use Hibernate or even another official JPA implementation you will be
able to do it without any special integration with Play. And if you
are using Scala we will continue to bundle Anorm.

Changes for current Play users
------------------------------

Play 2.0 will be a major release so it is unlikely that it will be
compatible at the API level with previous versions. Of course at the
architecture level you will find the same set of components, organized
in the same way, and most importantly, you will live the same 'Play
experience'.

What about my existing Play applications? How difficult will it be to migrate?

Don't worry, we don't expect you to migrate your existing applications
to Play 2.0. The Play 1.x versions will continue to be maintained and
you don't need to move to Play 2.0. We ourselves have many Play 1.x
web applications running and we will of course continue to support
them.

Remember: Play 1.2.3 is still the best way to write Web applications
in Java while Play 2.0 is still under development, and will continue
to be maintained and developed by the core team and contributors. Play
2.0 is an opportunity to move to for your next project, or the next
major rewrite of your application.

Getting started
---------------

Play 2.0 is still under heavy development and APIs are likely to
change, but you can already have a look to our preview versions. We
have set up a new GitHub repository to host the development, and we
have released a first preview version.

On the dedicated page at http://www.playframework.org/2.0, you can
track progress on this exiting project.

Have fun!

--
Guillaume Bort, http://guillaume.bort.fr

GrailsDeveloper

unread,
Sep 7, 2011, 6:12:57 AM9/7/11
to play-framework
Hi,

that sound like a good new direction for play. Would be great to have
the possibility to use the Scala-Template right now in a java-play-
project. Perhaps someone can show how this is possible. This enables
to avoid a migration of the templates.
2 question are still open to me:

1. Will the new framework mainly developed in Scala? I think this is
an important issue, because at the moment it's really easy for an
experienced java developer to analyze the code and create patches. How
will it be in the future? In other words, will you try to write as
much code as possible in Java and use only Scala where necessary or
the other way around?

2. CRUD based at the moment bold on JPA. Will there be a CRUD-Module
in the future?

Wish you great luck and a quick progress on Play 2.0. A beta at the
end of the year sounds great to me.

Niels
> On the dedicated page athttp://www.playframework.org/2.0, you can

Pascal Voitot Dev

unread,
Sep 7, 2011, 6:27:33 AM9/7/11
to play-fr...@googlegroups.com
Globally, this sounds good new directions...

I have the same questions as Niels.

Moreover, when you foresee to integrate EBean, please also think about other frameworks (mine is siena as you may know) which will need to be integrated and do not wire everything too much tightly. In an ideal world, I would like to be able to remove completely EBean if I don't want it and replace it by Siena!

Anyway, I'm eager to see next steps and if you need help, don't hesitate to ask!

regards
Pascal


--
You received this message because you are subscribed to the Google Groups "play-framework" group.
To post to this group, send email to play-fr...@googlegroups.com.
To unsubscribe from this group, send email to play-framewor...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/play-framework?hl=en.


Bing Ran

unread,
Sep 7, 2011, 6:34:35 AM9/7/11
to play-fr...@googlegroups.com
I kind of like having another pure Scala framework created that is a port of the current Play Java and let the current Play be pure Java.

Bing

Guillaume Bort

unread,
Sep 7, 2011, 6:36:12 AM9/7/11
to play-fr...@googlegroups.com
> 1. Will the new framework mainly developed in Scala? I think this is
> an important issue, because at the moment it's really easy for an
> experienced java developer to analyze the code and create patches. How
> will it be in the future? In other words, will you try to write as
> much code as possible in Java and use only Scala where necessary or
> the other way around?

Most part of the core (HTTP and asynchronous invocation handling) will
be written in Scala, because it is really easier and more robust
(avoiding mutable states in this part will just make it easier to
debug and maintain).

But all the Java related API will be written in Java. Because we want
to provide an idiomatic API for Java and not force Java developers to
deal with Scala types. Also we want to have a clean Javadoc for the
Java API.

> 2. CRUD based at the moment bold on JPA. Will there be a CRUD-Module
> in the future?

I don't think so, or perhaps as an external module for particular ORM.
But trying to provide an unified CRUD module for all persistence
engines we can imagine is way too difficult. Anyway I think that the
current CRUD module is not flexible enough. It mainly solve the need
of writing a lot of repetitive screens, but It think it can be solved
with a better form/paginated list, tag components instead. But nothing
is decided yet.

> --
> You received this message because you are subscribed to the Google Groups "play-framework" group.
> To post to this group, send email to play-fr...@googlegroups.com.
> To unsubscribe from this group, send email to play-framewor...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/play-framework?hl=en.
>
>

--
Guillaume Bort, http://guillaume.bort.fr

Guillaume Bort

unread,
Sep 7, 2011, 6:39:02 AM9/7/11
to play-fr...@googlegroups.com
> Moreover, when you foresee to integrate EBean, please also think about other
> frameworks (mine is siena as you may know) which will need to be integrated
> and do not wire everything too much tightly. In an ideal world, I would like
> to be able to remove completely EBean if I don't want it and replace it by
> Siena!

It exactly what we count on. That's why, even if we provide a default
ORM for Java to keep the fullstack aspect of Play, allowing users to
create quickly web applications, we won't integrate it too much with
the other parts of the framework. It is really important for us that
we can use whatever persistence engine you want with Play 2.0, without
need to hack it.

Please track the progress, and if you think that we make choice that
could limit integration with other persistence engine, in particular
Siena, tell us!

Pascal Voitot Dev

unread,
Sep 7, 2011, 6:44:52 AM9/7/11
to play-fr...@googlegroups.com
On Wed, Sep 7, 2011 at 12:39 PM, Guillaume Bort <guillau...@gmail.com> wrote:
> Moreover, when you foresee to integrate EBean, please also think about other
> frameworks (mine is siena as you may know) which will need to be integrated
> and do not wire everything too much tightly. In an ideal world, I would like
> to be able to remove completely EBean if I don't want it and replace it by
> Siena!

It exactly what we count on. That's why, even if we provide a default
ORM for Java to keep the fullstack aspect of Play, allowing users to
create quickly web applications, we won't integrate it too much with
the other parts of the framework. It is really important for us that
we can use whatever persistence engine you want with Play 2.0, without
need to hack it.

great :)
 

Please track the progress, and if you think that we make choice that
could limit integration with other persistence engine, in particular
Siena, tell us!


Yes now that Siena is near its final version 1.0.0 (just need mongoDB impl to definitely prove the design works), I will look at play2.0 a bit nearer and will tell you if I see any problems... Your scala evolution will certainly help me to develop the Siena4Scala also!
 
Pascal

Guillaume Bort

unread,
Sep 7, 2011, 6:46:46 AM9/7/11
to play-fr...@googlegroups.com
Developing a Web framework like Play is a lot of work, and maintaining
2 different versions would be terribly difficult. It's already the
case currently with the Scala module that is always behind the main
framework.

We prefer to merge efforts to provide a single perfect framework that
will support Scala and Java independently.

Pascal Voitot Dev

unread,
Sep 7, 2011, 6:51:28 AM9/7/11
to play-fr...@googlegroups.com
I agree with you...
Now that I know better Scala (and love it more and more), I know that you can write the core in Scala and make it fully available to any Java application and provide some external full-Java APIs without any problem.
The only drawback is for people who liked to modify the code and now they will need to know Scala. But anyway, I agree with you, maintaining 2 frameworks would be crazy!

pascal

Hristo Deshev

unread,
Sep 7, 2011, 7:08:32 AM9/7/11
to play-fr...@googlegroups.com
This is both good and bad news. While new and shiny stuff is always great, I guess nobody likes the idea of having a completely different Play framework. I hope you guys are able to define a clear migration path for 1.2.3. users that want to move to 2.0. Especially the ones like me that use the Scala plugin.

One question - will play-scala 1.x eventually move to Scala 2.9.1? I hope that feature isn't planned for the 2.0 version only.

Best,
Hristo

Guillaume Bort

unread,
Sep 7, 2011, 7:18:08 AM9/7/11
to play-fr...@googlegroups.com
> This is both good and bad news. While new and shiny stuff is always great, I
> guess nobody likes the idea of having a completely different Play framework.
> I hope you guys are able to define a clear migration path for 1.2.3. users
> that want to move to 2.0. Especially the ones like me that use the Scala
> plugin.

If you are using the Scala module currently, the migration path to
Play 2.0 will be easy. The most important change that will make
migration to Play 2.0 difficult is the new type safe template engine.
But if you are already using it it will be easy.

> One question - will play-scala 1.x eventually move to Scala 2.9.1? I hope
> that feature isn't planned for the 2.0 version only.

Problem is that Scala 2.9.0 breaks the Java reflection API (they done
it for good reasons however). So migrating the Scala module to 2.9.x
breaks almost everywhere it uses Java reflection API(binding,
fixtures, etc.). It's almost impossible to migrate without rewriting
these parts.

Ivan Meredith

unread,
Sep 7, 2011, 7:24:16 AM9/7/11
to play-fr...@googlegroups.com
Nice! Great to see scala 2.9 in the repo :D

I see anorm hasn't bean ported yet... btw, I take it you meant ebean
for java, anorm still preferred for scala?

Dave Cheong

unread,
Sep 7, 2011, 7:35:00 AM9/7/11
to play-fr...@googlegroups.com
Thanks for the update Guillaume. 

Looks like you are continuing to push the envelope with Play. I know it must have been hard to make the call to make a drastic non-backward compatible change in Play 2.0, but I think it's the right move. I wonder how this will impact the 3rd party modules already available for Play 1.x. How different are things? Would a lot of the modules need to be upgraded?

For me, Play has really been a boon to productivity. I use it all the time and recommend it to everyone I come across. The biggest hurdle is definitely the view/templating layer - it is where I spend 70% of my time at when coding a Play application. There's still a lot of hand crafting and because of its nature, IDE support is pretty bad. I hope the new templating technology alleviates this problem.

dave

Michael Boyd

unread,
Sep 7, 2011, 7:47:17 AM9/7/11
to play-framework
I use Play every day in many sites, and I'm now really excited about
Play 2! I'm sure it will be great.

However, can I make one suggestion? Don't re-invent the wheel with
type-safe declarations in the Scala templates.
Instead, I think you should use the declarations used in a popular JS
templating library -- preferably Closure Templates/Library.
I do this right now in tags and views, and it makes converting to
Closure Templates much easier:

*{
@param {String} _title
@param {Collection} _items
@param {play.mvc.Router.Route?} _pageLoadUrl (the ? indicates
optional)
}*
...the actual template here...
<h1>${_title}</h1>

Rakesh Waghela

unread,
Sep 7, 2011, 8:02:19 AM9/7/11
to play-fr...@googlegroups.com
Windows is not supported yet ?

Ivan Meredith

unread,
Sep 7, 2011, 8:05:34 AM9/7/11
to play-fr...@googlegroups.com
I imagine you just need to make a windows version of
https://github.com/playframework/Play20/blob/master/play

On 8 September 2011 00:02, Rakesh Waghela <java...@gmail.com> wrote:
> Windows is not supported yet ?
>

> --
> You received this message because you are subscribed to the Google Groups
> "play-framework" group.

> To view this discussion on the web visit
> https://groups.google.com/d/msg/play-framework/-/4WHeNxHSXCAJ.

Daryl

unread,
Sep 7, 2011, 8:21:56 AM9/7/11
to play-framework
Hi

I am going to disagree with some people here, and make a plea to go
the extra mile to make upgrades from old versions as painless as
possible.

You are obviously trying to move things forward, but don't annoy
existing users. We have been using play for live client projects since
version 1.0.1, we are currently running all live applications
(currently about 20) on 1.0.3.3. We have already struggled to upgrade
to 1.2.3 due to fairly large API changes, which in many cases could
have been minimised by keeping some backwards compatible methods while
still adding the new functionality. But the changes have been quite
ruthless and constantly having to revisit old code to upgrade play
versions is a pain many commercial developers could do without. Yes we
can leave applications on the old version, but by deprecating methods
and having them point to newer versions is much nicer for developers
than ruthlessly dumping them. We often want to utilise some of the
fixes & new features, but don't because of the pain to upgrade an
application to support a newer version.

We are not all playing at this (excuse the pun), we are trying to run
commercial development businesses, and don't want to be penalised for
being an early adopter by people taking theoretical high ground on
backwards compatibility. Backwards compatibility is price that
successful and stable projects have to live with. I appreciate this is
major version we are talking about here, but the more consideration
for this the better.

So having said that, and with all the talking of making things modular
and plug and play etc. Can things such as the database/storage plugin,
and template languages all be managed as modules. If you could do
this, it would make an upgrade easier, by selecting the JPA/hibernate
module and Groovy template modules as default (per application, not in
Play itself), then the upgrade path will be simpler. Then if you could
specify the database and template settings in an annotation per
controller, it would allow existing code to run, while gradually
converting and creating new functionality on the new modules.

I guess this was rather long and rambling, but essentially, please be
very careful with this. Many of us live in the real world, not fantasy
play land, we need to keep up with latest versions, so make the
upgrade path as simple as possible. I don't always think this happened
with Play. To continue its success, I think it is needed.

Also any ETA on this? It is on my schedule to put the leg work in to
upgrade to Play 1.2.3 over the next couple of months. Is it even worth
doing this? If there is going to be no more substantial development on
the Play 1 branch, I will stick with 1.0.3.2, and only consider the
move to Play 2.

thanks

Daryl.

Guillaume Bort

unread,
Sep 7, 2011, 8:26:56 AM9/7/11
to play-fr...@googlegroups.com
> Nice! Great to see scala 2.9 in the repo :D
>
> I see anorm hasn't bean ported yet... btw, I take it you meant ebean
> for java, anorm still preferred for scala?

It is what will be provided out of the box in the fullstack approach.
But nothing will prevent you to use anything else, either Java or
Scala based.

Guillaume Bort

unread,
Sep 7, 2011, 8:29:15 AM9/7/11
to play-fr...@googlegroups.com
> However, can I make one suggestion? Don't re-invent the wheel with
> type-safe declarations in the Scala templates.

We don't want to reinvent the wheel. The whole approach and syntax is
borrowed from ASP.net Razor template engine. And signature declaration
are just plain Scala declaration.

> --
> You received this message because you are subscribed to the Google Groups "play-framework" group.
> To post to this group, send email to play-fr...@googlegroups.com.
> To unsubscribe from this group, send email to play-framewor...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/play-framework?hl=en.
>
>

--
Guillaume Bort, http://guillaume.bort.fr

Guillaume Bort

unread,
Sep 7, 2011, 8:54:05 AM9/7/11
to play-fr...@googlegroups.com
It is very difficult for a major 2.0 release to promise backward
compatibility without adding a lot of complexity to the project.

What's matter for us is to continue to support and maintain the
previous versions that are already running so many applications. And
we will do it. As you know, when we had the security alert lately, we
fixed all versions, including the 1.0.3.x. And we will continue to do
it, even after the 2.0 release. We have also a lot of applications
running on Play 1.x and we will surely not rewrite them all, or
abandon them.

If you have already several applications running on Play 1.0.3.3 for
your customers, it's fine, there is no need to migrate them. Just
consider 2.0 for you next project, or if it's worse it for a
particular application.

On the other hand, I'm sure than once the 2.0 version will be ready,
the community will help to port the current Groovy template engine or
JPA based Model API as Play 2.0 modules to ease migration of old
projects. It should be fairly easy, just for now we want to focus on
developing the core of the next major version.

> --
> You received this message because you are subscribed to the Google Groups "play-framework" group.
> To post to this group, send email to play-fr...@googlegroups.com.
> To unsubscribe from this group, send email to play-framewor...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/play-framework?hl=en.
>
>

--
Guillaume Bort, http://guillaume.bort.fr

zka

unread,
Sep 7, 2011, 9:31:02 AM9/7/11
to play-framework
Hi,

it sounds great.

I already download the preview, for some reason i prefer java, so
with the new scala template engine, it is possible to place view in
folders ?

views/
my_folder_as_controller_name/
index.scala.html
another_controller_name/
index.scala.html

?

Daryl

unread,
Sep 7, 2011, 9:31:57 AM9/7/11
to play-framework
Thanks Guillaume.

I think the point I was hoping to make, is that the work on making
storage/template functionality pluggable is the key here, then having
modules for Play 1 compatibility is the obvious stepping stone for
upgrades. I would expect the compatibility modules to come later,
ensuring this support and ease of use/configuration is my biggest
concern.

The added bonus of being able to configure this on a controller basis
would also help, allowing the changes to be made over time, while
still supporting the newer options. Is selection of storage/templates
using an annotation per controller an option? If this could be built
in at this early stage, then it gives much more flexibility for
applications to be gradually upgraded? I have seen previous requests/
questions on here, that would have been possible by selecting module/
plugin options per controller, so I think any consideration for this
would be appreciated.

thanks

Daryl.

T.J. Crowder

unread,
Sep 7, 2011, 9:42:02 AM9/7/11
to play-framework
Hi,

Sounds very exciting! Don't let either of the following detract from
the main point that this sounds cool, and it's fantastic to see Play
moving forward, unlike so many projects that get a couple of years in
and just...stop. Clearly not the case here!

I'm sorry to hear you're rewriting a lot of the core in Scala because
it's not a language I know and I have an irrational bias toward
languages that are syntactically derived from B (so C, C++, Java,
JavaScript, C#, etc.). I realize I don't have to know Scala to create
Play apps, but I liked the idea of being able to get my hands dirty on
the internals as necessary (and hopefully contribute back). But I
guess either I'll have to not do that, or I'll have to bite the bullet
and learn a new language. (I've been doing this for well over 20
years, it won't be that much of a problem.)

Since you're going to be doing a lot of work in the source, could I
put in a request for *ALL* public API methods and fields to be fully
Javadoc'd? With more than one-liners (or one-liners linking to the
appropriate further documentation), ideally, but in many cases the
current API docs have no descriptions in the Javadoc at all, or such
minimal ones that they may as well not be there (the annotations in
particular suffer here).

I'm not complaining. Play is clearly a great framework and there is a
fair bit of documentation, but if you're going to be kicking around in
the source *anyway*, improving the Javadoc as you go could be a big
win.

Cheers -- and best of luck with Play 2!
--
T.J. Crowder
Independent Software Engineer
tj / crowder software / com
www / crowder software / com

Guillaume Bort

unread,
Sep 7, 2011, 9:50:27 AM9/7/11
to play-fr...@googlegroups.com
> The added bonus of being able to configure this on a controller basis
> would also help, allowing the changes to be made over time, while
> still supporting the newer options. Is selection of storage/templates
> using an annotation per controller an option? If this could be built
> in at this early stage, then it gives much more flexibility for
> applications to be gradually upgraded? I have seen previous requests/
> questions on here, that would have been possible by selecting module/
> plugin options per controller, so I think any consideration for this
> would be appreciated.

No need annotation for that. It will clearly be different API, so if
you use a statically compiled template it will just be a standard
method call, but if you want to evaluate a Groovy template (if a port
if available in 2.0) you will just have to call render()

Arthur

unread,
Sep 7, 2011, 10:54:06 AM9/7/11
to play-framework
It is great that Play is moving on and not becoming stale.

I've just been looking through the kiki sample code; not downloaded it
yet as I'm currently at work. In the views, the controllers package
is being imported using the line
@import controllers._

Couldn't the controllers always be imported by default; so that this
piece of boilerplate isn't needed at the beginning of every view.

See https://github.com/playframework/Play20/blob/master/samples/kiki/app/views/hello.scala.html
for example.
> popular, providing different properties for different ...
>
> read more »

Guillaume Bort

unread,
Sep 7, 2011, 11:03:25 AM9/7/11
to play-fr...@googlegroups.com
> Couldn't the controllers always be imported by default; so that this
> piece of boilerplate isn't needed at the beginning of every view.

Probably, nothing is final yet. But in 2.0 we will not block users to
use another namespace for controllers anyway.

> --
> You received this message because you are subscribed to the Google Groups "play-framework" group.
> To post to this group, send email to play-fr...@googlegroups.com.
> To unsubscribe from this group, send email to play-framewor...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/play-framework?hl=en.
>
>

--
Guillaume Bort, http://guillaume.bort.fr

jgeiger

unread,
Sep 7, 2011, 11:04:17 AM9/7/11
to play-fr...@googlegroups.com
How usable is Play 2.0 right now? If I'm starting a new app today is it in a usable state that would let me do actual development? Are the pieces listed in the roadmap in place or just suggestions for now?

Thanks.

Pascal Voitot Dev

unread,
Sep 7, 2011, 11:06:01 AM9/7/11
to play-fr...@googlegroups.com
On Wed, Sep 7, 2011 at 5:03 PM, Guillaume Bort <guillau...@gmail.com> wrote:
> Couldn't the controllers always be imported by default; so that this
> piece of boilerplate isn't needed at the beginning of every view.

Probably, nothing is final yet. But in 2.0 we will not block users to
use another namespace for controllers anyway.


the most boring IMO are the implicits also... quite verbose
 

Guillaume Bort

unread,
Sep 7, 2011, 11:51:42 AM9/7/11
to play-fr...@googlegroups.com
No you can't use for now, this is just a preview.

> --
> You received this message because you are subscribed to the Google Groups
> "play-framework" group.

> To view this discussion on the web visit

> https://groups.google.com/d/msg/play-framework/-/H7nsQLwGxQkJ.

will

unread,
Sep 7, 2011, 12:31:44 PM9/7/11
to play-framework

This is a fantastic release, especially with the native support for
Akka and async request.

Slightly off topic, does anyone know the comparison between Akka and
Node.js in term of memory consumption per connection, max connections
supported, and message latency? I'm investigating using Node.js for a
project with large number of connections but small message data set
(e.g. 100K idle connections per node but hundreds of bytes messages
occasionally to 1K connections). Thanks.

Sylvain Wallez

unread,
Sep 7, 2011, 1:24:21 PM9/7/11
to play-fr...@googlegroups.com
Le 07/09/11 11:39, Guillaume Bort a �crit�:
That's why we think it's now time to move on, and to consider the next
major version of Play. Welcome Play 2.0!

The plan looks really good!

The 2.0 website says " To get involved, please follow the development mailing list". Where is this list? I'm really interested in lurking there and possibly contribute once I feel comfortable enough with the new code base (and can stand the development pace).

Thanks,
Sylvain
-- 
Sylvain Wallez - http://bluxte.net

Rakesh Waghela

unread,
Sep 7, 2011, 1:28:25 PM9/7/11
to play-fr...@googlegroups.com

The author of the Lift Web Framework justifies the coexistence of Java and Scala both.
But it should not be enforced. Play ! is a revolution of Java world. Hopefully Java elements of Play ! prevails.

Especially in Template creation. why couldn't we have a template system with Java ? If it already exists as a module(Japid) in 1.x why not promote and make it better  in 2.x ?

Quote from that blog post

"What has changed is that I've realized that there's a vast quantity of development shops where the developers show up, have a few meetings, write a few lines of code and go home.  I've had experience with three instances of that kind of company over the last year.  One adopted Scala, is struggling, but trying to do the right thing despite problems with Java written in Scala, recruiting developers, and internal resistance.  One made the decision not to adopt Scala (although there's a little Scala that the VP Eng doesn't know about in production, but it's maintained by one person for whom Scala is vastly better at the task than Java.)  One made the decision to roll back from Scala back to Java because the institutional cost of replacing half their development staff, sending 25% of the remaining staff to expensive courses, and foregoing outsourcing parts of the project outweighed the value that Scala was bringing to the top 3 developers (although it was a very tough and close call.)"

My request to Experienced Play Developers / Authors
Don't miss the big business world heavily invested in Java **Language** .
Play ! has just taken the baby steps in the real business shops.. let it grow !

durre

unread,
Sep 7, 2011, 3:08:43 PM9/7/11
to play-framework
I'm still "high" on Play 1.2 and I'm loving every second of my
javaprogramming with play. I'm a bit afraid to look at the Scala
module and loose the momentum I'm in right now. This will change once
2.0 makes the first real release, then I'll make the plunge for new
webapps.

I'm just thrilled to see such a focused and productive core developers
that keep the framework I love on the cutting edge. Hope to join you
there soon :)

Thanks!
> That's why we think it's now time to move on, and to consider the next
> major version of Play. Welcome Play 2.0!
>

Manh Do

unread,
Sep 7, 2011, 3:24:13 PM9/7/11
to play-framework
I've been using Play! and I'm loving it so far.

It looks like you are planning to integrate Akka Actors. This is
definitely good news and it's definitely a step forward in providing
better concurrency.

Have you try looking into the Disruptor framework? I've ran several
tests and its performance is quite good. Configuring an asynchronous
ordered event processing is quite easy as well. I am planning to use
the Disruptor in my application in conjunction with Play.

Here's a link if you're interested: http://code.google.com/p/disruptor/

I am thinking that utilizing the Disruptor for request dispatching
would be quite beneficial.

In either case, I can't wait to for the release of Play 2.0. When do
you expect Play 2.0 to be release? I am in the midst of creating a
high performance / scalability application and am anxious to
intergrate with the next version of Play 2.0 for its Akka support.
> > WebScokets using continuations. Play 2.0 will be...
>
> read more »

si

unread,
Sep 7, 2011, 4:15:42 PM9/7/11
to play-fr...@googlegroups.com
perfect path, intelligent decision. It seems play will be more than next gen spring. There isn't a web framework that can compete with play 1.2 in any platform already; and play 2.0 is a dream come true in the programming world IMO, thanks guys.

Serdar Irmak

Guillaume Bort

unread,
Sep 7, 2011, 4:19:24 PM9/7/11
to play-fr...@googlegroups.com
> I am thinking that utilizing the Disruptor for request dispatching
> would be quite beneficial.

We are using Akka internally for requests dispatching, and performance
are awesome. You can test the sample application.

> --
> You received this message because you are subscribed to the Google Groups "play-framework" group.

Keith Swallow

unread,
Sep 7, 2011, 4:33:22 PM9/7/11
to play-fr...@googlegroups.com
Congrats on the 2.0. I've heard a couple calls for improved modularity on this thread. I think that the main strong suit of Play (like the Rails 1.x line) was integration of best-of-breed technologies.

The newer Rails stacks are less useful when it comes to getting a new app up and running. I would like to caution all the Play maintainers against too much modularity. If the seams show a lot then the barrier to entry rises and a main benefit (and appeal) of the framework is lost.

Best,

Keith

Sadache Aldrobi

unread,
Sep 7, 2011, 4:41:49 PM9/7/11
to play-fr...@googlegroups.com
I would suggest to anyone having any doubts regarding Play 2.0 to download the preview, try it, create applications, test them, go to the repository, browse source code, read it and judge by yourself. The whole idea is keep close to the community though the implementation of the 2.0.


--
You received this message because you are subscribed to the Google Groups "play-framework" group.
To post to this group, send email to play-fr...@googlegroups.com.
To unsubscribe from this group, send email to play-framewor...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/play-framework?hl=en.




--
www.sadekdrobi.com
ʎdoɹʇuǝ

Manh Do

unread,
Sep 7, 2011, 4:48:18 PM9/7/11
to play-framework
Awesome. I will test it once I get home. :)
> >> > applications - even for developers using Java as the main programming...
>
> read more »

descsuit

unread,
Sep 7, 2011, 5:47:17 PM9/7/11
to play-framework
There has been some mention of reinventing the wheel and when I
started using the Scala plugin one thing lit up a warning sign for me
and that was Anorm.

I'm using Squeryl on my current project and I like it a lot. I looked
at Scala-Query and my Scala chops were just not up to it (barely are
with Squeryl). There are about 3 other database integration packages
for Scala now. So I was wondering, why Anorm? Is it really just an
in-house project?

I could see the same argument being made for the templating engine,
but that is much more tightly integrated with the rest of the project.

Anyway, in general sounds good..

Oh one other question.. you mention having good Java idiomatic APIs,
will there be Scala idiomatic API's as well? Seems like a lot of work
to maintain them both and keep them in sync. Currently the Scala
plugin is lagging and it has a very partial API retool.

Alan

Sadache Aldrobi

unread,
Sep 7, 2011, 6:17:49 PM9/7/11
to play-fr...@googlegroups.com
On Wed, Sep 7, 2011 at 11:47 PM, descsuit <alan.mo...@gmail.com> wrote:
There has been some mention of reinventing the wheel and when I
started using the Scala plugin one thing lit up a warning sign for me
and that was Anorm.

I'm using Squeryl on my current project and I like it a lot.  I looked
at Scala-Query and my Scala chops were just not up to it (barely are
with Squeryl).  There are about 3 other database integration packages
for Scala now.  So I was wondering, why Anorm?  Is it really just an
in-house project?

There is nothing in the market that has the same model as Anorm. Anorm is an API, more like a JDBC with less pain. If you opt for ORMs then choose one and use it, and as you suggest we are not going to re-implement an extra ORM.
 

I could see the same argument being made for the templating engine,
but that is much more tightly integrated with the rest of the project.


Same thing, unfortunately we haven't found anything in the market with roughly the properties we were looking for.

I am not looking for conclusions here, but it is interesting to observe that every component of the framework that people appreciate today had the same "don't reinvent the wheel" critics in the beginning.
 
Anyway, in general sounds good..

Oh one other question.. you mention having good Java idiomatic APIs,
will there be Scala idiomatic API's as well?  Seems like a lot of work
to maintain them both and keep them in sync.  Currently the Scala
plugin is lagging and it has a very partial API retool.

From the sample application in the preview:

    def list(page:Int, sort:String) = {
        
        val p = if(page > 0) page else 1
        
        Secured(p != 42) { 
            Cached(p, sort) { 
                Action {
                    println("Listing page " + p + " using " + sort)
                    Html(views.html.list(p, sort).toString)
                } 
            }
        }  
} 



public class JavaApplication extends Controller {

    @Cached
    public static Result index() {
        System.out.println("REQUEST -> " + request());
        String url = routes.JavaApplication().hello(5, "World").url();
        return Html(javaIndex.apply(url));
    }
I hope this shows an example of how can we address Idiomatic Scala and Java in the same project. It is not easy but we take it seriously.


Sadek

 
Alan


--
You received this message because you are subscribed to the Google Groups "play-framework" group.
To post to this group, send email to play-fr...@googlegroups.com.
To unsubscribe from this group, send email to play-framewor...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/play-framework?hl=en.




--
www.sadekdrobi.com
ʎdoɹʇuǝ

Alison Winters

unread,
Sep 7, 2011, 8:57:32 PM9/7/11
to play-framework
Very interesting stuff Guillaume, it sounds like the team has been
thinking long and hard about the right way forward for Play.

Like some other group members, I also feel some trepidation about
moving so much toward Scala. Although I know it is gaining acceptance
in the real world, Java, Python and even Groovy feel like more
widespread technologies. Also they are all easy to understand, being
standard object-oriented/procedural languages. Scala is a big paradigm
shift for most developers, and I think that will definitely discourage
community contributions. I know you guys will write a good Java API to
access the front end, but I hope module developers and other
"hardcore" contributors will still be able to add features and
functionality without having to delve too deeply into Scala.

I do like the direction overall, though. Although I've never used SBT,
it does seem much tidier to use it for build and deployment (vs custom
Python scripts). I think this is going to be the most important
rationale for upgrading current apps in production. Everyone wants
nicer deployment :) I also like the conciseness of the ASP.NET/Razor-
style template syntax, even if it does mean having to use weird Scala
for loops and closures to do things. I am very familiar with the
quirks of Hibernate, but I think using EBean by default will be a
great advantage for developers new to Java, and it will probably
perform well enough for most projects anyway. It all looks very
exciting.

As a user with Play running in production, I am very interested in how
you will be continuing to support the 1.x branch. I don't expect any
new features now that you are focused on 2.0, and I know you will
probably only be working on bugs that actually break things (rather
than those that are simply annoying), but can we see some kind of
roadmap for those? It would be good to know what is planned to be
addressed for "1.4" and what is just going to be abandoned in the 1.x
tree and targeted for 2.0.

Also the announcement page on the web site looks really cool, nice
coding :)

Alison

Ivan Meredith

unread,
Sep 7, 2011, 9:11:38 PM9/7/11
to play-fr...@googlegroups.com
One request I have is that as you port parts over to play2, please
make them independant libs were possible. A good example is the WS
library, its brillant, I wish I could use it in legacy java apps when
I have to talk to new rest end points. Another is anorm, if I had
anorm as a jar today, it would simplify a migration of a app I
maintain to play. :)

> --
> Guillaume Bort, http://guillaume.bort.fr
>

Xuefeng Wu

unread,
Sep 7, 2011, 10:17:11 PM9/7/11
to play-fr...@googlegroups.com
Thank you play! team and I hope the dream come true more soon.

Is there possible that the typesafe team will contribute or support play!2 and let things happen early?

Christian Koch

unread,
Sep 8, 2011, 2:04:04 AM9/8/11
to play-fr...@googlegroups.com
Good Job! We like the (for Java frameworks) uncommon concepts and we hope that they will remain in Play 2.0.

v6ak

unread,
Sep 8, 2011, 2:22:13 AM9/8/11
to play-framework
It definitely can be ported o Windows without Cygwin. (if exists file,
%someUglyChars0, ...)

On Sep 7, 2:05 pm, Ivan Meredith <i...@ivan.net.nz> wrote:
> I imagine you just need to make a windows version ofhttps://github.com/playframework/Play20/blob/master/play
>
> On 8 September 2011 00:02, Rakesh Waghela <javain...@gmail.com> wrote:
>
>
>
> > Windows is not supported yet ?
>
> > --
> > You received this message because you are subscribed to the Google Groups
> > "play-framework" group.
> > To view this discussion on the web visit
> >https://groups.google.com/d/msg/play-framework/-/4WHeNxHSXCAJ.

Aishwarya Singhal

unread,
Sep 8, 2011, 2:59:31 AM9/8/11
to play-framework
+1 for native Scala and Akka support! I like the sound of it. Thanks
and keep up the good work!

Is there any place I could post some of my wish list (apart from
what's already included in 2.0) ?

PS: Developing with the play-scala support seems to be slower than the
Java one because, if I remember correctly, sbt holds on to a bit of
memory as the code is compiled on the fly. With sbt coming in
mainstream play, is something being done to ease that too (say run sbt
in a separate process and may be have inter process communication) ?

Best regards
Aishwarya

v6ak

unread,
Sep 8, 2011, 3:03:14 AM9/8/11
to play-framework
It should be simple to do so, since Play will move to SBT :-)

I've one question. I've currently a Play!-Scala project with some
Maven-Scala modules. Now, I've to call mvn install on the parent Maven
project, clean a part of Ivy cache (provided that the version has not
been changed), call play modules --sync in the Play! project directory
and restart the Play! app.

If I switch to SBT, how much would it simplify these steps?
* The Play app would probably be able to be moved to a SBT module.
* Since SBT is based on Ivy, there would be no need for cleaning Ivy
cache. (OK, I can do this also in 1.2.* branch.)
* Would I have to restart the Play! app?
* I probably would not need to sync dependencies.
* When downloaded the app from source, would there be a simple command
that would compile everything, test everythingg and run the Play app?

Regards,
Vít Šesták 'v6ak'

On Sep 8, 3:11 am, Ivan Meredith <i...@ivan.net.nz> wrote:
> One request I have is that as you port parts over to play2, please
> make them independant libs were possible. A good example is the WS
> library, its brillant, I wish I could use it in legacy java apps when
> I have to talk to new rest end points. Another is anorm, if I had
> anorm as a jar today, it would simplify a migration of a app I
> maintain to play. :)
>
> ...
>
> read more »

Guillaume Bort

unread,
Sep 8, 2011, 3:16:44 AM9/8/11
to play-fr...@googlegroups.com
> As a user with Play running in production, I am very interested in how
> you will be continuing to support the 1.x branch. I don't expect any
> new features now that you are focused on 2.0, and I know you will
> probably only be working on bugs that actually break things (rather
> than those that are simply annoying), but can we see some kind of
> roadmap for those? It would be good to know what is planned to be
> addressed for "1.4" and what is just going to be abandoned in the 1.x
> tree and targeted for 2.0.

Nothing is decided yet, but we will surely not backport important
changes like the new build system, scala support or the type safe
routing and template engine to the 1.x serie.

However it is likely than we will try to port the existing Groovy
template or the Hibernate based Model engine to the 2.x serie (after
the 2.0 release) to ease the migration. But not as standard default
components.

> --
> You received this message because you are subscribed to the Google Groups "play-framework" group.

> To post to this group, send email to play-fr...@googlegroups.com.
> To unsubscribe from this group, send email to play-framewor...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/play-framework?hl=en.
>
>

--
Guillaume Bort, http://guillaume.bort.fr

grandfatha

unread,
Sep 8, 2011, 4:25:27 AM9/8/11
to play-framework
I always had the fear that Play would get fragmented, because of the
Scala module and the consequence of having to build to separate APIs,
which essentially means having to maintain two different web
frameworks.

I think it is a good idea to unify both in a 2.0 release, because it
is unhealthy to create two different frameworks under the same name.


I hope that while building 2.0, Play#s core developers will remember
that ...


(1) simplicity
(2) developer usability
(3) general feeling of enjoying the use of the tool / APIs


is what brought Play to where it is right now. We dont need another
Lift just for the sake of jumping on the Scala bandwagon. Play has
become big, because it is essentially Django/Rails for the Java world.
If Play 2.0 does not support (1), (2) and (3) in the same way Play 1.0
supported it, I think it would mean its downfall and its usage only
among Scala enthusiasts, which would be a pity since it is making its
move right now into more conservative development shops and becoming
mainstream since it is just plain Java.


tl;dr : Dont fuck up the developer usability of Play by switchting so
much to Scala, please!



Rakesh Waghela

unread,
Sep 8, 2011, 4:30:34 AM9/8/11
to play-fr...@googlegroups.com
Dont fuck up the developer usability of Play by switchting so 
much to Scala, please!  


+1 for templates !

Daryl

unread,
Sep 8, 2011, 4:46:20 AM9/8/11
to play-framework
> The newer Rails stacks are less useful when it comes to getting a new app up and running.
> I would like to caution all the Play maintainers against too much modularity. If the seams
> show a lot then the barrier to entry rises and a main benefit (and appeal) of the framework is lost.

I think this is where the initial design and planning is vital. It
needs to have the modularity to swap modules/plugins in and out. This
has become an increasingly common request on Play 1.0, and it has to
be considered important for this functionality to be included in such
a major rewrite. The trick will be to select the best defaults and
make the ability to create a new app and run straight away without any
configuration as in the current version. Swapping out modules to meet
particular needs will be a conscious decision on the part of a more
experienced developer.

Selecting the best defaults will also be an interesting decision. The
current JPA/groovy templates have a fairly easy learning curve,
allowing beginners to just dive in. If the something more complicated
is bundled as default, it could put beginners off. Maybe there should
be different bundled versions that allow you to get up and running
quickly with different options. Its a fine line between introducing
beginners/ease of use and allowing more experienced users to configure
things as needed.

Interesting times ahead :)

Xuefeng Wu

unread,
Sep 8, 2011, 4:49:56 AM9/8/11
to play-fr...@googlegroups.com
If play!2 is easy and productivity enough, It may could interest developer who  don't know scala or even java.
As the rails which bring new developer into Ruby world.

stefaan luckermans

unread,
Sep 8, 2011, 5:03:04 AM9/8/11
to play-fr...@googlegroups.com
We are one of the companies that try to use Play to build an enterprise app. We have a multi-year planning and our fear now is that in time Play 1.1.1 will no longer be supported and will force us to re-develop all we are currently developing.

For us Play 1.2 was even a big step, because we ruled out the use of maven as to bothersome and about scala? We never heard of it and don't really plan to use it.

Or client are big banks and insurance companies and therefore we stick to old familiar java …

The only 2 things that we are interested in are asynchronous HTTP, because we plan to build a lot of dashboards as well as easy portability to the systems of our clients.

I hope that the Play people could set up a sort of help desk to help companies as ours to decide which Play to use and/or when to make the migration to which version of Play.

The initial ease we found in Play 1.1.1 was fading with Play 1.2 and is now even more fading with Play 2.0.

Interesting detail. My developers are java developers, but not java developers 'pure sang'. They all have a testing background and one of the major reasons to choose for Play was the possibility to approach our app in a test driven way.

I just hope we made the right decision by going with Play ….



Stefaan Luckermans 
Owner of Thaste IT

Gasthuisvest 30
2500 Lier
 
Cell phone: +32 472 103 204
 


On 08 Sep 2011, at 10:49, Xuefeng Wu wrote:

If play!2 is easy and productivity enough, It may could interest developer who  don't know scala or even java.
As the rails which bring new developer into Ruby world.

--
You received this message because you are subscribed to the Google Groups "play-framework" group.
To view this discussion on the web visit https://groups.google.com/d/msg/play-framework/-/GVHW1bbtw1sJ.

Pascal Voitot Dev

unread,
Sep 8, 2011, 5:21:35 AM9/8/11
to play-fr...@googlegroups.com
Guillaume, I'm becoming Scala fan more & more but, according to what some people say, do you think that play2.0 will allow writing modules in Java (and not only in Scala) as simply as now? I mean, a basic developer could write a module without needing to learn Scala...
Following what stefaan said, I think people need to be reassured about the easiness of the Java Api layer to accept play2.0 based on a Scala core... They will come naturally to Scala if they need but basic java developers won't switch to Scala for sure... Some big companies are still stuck on Struts1 and to convince them to try something else, complete technology switch is generally not the best argument...

The short learning curve and the easiness are certainly the best arguments of play in the java world.

Thanks
Pascal
PastedGraphic-1.tiff
PastedGraphic-2.tiff

Ivan Meredith

unread,
Sep 8, 2011, 7:14:26 AM9/8/11
to play-fr...@googlegroups.com
I doubt there is any requirement to write modules in scala. In play 1.x its not like you are limited to java either. I have a module I wrote in clojure for kicks, and the play-scala module is written in scala.
PastedGraphic-2.tiff
PastedGraphic-1.tiff

Guillaume Bort

unread,
Sep 8, 2011, 7:32:54 AM9/8/11
to play-fr...@googlegroups.com
> Guillaume, I'm becoming Scala fan more & more but, according to what some people say, do you think that play2.0 will allow writing modules in 
> Java (and not only in Scala) as simply as now? I mean, a basic developer could write a module without needing to learn Scala...

It can depend of the kind of extensions you want of course, but writing plugins/modules in Java will always be possible.
PastedGraphic-1.tiff