Introducing Play 2.0
Guillaume Bort
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
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
Pascal Voitot Dev
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
Bing
Guillaume Bort
> 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
> 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
> Moreover, when you foresee to integrate EBean, please also think about otherIt exactly what we count on. That's why, even if we provide a default
> 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!
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
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
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
Guillaume Bort
> 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
I see anorm hasn't bean ported yet... btw, I take it you meant ebean
for java, anorm still preferred for scala?
Dave Cheong
Michael Boyd
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
Ivan Meredith
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
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
>
> 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
> 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
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
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
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
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
> 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
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.
>
> read more »
Guillaume Bort
> 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
Pascal Voitot Dev
> Couldn't the controllers always be imported by default; so that thisProbably, nothing is final yet. But in 2.0 we will not block users to
> piece of boilerplate isn't needed at the beginning of every view.
use another namespace for controllers anyway.
the most boring IMO are the implicits also... quite verbose
Guillaume Bort
> --
> 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
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
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 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
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 ?
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
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!
> major version of Play. Welcome Play 2.0!
>
Manh Do
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.
>
> read more »
si
Guillaume Bort
> 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
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
--
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.
Manh Do
>
> read more »
descsuit
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
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.
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));
}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
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
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
Is there possible that the typesafe team will contribute or support play!2 and let things happen early?
Christian Koch
v6ak
%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.
Aishwarya Singhal
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
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
> 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
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
much to Scala, please!
Daryl
> 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.
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
As the rails which bring new developer into Ruby world.
stefaan luckermans
Owner of Thaste IT
Gasthuisvest 30
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
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
Ivan Meredith
Guillaume Bort
homerdoe
1-Speed of reloading(Python scripts)
2-Java
3-JPA
Although i like Scala, i just cannot understand how can someone make
some big business apps without a proper IDE for it.
Seems to me that all the advantages that made me use Play, will be
gone because the scala template and sbt are going to be slower than
the ones java have today. It wont be that easy to use a ORM(JPA)
(millions still do and will for the foreseeable future). And java will
almost be a second citizen.
To conclude, i think all the things that made me go to play will be
gone!
I just dont understand the problem people have with groovy.
Im sorry guys but play may be gone for me, just hope you reconsider
those decisions.
> >> *Owner of Thaste IT
>
> >> *Gasthuisvest 30
> >> 2500 Lier
>
> >> *Cell phone: **+32 472 103 204*
> >> *mailto: <stefaan.luckerm...@thaste.org>stefaan.luckerm...@thaste.org*
> 44KViewDownload
>
> PastedGraphic-2.tiff
> 125KViewDownload
Ike
- Concerns about Scala as a language choice for new development.
- Concerns about adding complexity and moving away from "Rails-like" simplicity for new users.
Sadache Aldrobi
#2 is a different story and one which I think the Play developers should consider very carefully. Developer productivity and ease of use are crucial values that should not be sacrificed. It is natural for project members to grow more sophisticated as their engagements expose them to more large and complex projects (I'm looking at you Spring Framework). But, ultimately, it is the 5 or 10 minute video demo that sells the framework to the masses.As long as developers are able to easily download the framework, create a new project with a single command and create a database-driven website with just a handful of files and easy-to-understand syntax, all with fast modify-deploy cycles then we should be OK.If we start seeing things like handle(_, _, _, _, _) as common method signatures then I think we'll be in trouble :)
--
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/-/mWn_1896EwsJ.
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ǝ
Erwan Loisant
On Thu, Sep 8, 2011 at 17:46, homerdoe <ozie...@gmail.com> wrote:
> What attracted me for Play was the folowing things:
>
> 1-Speed of reloading(Python scripts)
> 2-Java
> 3-JPA
1. The speed of reloading is not linked to the use of python. We used
Python because we didn't want to launch a JVM for each command; this
issue is fixed with the use of the sbt console: you can open a
console, run several commands and it will be in the same. Reloading of
Java code will NOT be slower. Compiling Scala code is slower than Java
code, but if you choose to code in Java it won't be a problem
2. Java will not be a second citizen. We understand nobody likes
Scala, and Java has its own advantages. Both languages will be equally
supported. What language is used to write the core doesn't matter,
it's just an implementation detail.
3. While Hibernate will not be included, we will include Ebean
(http://www.avaje.org/) which has an API very close to JPA: it uses a
lot of annotations from the javax.persistence.* namespace. It's
actually more in the spirit of Play because it natively support the
explicit save. In Play 1.0, we had to patch Hibernate to get this
behavior. Of course, if you really want to use Hibernate, nothing will
prevent you from importing it to your project.
> Although i like Scala, i just cannot understand how can someone make
> some big business apps without a proper IDE for it.
It's a matter of taste, but if you're an IDE guy you should check out
Typesafe's Scala plugin for Eclipse: http://www.scala-ide.org/
They're throwing a lot of ressources to the project, it's already
pretty good and we can expect it to get better in the future.
> Im sorry guys but play may be gone for me, just hope you reconsider
> those decisions.
You're free to use whatever framework you like, but I'm confident Play
2.0 will appeal to the same Java developers who liked Play 1, and not
just people interested in Scala.
--
Erwan Loisant
v6ak
> Although i like Scala, i just cannot understand how can someone make
> some big business apps without a proper IDE for it.
as Java support, it is good.
BTW: I'll probably do also something in Java (a Java project
contribution, I can't do it in Scala) and I probably will not go back
to Eclipse...
Brian Nesbitt
Ike
2. Java will not be a second citizen. We understand nobody likes
Scala, and Java has its own advantages. Both languages will be equally
supported. What language is used to write the core doesn't matter,
it's just an implementation detail.
Ike
That's one of the reasons for which we wanted to announce with a preview: To reassure users regarding our intentions. Download the preview and simply use the plain old "play new"
Guillaume Bort
> --
> 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/-/kEQVD7D-uzYJ.
homerdoe
play wont be as near as interesting as it is today for the average
java crowd(i dont consider myself one but hope to sell play to people
who are).
Regarding the python scripts, ive used grails and glassfish and think
that the reloading time could improve, so i have a natural fear of jvm
things that need to be fast.
I dont know scala that much, so i will be watching closely the
development of the new version, im sure the development team is aware
of those things and lets see what the future unfolds...
Pascal Voitot Dev
I prefer your version ;)
Steven Elliott Jr
Steven Elliott Jr
> I wouldn't say that "nobody likes Scala" :) I'm not surprised that not many are willing to learn a new language, but that's hardly and excuse for dismissing it.
I happen to love Scala but where I work it's hard to introduce a new language; I am waiting to make my pitch for a Scala app when 2.0 becomes an official release. In the meantime I have been diligently trying to port some Java apps over to Scala because I find it to be extremely powerful and showing people a working app is the best marketing tool. Despite the Scala resistance in my organization, the good news is that even though most engineers are not ready to switch to Scala, at least they are using the Play! Framework which is a pleasure to work in. So, it is definitely important to keep the Java support baked in for the old school peeps. Great job to all the devs that make Play! a reality!
Erem Boto
made but also the way they've chosen to present their choices to the
community. In fact, Play! is the best-run open source project I've
ever had the pleasure of working with.
I have two issues to bring up.
====
(1) How can we access the developer's mailing list, or an IRC channel
if it exists? I would like to contribute to the project by writing
scaladocs, but doing so will require asking the right people the right
questions and I don't want to flood the users' forum.
(2) I love Scala, but Scala library developers tend towards the
readability-destructive habit of creating punctuation-based DSLs for
each of their libraries. Not every library needs a DSL, and not every
DSL needs to use punctuation. If you ever consider putting operators
like '**', '<#', '<<?', '>>?', etc into the code base _please_
reconsider.
I wouldn't feel the need to bring it up, but Scala's semi-mindfuck
parser combinator syntax that unfortunately features prominently in
Anorm suffers from this syndrome and I would hate to see it spread
into other areas of the developer-facing APIs.
There's a pretty good conversation of it on Proggit. Odersky even
weighed in on the topic.
http://www.reddit.com/r/programming/comments/k5d4v/yes_virginia_scala_is_learnable/
====
Thanks for all the hard work, Playboys. You've made an amazing
product.
Erem
Ike
Thanks for all the hard work, Playboys. You've made an amazing
product.
Ivan Gallo
--
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/-/ZMaYCShefbsJ.
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.
Ivan Gallo P
SCJP
cel 3008165846
Ian Lawrence
> Play has
> become big, because it is essentially Django/Rails for the Java world.
+1
Exactly why we got into Play (along with the simplicity of the python
commands and the fact that we do not need to use an IDE to develop the
java projects we seem to inherit constantly).
My personal opinion is try to make 1.2.2/3 even simpler for non Java
developers to use and more Django/Rails like rather than move to
another programming language and build system. What advantages exactly
does this increased complexity bring to Play?
Regards
Ivan Meredith
doesn't automatically make it complex), but the apis for a framework
are the important thing. Play 1.x core is pretty complex too btw.
> --
> You received this message because you are subscribed to the Google Groups "play-framework" group.
Ivan Meredith
to learn scala. I'm sure Japid will be ported at the very least, so
you wont even have to learn how to do the scala templates (which are
very simple, much easier than learning scala)
Ivan Meredith
far out of the standard to create a platform that is awesome for end
user developers to use. Do you really think they want this to change?
In play 1.1 -> 1.2 its got easier to manage, with evolutions and
dependancies.
Obviously I personally like where this is going, however even if you
have doubts, I suggest looking at the sample app (yes this is a java
controller https://github.com/playframework/Play20/blob/master/samples/kiki/app/controllers/JavaApplication.java
), and then just wait awhile and see where it goes.
Hristo Deshev
(2) I love Scala, but Scala library developers tend towards the
readability-destructive habit of creating punctuation-based DSLs for
each of their libraries. Not every library needs a DSL, and not every
DSL needs to use punctuation. If you ever consider putting operators
like '**', '<#', '<<?', '>>?', etc into the code base _please_
reconsider.
Turar
using Play (just finished going through the tutorial and sample app).
Prior to that, I went through a process of choosing between Play,
other Java frameworks, Django, and Rails, and Play came out on top.
So now I'm a bit confused and would like some advice. Do I proceed
with Play 1.2.3 for this brand new project, and then hope to migrate
to 2.0 early next year, or just forget the whole idea, and go with,
say, Rails for this project, and re-evaluate Play once 2.0 release is
out and has traction? From what I understood so far, the current
recommendation is to not even bother with migrating from 1.x to 2.x,
and just keep developing in 1.x, as it still will be supported. Is
that right? While that makes sense, it's not the most exciting thing
if starting a new project today and knowing there's a whole new
direction already in the works.
Thanks!
Dirk
I'm excited to see what comes next..
felipeko
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.
Everson Alves da Silva
Rakesh Waghela
grandfatha
> we even got Unicode art!) DSL's people come up with. Casting another vote
> for "please don't go there."
For me, even some of the Anorm code is not really aesthetically
pleasing:
def prevNext = {
SQL("""...some..sql...."""
).on("date" -> postedAt).as(
opt('pos.is("prev")~>Post.on("")) ~
opt('pos.is("next")~>Post.on("")) ^^ flatten
)
} (taken from scala-module/samples-and-tests/yabe/app/models.scala)
This is not the API of a Rails/Django inspired framework IMO and I
dont want that to happen to the rest of Play, that is all I am saying.
T.J. Crowder
> For me, even some of the Anorm code is not really aesthetically
> pleasing:
>
> def prevNext = {
> SQL("""...some..sql...."""
> ).on("date" -> postedAt).as(
> opt('pos.is("prev")~>Post.on("")) ~
> opt('pos.is("next")~>Post.on("")) ^^ flatten
> )
>
> } (taken from scala-module/samples-and-tests/yabe/app/models.scala)
https://github.com/playframework/play-scala/blob/master/samples-and-tests/yabe/app/models.scala#L31-49
I realize I don't yet "speak" Scala, but PLEASE don't make Play's core
like that. Remotely. At. All. 20+ years of professional experience
_scream_ "maintenance nightmare" at me. (And I'm not just -- or even
primarily -- a Java-head, in my time I've done paid professional work
in 80x86 assembly, C, C++, VB/VB.Net/VBScript, Pascal, Java,
JavaScript, C#, and probably a dozen others.)
Again, I don't "speak" Scala yet -- but that's part of the point, and
that syntax is clearly a huge barrier to entry. There are hundreds of
thousands, if not millions, of people au fait with Java who can read
and understand and contribute to Play. There are currently very few au
fait with Scala, and if David Pollak is right[1][2] (even if he comes
off a bit elitist about it, particularly in [2]), there will continue
to be very few for many years to come.
Contrast the above with:
public Post previous() {
return Post.find("postedAt < ? order by postedAt desc",
postedAt).first();
}
public Post next() {
return Post.find("postedAt > ? order by postedAt asc",
postedAt).first();
}
From:
https://github.com/playframework/play/blob/master/samples-and-tests/yabe/app/models/Post.java#L50-56
[1] http://goodstuff.im/yes-virginia-scala-is-hard
[2] http://goodstuff.im/scala-use-is-less-good-than-java-use-for-at-l
--
T.J. Crowder
Independent Software Engineer
tj / crowder software / com
www / crowder software / com
Jonas
Thanks for this and Congratulations to a great framework.
I have used Play with both Java and mostly Scala for some months now.
I really like the framework.
The things that attracted me was:
+ Netty as server and the performance
+ Type safety of Java and Scala
+ Simplicity of MVC and Ruby on Rails like
+ Good tutorials and documentation
+ Support for WebSockets
After some experience with both Java and Scala:
+ I really liked the type safe and easy to use Scala templates
- I wanted to use WebSockets with the Scala module
- Anorm, I started to use it, it looked good, but it didn't have good
support for PostgreSQL
- Anorm, I need transactions for Order+multiple OrderItems, so I used
JDBC for this.
- This is minor problem, but it takes some time for a bigger Scala app
to compile.
- Not a play issue, but the Scala support in Eclipse wans't good. I
could change to IntelliJ, but it's a big step to switch many projects
to another IDE that I don't know yet.
Play 2:
+ It sounds like a dream with type safe routing
+ It sounds like a dream with Akka, I have used it in a Java project
and I have used Erlang before
+ Sounds like you are designing for WebSocket support for Scala,
great!
+ Better integration with Scala and keeping good support for Java
Thanks a lot for a great framework
Guillaume Bort
> commands and the fact that we do not need to use an IDE to develop the
> java projects we seem to inherit constantly).
If will not change in Play 2.0. You will use the same
new,run,start,test commands to manage your application. The fact that
we use SBT under the hood instead of python scripts will not change
anything on the final UI.
And like in Play 1.x you will be able to work without IDE. Play will
just recompile and reload any change when you hit reload.
> --
> 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
https://gist.github.com/1203802
Really no one can say that a Java developer will be lost reading or
writing this stuff.
--
Guillaume Bort, http://guillaume.bort.fr
Pascal Voitot Dev
2.0 will arrive progressively and you will be able to prepare your migration in the same way...
The only doubt I would have is against the Groovy templating which won't be kept in 2.0.
So I would advise going directly to Scala template or Scalate or Japid or Cambridge.
Regards
Pascal
Rakesh Waghela
ogregras
T.J. Crowder
> Here is a type safe template as seen by a Java developer:
>
> https://gist.github.com/1203802
>
> Really no one can say that a Java developer will be lost reading or
> writing this stuff.
relate to the _framework code_ and whether people can readily
understand and contribute to it (and samples, etc.). I don't see any
issue with the _templates_ you're citing, regardless of one's
linguistic leanings. You have to learn any templating system, that one
looks just as comprehensible as any other. Not so much that code from
the Scala yabe sample quoted by grandfatha (yikes!), and the "ASCII
art DSL" concerns raised by Hristo Deshev. I would hate to see Play's
framework code look like that.
grandfatha
Guillaume Bort wrote:
> Here is a type safe template as seen by a Java developer:
>
> https://gist.github.com/1203802
>
> Really no one can say that a Java developer will be lost reading or
> writing this stuff.
regarding your hard work and effort. It is just that some of the Scala
code out there (even part of anorm) can be a real threat to the
popularity of the framework. And I would hate to see such a
masterpiece go down in flames because of stupid things like e.g. the
overuse of symbolism within the scala world.
Sadache Aldrobi
--
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ǝ
Pascal Voitot Dev
Scala has a powerful syntax... but as all the powerful things, if you aren't reasonable and self-disciplined, you can become incomprehensible... But I know coders who write weird Java also :)
Ike
Erem Boto
library is a scala standard lib, therefore all Scala developers will/
should be familiar with its syntax." But I hope the continued
controversy around Anorm's syntax has communicated to you that this
assumption may not be sound or reasonable.
For example (and I think I'm typical here). Only in researching how to
use Anorm did I discover _what_ a Parser Combinator is, which took me
down a deep hole learning about parsers, parser-generators and context-
free grammars. When I was feeling more comfortable, I searched for the
Parser Combinator scaladoc and found a perfect example of an
inscrutable API. For example, look at the three adjacent methods ^?,
^^, and ^^^. Or the methods ~ and ~!, none of which at their face give
any contextual information about the method's purpose. That lack of
contextual information in the method name butchers readability and
makes any code that uses the library heavily look frustrating and
undecipherable. Which is why the Anorm code stands in jarring contrast
to the rest of the Play! APIs and docs which are dead-simple for
anybody familiar with the relevant domains (HTTP, HTML, SQL, etc).
At any rate, I'm not complaining about the learning process; it was
all useful knowledge. But should this level of research really be
necessary just to understand the options for extracting data from a
result set? I think most of us Play! developers would argue otherwise.
To reiterate and bring this back to the topic, I love the move to
Scala but would hate to see more Play! APIs seduced into employing
punctuation operators and thereby murdering readability.
Erem
On Sep 9, 5:43 am, Sadache Aldrobi <sadek.dr...@gmail.com> wrote:
> Just to clarify here, Anorm did NOT invent a syntax, a DSL or operators. It
> implements standard Scala Parsers Combinators and it is targeted for Scala
Sadache Aldrobi
> Just to clarify here, Anorm did NOT invent a syntax, a DSL or operators. It implements standard Scala Parsers Combinators
Granted, and I understand your rationale: "The Parser Combinator
library is a scala standard lib, therefore all Scala developers will/
should be familiar with its syntax." But I hope the continued
controversy around Anorm's syntax has communicated to you that this
assumption may not be sound or reasonable.
To reiterate and bring this back to the topic, I love the move to
Scala but would hate to see more Play! APIs seduced into employing
punctuation operators and thereby murdering readability.
punctuation operators and thereby murdering readability.
www.sadekdrobi.com
ʎdoɹʇuǝ
Erem Boto
frustration and way too harsh.
I also do not wish to deride what you've done with Anorm, because
after doing the homework I described in my previous post I can
definitely appreciate the library's versatility.
Point is that change is both awesome and scary, and I'd love to see
Play! come out of this great change as the undisputed king of JVM web
frameworks, if it isn't there already =)
Erem
Sadache Aldrobi
>> I wouldn't call it "murdering readability" anyway.
>
> Apologies! Looking back on it, that wording was chosen out of
> frustration and way too harsh.
>
> I also do not wish to deride what you've done with Anorm, because
> after doing the homework I described in my previous post I can
> definitely appreciate the library's versatility.
>
No problem.
> Point is that change is both awesome and scary, and I'd love to see
> Play! come out of this great change as the undisputed king of JVM web
> frameworks, if it isn't there already =)
Perfect )
jh
E.g. which operations are done in compile-time and which are still
evaluated runtime (using reflection or something else)?
Templates
1.x runtime parsed
2.0 compiled
Routing
1.x runtime parsed?
2.0 compiled?
Parameter binding and checking for controllers
1.x reflection?
2.0 ?
Any other items worth mentioning?
Thanks in advance.
Mike Row
Guillaume Bort
the parameters binding will be compiled as well.
> --
> 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
Piero Sartini
Ivan Meredith
Sure the api will change a bit, but then you get that with most web
frameworks when they upgrade between major versions.
I personally use play-scala. I don't really care if the core is in
java or scala, it makes no difference to me as an end user. But I
imagine scala makes it easier to write the core of play.
At the end of the day I love play 1.x (even when I use it with java),
and I trust the Zenexity guys will continue on in play 2.x what makes
play 1.x so great to use.
> --
> 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/-/QDqBXmszgS4J.
冉兵
Ivan Meredith
that case anyway though.
冉兵
Nicolas Leroux
Nicolas
2011/9/30 冉兵 <bing...@gmail.com>:
--
Nicolas Leroux
T.J. Crowder
> But I imagine scala makes it easier to write the core of play.
information. So let me ask Guillaume and team: *Why* is switching to
Scala for the core so compelling? What about Scala makes it so much
better for writing the core -- indeed, throwing away working code and
REwriting it -- than Java?
Play moving away from Java makes me much less interested in using it.
A framework where Java is a second-class citizen, as Piero put it,
doesn't appeal to me when I'd be doing my stuff in Java. And as I've
said before, not being able to read the core code (because I don't
know Scala and don't have the time to dedicate to learning it right
now, too much on my plate) seriously dents my interest in the
platform.
Have you heard of the "version 2 anti-pattern"? That's where a product
team kills a product because having worked on version 1 for a while,
they feel they really need to rewrite the product for version 2. In
doing so, they lose important market position (rewriting what they
have rather than adding things they don't) and change things that piss
off existing customers. Now, Play! is not a product, per se, and the
people using it not customers, per se (except of course for
playapps.net), but...
FWIW,
--
T.J. Crowder
Independent Software Engineer
tj / crowder software / com
www / crowder software / com
Daniel Guryca
Well I am in a bit similar position. I have deployed many Play apps.
But yeeh only 2 just serious (eshop + CRM) ones. Anyway I have
initializated a move from Play to a Python land.
Reasons are 3:
1. Python is more lightweight - memory + lines of code + for unix
admin system tasks it is totally superior - so it better suits my
needs for very small projects.
2. Play is shifting to version 2 which is going to be a total rewrite.
3. I am not willing to learn Scala (atleast not till it reaches Next
Big Language tag)
Piero concerns would be also my concerns if I would be in a position
of starting a new project with another java programmers I would be ...
well ... a bit lost.
I see that Scala is nice language but for me it has a horrible
unreadable syntax (Perl like) + in my opinion it's so powereful that
it's overcomplicated.
But Anyway these are just my needs so I believe that many other guys
will be very happy about this Scala shift ... so do not take my words
so seriously. Different people have different tastes.
Thanks for your very nice and hard work on Play!
Daniel
> --
> You received this message because you are subscribed to the Google Groups "play-framework" group.
Ivan Meredith
is no technical reason why Java has to be a 2nd class citizen. It all
depends on the developers. And I haven't seen anything from them
As a module maintainer I find the python system hard to work with. I
have do deal with all args twice because I have to pass them into a
java class. Also If you write your own modules, you can't keep them in
a private maven repository because deps management doesn't support
basic auth. I'm not saying SBT automatically makes things better, but
it potentially frees up time that the devs have to spend maintaining
the python build system.
I guess we just need to wait and see how it is. Play 1.x could be
forked by somebody if really needed. But I have faith :)
Guillaume Bort
There is no reason thinking that Java will become a 2nd class citizen
(unless of course FUD).
Typically we are currently working faster on the Java API than on the
Scala one. Here is for example a typical CRUD controller in Play 2.0
written in Java and using Ebean models:
https://gist.github.com/1238475
--
Guillaume Bort, http://guillaume.bort.fr
Martin Grigorov
On Fri, Sep 30, 2011 at 11:14 AM, Guillaume Bort
<guillau...@gmail.com> wrote:
> Hi,
>
> There is no reason thinking that Java will become a 2nd class citizen
> (unless of course FUD).
>
> Typically we are currently working faster on the Java API than on the
> Scala one. Here is for example a typical CRUD controller in Play 2.0
> written in Java and using Ebean models:
>
> https://gist.github.com/1238475
I'm not Martin Oderski but I can see that template editForm.scala.html
wont compile because of :
@helper.html.form(action = routes.Tasks.dekete(id)) {
;-)
Otherwise - good job! I like it.
Guillaume Bort
> wont compile because of :
> @helper.html.form(action = routes.Tasks.dekete(id)) {
> ;-)
Why that?
Martin Grigorov
<guillau...@gmail.com> wrote:
>> I'm not Martin Oderski but I can see that template editForm.scala.html
>> wont compile because of :
>> @helper.html.form(action = routes.Tasks.dekete(id)) {
>> ;-)
>
> Why that?
don't tell me that Scala compiler doesn't catch it
Guillaume Bort
On Fri, Sep 30, 2011 at 11:30 AM, Guillaume Bort
Guillaume Bort
Of course it catch it. My fault I hacked the code directly into the
Gist interface.
On Fri, Sep 30, 2011 at 11:39 AM, Martin Grigorov
T.J. Crowder
> Hi,
>
> There is no reason thinking that Java will become a 2nd class citizen
> (unless of course FUD).
genuine anxiety from people using Play and people like myself
evaluating it.
I also haven't seen any actual reason for switching the base to Scala.
I assume there must be one, the Play developers are clearly very
smart, informed people, I just haven't seen it explained.
Nor have I seen any response to the concern that rewriting the base in
Scala makes the *base* unreadable to people who know Java and don't
know Scala (a HUGE number of people). Every time I raise this, another
example of *using* the framework in Java is posted, which is of course
completely irrelevant to my concern.
Guillaume Bort
> I assume there must be one, the Play developers are clearly very
> smart, informed people, I just haven't seen it explained.
Well, basically writing the core in scala just make it easier and more robust.
For example here is a small Scala code snippet from the DB plugin that
read the configuration file to init every found data source, and the
way we would have to write it in Java:
https://gist.github.com/1253368
Not only the Java version is longer and more tedious to write, but it
is also way more error prone, all the null cases must be properly
handled by the developer and are not checked at all by the compiler.
Also we need to manage synchronized block explicitly (and Java purists
will probably notice that the synchronization stuff is not perfect and
can lead to duplicate datasource connection problems in some race
conditions). And the resulting API is error prone as well, since
everywhere else in the code you have to remember to use getDbs()
instead of direct access to dbs, even if it would just properly
compile and fail under some conditions. The result is far from perfect
as well because all this stuff stay completely mutable and some
external code (for example a plugin) would be able to modify the
internal state of the DBPlugin leading to strange errors difficult to
understand.
Basically Scala allow us to write less code, more robust since it is
completely checked by the compiler and completely null free, and fully
thread safe (that is the most important in an async web framework).
This is just a small example. There are some parts like parsing and
compiling routes,configuration and template file is a nightmare to do
in Java (using home made parser and regex stuff). Typically Play 2.0
is currently very good at reporting errors as everything is properly
parser into a valid AST making it possible to properly report errors.
And of course all the internal async handling is way easier to write
in Scala using the Actors paradigm.
But all Java specific API like the Ebean plugin, the Java databinding,
etc. are still written in Java.
Even if we had written the code async stuff, or the parsers/compilers
in Java, knowing the Java language would not be enough to be able to
understand it. You would have to understand very low level async or
parsing Java code, way more complicated to undersand than simpler high
level code written in Scala.
Ivan San José García
T.J. Crowder
On Sep 30, 11:45 am, Guillaume Bort <guillaume.b...@gmail.com> wrote:
> > I also haven't seen any actual reason for switching the base to Scala.
> > I assume there must be one, the Play developers are clearly very
> > smart, informed people, I just haven't seen it explained.
>
> Well, basically writing the core in scala just make it easier and more robust.
>
> For example here is a small Scala code snippet from the DB plugin that
> read the configuration file to init every found data source, and the
> way we would have to write it in Java:
>
> https://gist.github.com/1253368
particularly complex or error-prone to me. I can't, of course, comment
on the Scala or whether apples are being compared to apples here, that
would require someone familiar with both languages.
> ...and Java purists
> can lead to duplicate datasource connection problems in some race
So you synchronize correctly. Sorry, that's just a non-argument.
"There are bugs in my Java code so I need to write Scala instead"
makes no sense and feels like FUD to me.
> Basically Scala allow us to write less code, more robust since it is
Huh? There will only be nulls in your Maps if you put nulls in your
Maps. Java doesn't just magically throw nulls into your data
structures willy-nilly.
> This is just a small example. There are some parts like parsing and
> compiling routes,configuration and template file is a nightmare to do
> in Java (using home made parser and regex stuff).
without Scala knowledge, I can't be on even footing. Literally
thousands of projects use Java to parse thousands of data formats
without apparent trouble. JSoup uses Java to parse HTML, which is
known to be a real PITA. I've done templating in Java and not felt it
was particularly difficult or awkward. And of course, that template
parsing is encapsulated in a class so code using it doesn't have to
worry about the details.
> And of course all the internal async handling is way easier to write
> in Scala using the Actors paradigm.
> Even if we had written the code async stuff, or the parsers/compilers
> in Java, knowing the Java language would not be enough to be able to
> understand it. You would have to understand very low level async or
> parsing Java code, way more complicated to undersand than simpler high
> level code written in Scala.
suspect, though. It sounds like to understand Scala you have to
understand the async stuff if it's embedded in the language, so it
sounds like a net zero comparison.
Thanks again for the example. At the end of the day, it comes down to
the Play team believing that using Scala is a net gain, despite the
relative paucity of resources that can contribute or understand it,
what with Scala resources being multiple orders of magnitude less
common that Java ones -- now and for the foreseeable future. That's
your call to make, naturally. I hope you're right about it, and wish
you the best for Play 2.
Guillaume Bort
patterns that solve the double check locking problems:
http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html
So yes it is possible to handle proper synchronization in Java but you
have to remember all these patterns and their issues. It is way
simpler to let a compiler manage it properly using the Scala natively
supported singleton objects and lazy val.
2011/9/30 Ivan San José García <iva...@gmail.com>:
Guillaume Bort
> "There are bugs in my Java code so I need to write Scala instead"
> makes no sense and feels like FUD to me.
Of course you can but why bother with that if higher level concepts
like singleton objects and lazy val manage it properly for you?
It is the same kind of arguments you can apply to Java. You can choose
to write a program in Java instead of C because you don't have to
bother with pointer management and use an higher concept of reference
and garbage collection instead. Of course a C developer could argue
that if you manage your pointers properly it is not an issue, but you
have to admit that it is just simpler and more robust to let a
compiler manage this aspect.
> Huh? There will only be nulls in your Maps if you put nulls in your
> Maps. Java doesn't just magically throw nulls into your data
> structures willy-nilly.
Yes but you have to deal with null anyway in Java. Look at the sample
Java code, there many places where I can't avoid them, and have them
to manage them properly.
> We'll just have to agree to disagree here, and I recognize that
> without Scala knowledge, I can't be on even footing. Literally
> thousands of projects use Java to parse thousands of data formats
> without apparent trouble. JSoup uses Java to parse HTML, which is
> known to be a real PITA. I've done templating in Java and not felt it
> was particularly difficult or awkward. And of course, that template
> parsing is encapsulated in a class so code using it doesn't have to
> worry about the details.
Again I don't say that it is not possible to write a parser or a
compiler in Java. It's just more complicated because you have to
handle lower level code, instead of focusing on declaring your
grammar.
> How or why? Java is very good for writing asynchronous stuff.
Because again managing synchronization between thread sharing some
memory state, is lower level and more error prone than using the Actor
model (Shared Nothing, based on Message Passing).
http://java.dzone.com/articles/scala-threadless-concurrent
Morten Kjetland
Guillaume Bort
Not exactly since you don't have any immutable Java structure in Java.
For example declaring a:
final Map<String,String> internalData;
will avoid to assign a new reference to internalData but will never
avoid to change the internal state of the Map.
T.J. Crowder
> There are several patterns including double check locking and more
> patterns that solve the double check locking problems:
>
> http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html
code snippet. It's been proven to be more overhead than it's worth
(now that it works at all). Just simple synchronization is fine, the
JVM is really good at it. Your example fails because you're trying to
synchronize on a null, but it's trivial to fix in a clear, easily-
understood way. Whether you write in Scala or Java, you use the
language's mechanisms of exposing the JVM's synchronization features.
Java's are not complex.
-- T.J.
Morten Kjetland
> You can also create immutable java objects using final.Not exactly since you don't have any immutable Java structure in Java.
For example declaring a:
final Map<String,String> internalData;
will avoid to assign a new reference to internalData but will never
avoid to change the internal state of the Map.
Martin Grigorov
<guillau...@gmail.com> wrote:
>> You can also create immutable java objects using final.
>
> Not exactly since you don't have any immutable Java structure in Java.
> For example declaring a:
>
> final Map<String,String> internalData;
>
> will avoid to assign a new reference to internalData but will never
> avoid to change the internal state of the Map.
The j.u. collections are mutable but there are third party libraries
which provide immutable collections
Martin Grigorov
<martin....@gmail.com> wrote:
> On Fri, Sep 30, 2011 at 1:41 PM, Guillaume Bort
> <guillau...@gmail.com> wrote:
>>> You can also create immutable java objects using final.
>>
>> Not exactly since you don't have any immutable Java structure in Java.
>> For example declaring a:
>>
>> final Map<String,String> internalData;
>>
>> will avoid to assign a new reference to internalData but will never
>> avoid to change the internal state of the Map.
>
> The j.u. collections are mutable but there are third party libraries
> which provide immutable collections
http://download.oracle.com/javase/1.5.0/docs/api/java/util/Collections.html?is-external=true#unmodifiableMap(java.util.Map)
but yeah, it is much better to use a collection which is designed for that.
Sadache Aldrobi
--
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.
Sadache Aldrobi
ʎdoɹʇuǝ
T.J. Crowder
On Sep 30, 12:38 pm, Guillaume Bort <guillaume.b...@gmail.com> wrote:
> > So you synchronize correctly. Sorry, that's just a non-argument.
> > "There are bugs in my Java code so I need to write Scala instead"
> > makes no sense and feels like FUD to me.
>
> Of course you can but why bother with that if higher level concepts
> like singleton objects and lazy val manage it properly for you?
> > Huh? There will only be nulls in your Maps if you put nulls in your
> > Maps. Java doesn't just magically throw nulls into your data
> > structures willy-nilly.
>
> Yes but you have to deal with null anyway in Java.
your maps, and you don't put nulls in them, they WILL NOT have nulls
in them. No need for any null checks in your code.
But this is not about the fine points of doing things in one language
or another. You presented using Scala rather than Java for the core as
though it were all advantages and no disadvantages. The feedback you
should be hearing from many of us in this thread is: There are also
major DISadvantages to using Scala, one of them (for me, the primary
one) being that there are orders of magnitude fewer skilled Scala
programmers than skilled Java programmers and that will be true for
several years at the very least. That means orders of magnitude fewer
people available to help contribute to the core, orders of magnitude
fewer people who can figure out issues in the field, etc.
But again: Obviously, the pros vs. cons decision is for you and your
team, not for me or the others raising concerns in this thread. I'm
not saying "you should use Java," I'm saying that there are factors
beyond built-in singletons and such to consider, which don't appear to
have been given consideration. There are resourcing and business
factors. A Java shop is just plain going to be a LOT less interested
in a framework built on Scala, even if it has a good Java API. That's
just a fact of life. Some shops won't care, of course, but some will.
Java developers are less likely to want to use it, for the same
reason. And some won't care as long as they don't have to deal with
Scala directly.
Having made that point, I don't think I have anything else useful to
add and it's not my desire to argue or make trouble. It is your
decision, and if you feel the pros outweigh the cons, great, I hope
it's the right decision for the framework and wish you the best with
it.
Martin Grigorov
> Yes you could you could, but then it is not Java, Java is an imperative
> mutable programming language. You start immutable and Java will be in your
> face all around blocking you from taking advantage of immutable data
> structure.
I wont argue here :-)
I can say that if I need to update the Nth element in my mutable list
it will much faster than any technic you know (including functional
persistent data structures) with an immutable list. But I see your
point. You can always fallback to mutable ArrayBuffer if the use case
requires it.
T.J. Crowder
> T.J. Crowder,
>
> I am sorry man but it seems that you don't want to get it no matter how good
> we explain it. Just you don't want to get it. The time you pass arguing you
> could learn few mechanisms in Scala that would help you finding it really
> useful.
>
> Sadek
Reasonable, mature people can disagree.
-- T.J.
Julien Tournay
-- T.J.
--
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.
Real Programmers don't need comments-- the code is obvious.
T.J. Crowder
Thanks. I understand what you're saying (though I disagree with some
specifics; that doesn't matter), and I understand that some things are
easier in Scala than in Java, just as some things are easier in
JavaScript than in Java, and some things are easier in Java than in C,
etc. Languages are like that. That's fine. My central point is that
there are non-technical issues to consider, alongside the technical
ones, and it was far from clear that those non-technical issues had
been considered. Having raised the point, I hope clearly, pushing the
issue further would be disrespectful to the team, which has never been
my intention.
-- T.J.
Sadache Aldrobi
-- T.J.
--
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ǝ
T.J. Crowder
On Sep 30, 1:55 pm, Sadache Aldrobi <sadek.dr...@gmail.com> wrote:
> I didn't intend any misrespect. Just you can not reach someone who is not
> willing to understand. You asked why scala, we explained, you tell you can
> possibly do it with Java, end of argument.
primarily technical. Though I do strongly disagree with a couple of
Guillaume's specific claims, I'm sure others are perfectly valid and I
appreciate his having outlined them. That's not my main point, though,
as I think a thorough read of my messages will make clear.
-- T.J.
grandfatha
tooling..... I am still not 100% optimistic about the changes in 2.0,
but only time will tell. Maybe the Scala revolution will start just
like Ruby became popular only after Rails was released. Who knows? It
all reminds me of a Steve Jobs quote about him being fired from Apple
back in the day:
"It was awful tasting medicine, but I guess the patient needed it."
Aaron Freeman
little over a year now I've been a big fan of Play! and have
evangelized a lot and have friends at several other companies using it
now. Since I first found Play! and read the authors' reasoning for
breaking from JEE, I totally agreed. Having done quite a bit of JEE, I
know what pain it is, and Play! was so refreshing by being willing to
do what worked best rather than simply follow the pattern of how Java
is usually done. The Java community suffers horribly from the fact
that most frameworks and libraries are overly complex and make even
simple things a pain. JEE being a great example of that. Play! showed
that it doesn't have to be this way, even in Java. Which was great!
At the company I'm with now we use several languages, and Java is just
one of them. So Scala is fine with us. We'll continue to use Play! and
probably start doing more Scala in the future. But for a lot of people
Java is the "official" language of the company. Several of my friends
at other companies that I've gotten to use Play! are in that
situation.
The bottom line is that Play! was awesome because it was the best Java
web framework I've ever worked with. And it won't be that any more. It
will be a great Scala web framework that supports Java. And that
difference will have a big impact, especially on all those "Java"
shops.
Like T.J. said, it's the maintainers decision, and it's totally fine
for them to do what seems best. I just think Play! was a shining
example of how things could be done in Java, and how you don't have to
do things the same old Java way. And losing that example is kind of
sad for the Java community.
Julien Richard-Foy
> web framework I've ever worked with. And it won't be that any more.
I’m not sure of that. I think the Play 2 Java API will be even nicer
than the Play 1 Java API. Just jook at the gists posted by Guillaume
:)
antman
The Play developers keep brandishing *technical* arguments to support
their decision to rewrite the core of the framework in Scala. I (and
others) understand that Scala provides higher-level constructs that
are of benefit in many scenarios the were trying to solve.
However, the problem with narrowly focusing on technical arguments
when taking a decision on the future direction of a product is that
other less-tangible factors get ignored. Oftentimes, these factors are
very important, and smart geeks, who always like to play with the
latest shiny toy, ignore them to their detriment.
For example, Paul Graham has several articles outlining the
superiority of Lisp over other languages. Being a Lispnick myself, I
agree with him. Yet despite its vaunted superiority, how many projects
are using Lisp? And how many projects are using Java? Right.
As TJ attempted to argue, the key sell of Play for many developers was
that it was a *Java* web framework for Java programmers. This made it
easier to sell its use to the vast number of Java shops out there
(including my employer), and I believe it was a key (if not *the* key)
reason for Play's skyrocketing popularity. It made Play familiar,
approachable, and non-scary. And I for one, have found myself delving
into the code several times to figure out some things I could not
gather from the documentation, or a web search. With the code written
in Scala, that will no longer be possible for a large proportion, if
not the majority, of Play users, including myself. This makes Play 2
unfamiliar, unapproachable and scary. In my case, rather than moving
to Play 2, we may end up using Grails for future projects.
To dimiss these concerns with the suggestion to "just learn Scala" is
very misguided, in my point of view. Many of us simply don't have the
time to learn a complex language like Scala to the extent necessary to
be able to read and understand Play 2's Scala code. Nor the motivation
- Scala will always be a niche language, for the reasons outlined here
by David Pollack (http://goodstuff.im/yes-virginia-scala-is-hard), the
creator of the Lift web framework, and one of the gurus of the Scala
world. Scala's complexity has already spawned two new languages:
Ceylon and Kotlin, by teams at Red Hat and JetBrains who evaluated
Scala and found it wanting.
descsuit
or categorically if one language is better than another.. But I know
that now that I've been using Scala writing anything in Java is
painful at best. Unfortunately, some of that pain involves interfaces
and extensions to classes, which means when you have provide an API
for both languages you lose a lot of the flexibility Scala.
Sadache Aldrobi
--
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.
T.J. Crowder
> Some people here on this very thread chose to be constructive and optimist,
> some chose to fight change by all means.
respectfully disagree with one another, and in mature discussion
there's room for multiple viewpoints and perspectives. Statements like
the above are at best zero-sum, and at worst inflammatory and
disrespectful.
-- T.J.
Drew Hamlett
terrible. If the Netbeans, Eclipse and IntelliJ plugin were combined
then we would possibly have a usable IDE.
T.J. Crowder
> We are talking past each other in this thread.
point (and probably passed it) where further discussion is a waste of
time. (Not a dig at you, antman -- your points are cogent and clearly
made.) But FWIW, I think at this stage one has to step back and
respect the decision that Guillaume and team have made/will make.
That's what I'm doing. They're on the front line. They live and
breathe this every day. They've heard the feedback about the business
and community negatives by now. They're also aware -- more aware than
nearly any of us -- of the technical benefits, although we might argue
various points here and there. It's their scale to balance, their
direction to decide. If they continue their current direction, it's
because they believe that the benefits outweigh the negatives, not
because they are unaware of or disregarding those negatives. That's
the best anyone can do: Make the best decision they can with the
information at hand.
Unless someone has a _new_ point to make, I suggest that further
discussion is just second-guessing, and we should show the team more
respect than that.
Just my take.
Jorge Aliss
antman
because they perceive it as a negative.
Personally, I spent a good amount of capital to introduce Play into
our workplace. That it was a Java web framework, written in Java, was
the big selling point, as we are a Java shop.
TJ, I'm sorry, but I disagree with you. The reason I decided to post
to this already lengthy thread was because, in my opinion, it is
important that the Play team hears from their users, as many times as
possible, about the concerns that this change as aroused.
Your assertion that it is somehow disrespectful to the team to voice
an opinion about the direction they have taken does not make much
sense to me. I don't intend to insult nor disrespect anybody, and I
believe that the Play developers are mature adults that can receive
criticism without becoming insulted or feeling disrespected. I have
the greatest respect for them and their work, otherwise I would not be
using their product.
Smart engineers always listen to their users, and perhaps if enough
users voice dissatisfaction with this new direction, some changes will
be made to accommodate these concerns.
Ivan Gallo
Ivan Gallo P
SCJP
cel 3008165846
T.J. Crowder
[snip]
> an opinion about the direction they have taken does not make much
> sense to me.
but that's how it reads. I'll say again your points were cogent and
clearly-made (and made politely). I guess what I'm saying is that once
someone has made their point / voiced their opinion, getting into a
back-and-forth on it for any length of time isn't useful. Or something
like that. :-)
Joseph Burns
more Scala for a while, now I can have the best of both Java and Scala
in a web framework. The speed and technical benefits you have
described as new side effects are encouraging, I am looking forward to
embracing the new platform.
On Sep 7, 5:39 am, Guillaume Bort <guillaume.b...@gmail.com> wrote:
> 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 ...
>
> read more »
antman
nothing else to contribute to this discussion, so I'll give way to
others to voice their opinions (whether pro or con) instead.
And for the record, Play is an awesome framework, my kudos to the
team.
Miuler
GrailsDeveloper
the more of scala. I'm personally stopped at the moment my advertising
for play. With play 1.x I think we have the following situation:
+ a really great framework, with brilliant ideas from Guillaume and
his team
on the other side there was some issues:
- a lot of things have a leak of documentation. Comments in code a
really rare.
- many small bugs and issues.
Both things wasn't a problem in play 1.x because
- you can easily read and understand the code
- you can easily fix an issue and build your own play-version.
for the last thing it is essential that the framework code is java.
However if the code quality becomes better and perhaps with more unit-
test-coverage the second issues doesn't matter. If the documentation
will become better the first issue isn't a problem any more. So I hope
that the team will have this in mind.
Last but not least I'm scared about the memory consumption. To compile
scala you need a lot of memory and it seems to be easy to create
memory leaks with scala. So I hope that this wouldn't be a problem at
all.
How ever it's the decision of the core-team and I'm glad that they
want to support play1.x in the future.
Niels
Piero Sartini
project. The decision was made before the announcement of Play 2.0.
Now I've read somewhere about Play1.0 maintenance for at least 8
months.. this is not nearly enough for a project that is just started.
Even if maintenance is given for a longer period, it does not make
sense to use a framework that will not evolve.
Switching to 2.0 afterwards seems to be complicated as there is no
compatibility. Not in the templates, not in the controllers and not in
the model. Knowing a rewrite will be needed does not make us very
eager to bet on this horse. Using 2.0 from the beginning is not
possible because its not ready. Also there is the scala thing that
scares us, like explained earlier.
I guess there are other people with this problem as well. As it stands
now, there is no way to start or continue a new project with Play. At
least not if you need to explain that decision.
Engin Tekin
however if it will take years to complete the project
play 1.2.3 is still the best option but you might prefer to migrate to
newer versions later on
Ivan Meredith
> scala you need a lot of memory and it seems to be easy to create
> memory leaks with scala. So I hope that this wouldn't be a problem at
> all.
>
This probably won't be an issue if your using Java, since it won't be
invoking the scala compiler. if you are using scala templates it could
be an issue, although the compiling issues that ive seen seem to focus
around the stack which is only a very small bit of memory anyway (<
1M). The only other time this will be an issue is if you compile the
core itself, which you probably wont be doing a lot.
Personally I've been using and compiling scala for a year now. I have
never had an issue with memory until I managed to find a bug/feature
of the scala templates. This should be fixed when/if the grammar is re
done for the templates.
As for memory leaks, in general I would say its about the same as
Java. If you don't destroy the reference from stack to heap, it
persists and you potentially have a "leak". If anything I think an FP
style of coding probably limits this more than OO since you have more
"function" scoped data. (I could be wrong on FP vs OO memory usage, I
haven't really thought about it until today).
Btw I totally agree about docs and tests. Java/scala docs on "hard to
understand if you dont know scala" functions could go a long way to
helping people grep the code. I still scratch my head over some of the
parser combinator api and scala type system.
>
> On 1 Okt., 16:48, Miuler <miu...@gmail.com> wrote:
>> +1 SCALA
>>
>> For my scala is one of the main reasons why playframework appeared on my
>> list.
>> Scala playframework echo to appear on the map.
>
TAN Yee Fan
I am one of those developers who never post on this mailing list (except
to push the developers to fix a certain bug, but my pull request has
been ignored so far). In any case, I would like to add my weight towards
the voices of dissent over the direction and handling of Play 2.0.
I have no new arguments from what has already stated, but to state my
concerns:
1. The is no backwards compatibility for running Play 1.x projects,
preventing us from migrating to Play 2.0. Among the points I am making,
this is the most important one.
2. Supporting Play 1.x for only "at least 8 months more" doesn't
reassure me at all. Our projects, including the necessary support, are
typically measured in years.
3. The Play 2.0 announcement signals that no major improvements will
come to Play 1.x, and that Play 1.x will be retired some point in the
near future.
4. Being relatively new, Play lacks documentation either with the Play
website/application or elsewhere on the Internet. The Javadocs looks
woefully incomplete in certain areas. This forces people to look into
the source code. Converting to Scala strongly dilutes this ability to
understand the source code for most of the developers out there.
5. Point 4 above also implies that modifying Play to our own
requirements becomes more difficult.
The announcement of Play 2.0 makes me think that it was a mistake for us
to investigate and start projects in Play at the first place. If this is
what you are going to do in Play 2.0, do you think I will have the
confidence that if I develop using Play 2.0, then I can continue my
project when Play 3.0 comes out? It is sad because Play 1.x had so much
potential, and I would like to see it evolving into a more mature
platform with the large number of small wrinkles smoothed out. I hope I
am proven wrong, but so far I am unconvinced.
Regards,
Yee Fan
Alison Winters
I've already stated my opinion earlier so I won't comment too much on
that, aside from saying that I share the anxiety of moving the core to
Scala. I understand it has many technical advantages over Java, but I
don't think it has the widespread support to make it one of the
preeminent languages any time in the near future. Big Java shops will
be wary of investing in Scala development for quite some time, and
speaking as a freelance/contracting web developer even I am wary of
building sites with a framework where I can't understand the
underlying code base. I have neither the time nor desire to learn a
new language, and probably won't until it's popular enough that I have
to.
All that aside, what is also worrying are the changes to the Java API
for 2.0. I hope that the models and the templates will not be too big
of a deal - no doubt there will be a JPA/Hibernate plugin for the
model and a Groovy plugin for the templates - but what about the jobs,
controllers, util classes, F library etc? I look at the new code
examples and I am completely lost as to what's happening. It's not
that the code is complicated, it's just that it is quite different to
the way things worked in Play 1.x. No one is going to want to rewrite
their entire app with new imports, new method calls etc just to
upgrade. But even if you are only targeting 2.0 for new apps then how
is changing the whole API going to be appealing to existing
developers? If everything works differently then there is no reason
for people to stick with Play - a brand new learning curve for 2.0
gives them another opportunity to learn something else.
An example:
return ok(editForm.render(id, form(Task.find.byId(id))));
This looks like LISP! Personally I can deal with this kind of
programming because I use LambdaJ and I like vaguely fluent
interfaces, but this isn't always popular in the Java community. The
old format would presumably be:
Task task = Task.findById(id);
render(task);
What do I want to find? A task. How do I want to find it? By id. What
do I want to do with it? Render it. This is a lot more straightforward
than talking about an editForm (what is that?) and forcing an ok()
wrapper around 99.99% of return statements.
Someone else recently posted to the list about the binding difference
on save() where you can no longer auto-bind as arguments to your
method and instead must explicitly bind on the first line into a
Form<T>. Looks like Struts! I'm sure there is a good technical reason
for this, and if I was seeing it for the first time in any other
framework I'd just accept it, but because I know how Play 1.x did it,
and I know how nice/easy that was, it just seems like more work to me.
I love Play and I have been using it for 18+ months, and I'll probably
learn the new API eventually, but I am surprised that the decision was
made to go so much in a different direction.
Alison
冉兵
return ok(editForm.render(id, form(Task.find.byId(id))));
This looks like LISP! Personally I can deal with this kind of
programming because I use LambdaJ and I like vaguely fluent
interfaces, but this isn't always popular in the Java community. The
old format would presumably be:
Task task = Task.findById(id);
render(task);
What do I want to find? A task. How do I want to find it? By id. What
do I want to do with it? Render it. This is a lot more straightforward
than talking about an editForm (what is that?) and forcing an ok()
wrapper around 99.99% of return statements.
...
Alison
Pascal Voitot Dev
Even if I think Scala requires some discipline not to write incomprehensible lines of code as one can find on the net sometimes and offers a few complex concepts that I wouldn't put in every developer's hands (but it was the same thing in C/C++), I think it brings a much better ground to build efficient and complex modern systems than Java.
Yet I understand your fears.
This is, in my opinion the biggest challenge of Play team to make this new Scala core be transparent to Java people and reassure them that it wasn't an error to invest on Play coming the heavy JEE world...
But play team is aware about this apparently and we are a few ones aware of this so we'll try to be careful :)
Pascal
Piero Sartini
> is now an aging language stuck in a state where every move is like so slow
> that it's not even worth anymore. Hopefully the VM is still alive.
Don't you think that this "slow" and conservative progressing is one
of the key factors of Java's success? Really, its not that "hip and
cool" like other newcomers on the JVM - BUT it worked for the last 15
years without breaking backward compatibility. Together with plain C
it is the most used programming language, far ahead of any others
(TIOBE). It has evolved into something that is easily useable for
nearly every kind of project, _and_ it is quite comfortable nowadays.
But this whole discussion about Scala pros and Java cons has nothing
to do with the concerns stated in this thread. These are non technical
and should not be alleviated by FUD about how worth Java is or is not.
Pascal Voitot Dev
> I'm sad to see that JavaDon't you think that this "slow" and conservative progressing is one
> is now an aging language stuck in a state where every move is like so slow
> that it's not even worth anymore. Hopefully the VM is still alive.
of the key factors of Java's success? Really, its not that "hip and
cool" like other newcomers on the JVM - BUT it worked for the last 15
years without breaking backward compatibility. Together with plain C
it is the most used programming language, far ahead of any others
(TIOBE). It has evolved into something that is easily useable for
nearly every kind of project, _and_ it is quite comfortable nowadays.
Don't misunderstand me, I'm a java lover since very long (and i code in Java everyday for hours).
But since 2-3 years, after spending a few time on C#, Python, Groovy, I began to feel that Java was not moving enough with new syntaxes or new designs... Everything is slow in Java world due to its very heavy standardization process. Being stable is an advantage but being stuck in the same state for too long is a drawback after a few time.
Due to new technologies around web/mobile/distributed/..., Java doesn't fit anymore very well sometimes (for web particularly, it's really overkill outside Play). To write something you write in 2 lines in Python, you need 10lines in Java.
Groovy is the best example of it... It looks like Java (yet being dynamic) but it brings syntactic sugar and new concepts that are so practical that I don't understand why they didn't appear in Java sooner. I don't ask Java to be hype but Collections in Java is just a pain for ex, why don't we have Mixin in Java???...
Moreover, when you compare Java to C# for ex, you begin to think that Java hasn't been evolving for a few years now and it's a pity IMO (which is very subjective).
So yes Java is something widespread that is usable by everyone and it will remain the most used languages for years but it's not a reason NOT to make it evolve (without breaking backward compatibliity naturally).
Hopefully for Java, there is a very good VM on which we can run other languages now and there are so great libraries in Java that it's the best platform to build professional apps and that's why Play is great compared to Django or Rails.
IMO, the real interesting part of Java is now the VM and the language is just one among others. But give a try to Scala just to see its concepts, if you like developing, you should find it really refreshing and you should see your lines of code quite different in a few weeks ;)
Anyway long life to Java as a platform ;)
Pascal
But this whole discussion about Scala pros and Java cons has nothing
to do with the concerns stated in this thread. These are non technical
and should not be alleviated by FUD about how worth Java is or is not.
ogregras
To write something you write in 2 lines in Python, you need 10lines in Java.
Pascal Voitot Dev
On Monday, October 3, 2011 6:30:17 AM UTC-4, Pascal wrote:To write something you write in 2 lines in Python, you need 10lines in Java.I don't want to enter this discussion again, but I'll only say that this resumes how I see Scala : "you need 2 lines instead of 10 in Java". And this is exactly one of the reason why I'm not attracted by Scala! I prefere readable and easy to understand code over compact and powerful one. I've seen some Perl code been able to do some very complex tasks in very few characters. And it was very hard to understand!
But nobody forces you to write Scala!
If you take perl as an example it's clear that it's a very very bad example... Perl is just for crazy people... write it, never read it again XD...
Just for personal knowledge, read a few things about Scala, it's worth the glance and really enriching for software design in general!
Pascal
I would never, ever, use a line like "return ok(editForm.render(id, form(Task.find.byId(id)))); " (if this is a real example from upcoming Play 2.0).
--
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/-/dRxMd7WglQ4J.
Martin Grigorov
<pascal.v...@gmail.com> wrote:
>
>
> On Mon, Oct 3, 2011 at 1:05 PM, ogregras <ogre...@gmail.com> wrote:
>>
>> On Monday, October 3, 2011 6:30:17 AM UTC-4, Pascal wrote:
>>>
>>> To write something you write in 2 lines in Python, you need 10lines in
>>> Java.
>>
>> I don't want to enter this discussion again, but I'll only say that this
>> resumes how I see Scala : "you need 2 lines instead of 10 in Java". And this
>> is exactly one of the reason why I'm not attracted by Scala! I prefere
>> readable and easy to understand code over compact and powerful one. I've
>> seen some Perl code been able to do some very complex tasks in very few
>> characters. And it was very hard to understand!
>
> But nobody forces you to write Scala!
> If you take perl as an example it's clear that it's a very very bad
> example... Perl is just for crazy people... write it, never read it again
> XD...
the lang is bad.
I'm not sure how good is your Scala but for a Java guy reading code
with Scala parsers (e.g. see the methods in RouteFileParser:
https://github.com/playframework/Play20/blob/master/framework/play/src/main/scala/play/core/Router.scala#L539)
it will look the same crazyness. When you spend some time on it you'll
see how it is good.
But this is valid for Perl too - it is still the best lang for
parsing. Spend some time to learn it and you'll love it compared to
Java for the same task :-)
Piero Sartini
> began to feel that Java was not moving enough with new syntaxes or new
> designs... Everything is slow in Java world due to its very heavy
> standardization process. Being stable is an advantage but being stuck in the
> same state for too long is a drawback after a few time.
For some, it is an advantage. Bigger projects need time to develop -
and its not good if everything changes too often.
> Due to new technologies around web/mobile/distributed/..., Java doesn't fit
> anymore very well sometimes (for web particularly, it's really overkill
> outside Play). To write something you write in 2 lines in Python, you need
> 10lines in Java.
Depends... take your examples:
web
for action based frameworks, more low level - in one word rails style
of developing there is nothing in java except Play! Stripes has some
good concepts, but seems not to be get much love lately.
But if it comes to component based frameworks which are used by more
and more companies there is not much missing.
Seaside! would be my favorite framework, but Smalltalk is nothing I
can introduce without heavy contrary wind. In Java you can choose
between Wicket, Tapestry and Seam/JSF2 (as well as some more). All of
them are excellent frameworks to use. But right, we are in the
enterprise domain here. It doesnt make sense to use component based
frameworks to build small to medium sized portals. But its not like
Java has not its place in web development as well.
mobile
we have two big players in this space. iOS and Android. One of them
uses Java the language (not the JVM), and it is not beside the point
to say that its one of the reasons google was able to build such a
great ecosystem that fast. So it seems as Java is suited really well.
distributed
not sure what you mean exactly, but looking at Hadoop, ZooKeeper at
the one side and cloud offerings like google's appengine and amazons
stack my feeling is that Java is not inoperative in this space as
well.
> Groovy is the best example of it... It looks like Java (yet being dynamic)
> but it brings syntactic sugar and new concepts that are so practical that I
> don't understand why they didn't appear in Java sooner. I don't ask Java to
> be hype but Collections in Java is just a pain for ex, why don't we have
> Mixin in Java???...
Groovy is great, but I would never want to write backend logic in it.
This needs to be statically typed - we can leverage the power of
groovy very easy inside of Java code (BSF) - thats the best of two
worlds where it is needed.
About mixins, I dont think this is something that needs to get into
the language itself.
> Moreover, when you compare Java to C# for ex, you begin to think that Java
> hasn't been evolving for a few years now and it's a pity IMO (which is very
> subjective).
> So yes Java is something widespread that is usable by everyone and it will
> remain the most used languages for years but it's not a reason NOT to make
> it evolve (without breaking backward compatibliity naturally).
But it does evolve - java 7 is a compromise, and we all know why. But
it brings many neat little things. Java 8 is suspected to bring the
bigger things like lamdba expressions (closures) and jigsaw. So I
really dont see it the way you do.
> Hopefully for Java, there is a very good VM on which we can run other
> languages now and there are so great libraries in Java that it's the best
> platform to build professional apps and that's why Play is great compared to
> Django or Rails.
Full Ack. But we need to consider that Rails and Django can run on the
JVM as well with.
> IMO, the real interesting part of Java is now the VM and the language is
> just one among others. But give a try to Scala just to see its concepts, if
> you like developing, you should find it really refreshing and you should see
> your lines of code quite different in a few weeks ;)
Yeah, maybe. I've looked at it some time ago and it did not attract me
too much, but maybe its time to have another look. Clojure looks
interesting for learning new concepts as well. But if it comes down to
web development, JRuby on Rails is a far better option than learning
Scala. As mentioned before there is no chance we can use a Scala web
framework for our projects. If we decide to train people into a new
language for web development, it will most likely be JRuby as it is
acceppted by more people.
> Anyway long life to Java as a platform ;)
signed.
GrailsDeveloper
I think you miss the point. It's not relevant if Java or Scala is the
better language. The point is, are there enough developer/user of play
who can read, understand and modify the core-code. In the past this
was often necessary. I have doubts that it wouldn't be necessary in
the future, but if documentation and quality of the core is good
enough it's possible. This is for me a big disadvantage of changing to
scala. I personally hadn't seen the advantage. I would assume that the
most parts can be done in Java.
Niels
On 3 Okt., 13:18, Pascal Voitot Dev <pascal.voitot....@gmail.com>
wrote:
> > On Monday, October 3, 2011 6:30:17 AM UTC-4, Pascal wrote:
>
> >> To write something you write in 2 lines in Python, you need 10lines in
> >> Java.
>
> > I don't want to enter this discussion again, but I'll only say that this
> > resumes how I see Scala : "you need 2 lines instead of 10 in Java". And this
> > is exactly one of the reason why I'm not attracted by Scala! I prefere
> > readable and easy to understand code over compact and powerful one. I've
> > seen some Perl code been able to do some very complex tasks in very few
> > characters. And it was very hard to understand!
>
> But nobody forces you to write Scala!
> If you take perl as an example it's clear that it's a very very bad
> example... Perl is just for crazy people... write it, never read it again
> XD...
> Just for personal knowledge, read a few things about Scala, it's worth the
> glance and really enriching for software design in general!
>
> Pascal
>
Rakesh Waghela
Pascal Voitot Dev
Perl is just like RegExp... you can't understand something you wrote 6months ago, it's impossible XD
Martin Grigorov
> views in scala makes me feel either im alien or the view !
> https://github.com/playframework/Play20/blob/master/samples/todolist-java-ebean/app/views/form.scala.html#L7
Nice example!
It is plain simple: if 'maybeId' is not null then update the entry,
otherwise the entry is new so save it.
But this example shows that the application developer should know some
Scala to be able to use the new more powerful templates.
Pascal Voitot Dev
views in scala makes me feel either im alien or the view !
My first day in Scala (a few weeks ago) was a bit like that... the syntax is quite different from Java, it's true and you have often a bit more information than in Java!
But after a few hours in it, you become accustomed to it and it's as reading python or ruby or any language...
In your ex, you see the great great Option feature of Scala which makes code really cleaner and robust against NPE... Here the line is quite compact, it's true. In Java, we are not used to have chained functions in general but you can format your code as you want to have more clear spaces and distinguish blocks...
Anyway, I understand your concerns and hope Play team will hear you!
Concerning Scala templates vs Groovy templates, I really won't regret Groovy: a Scala template is compiled and quicker... If I want a template engine outside Scala, I'd prefer using Japid or Cambridge as we said a few times in this thread IMO ;)
Guillaume Bort
> Scala to be able to use the new more powerful templates.
Not exactly. I've written it using Option here, but it could be
written this way:
@helper.html.form( if(maybeId == null) routes.Tasks.save() else
routes.Tasks.update(maybeId))
Also the complexity of this line comes from the fact that both create
and edit templates are merged into a single template that handle both
actions. Actually in the previous post I've posted a simpler example
using separate templates. https://gist.github.com/1238475
Being able to properly use a single template to handle both edit and
create is an advanced use case (almost impossible to achieve it
properly in Play 1.x). As beginner you will probably use more
straightforward code like in https://gist.github.com/1238475
--
Guillaume Bort, http://guillaume.bort.fr
Martin Grigorov
>> But this example shows that the application developer should know some
>> Scala to be able to use the new more powerful templates.
>
> Not exactly. I've written it using Option here, but it could be
> written this way:
>
> @helper.html.form( if(maybeId == null) routes.Tasks.save() else
> routes.Tasks.update(maybeId))
>
> Also the complexity of this line comes from the fact that both create
> and edit templates are merged into a single template that handle both
> actions. Actually in the previous post I've posted a simpler example
> using separate templates. https://gist.github.com/1238475
>
> Being able to properly use a single template to handle both edit and
> create is an advanced use case (almost impossible to achieve it
> properly in Play 1.x). As beginner you will probably use more
> straightforward code like in https://gist.github.com/1238475
Learn Scala to use Scala templates, otherwise use any other templating system.
Rakesh Waghela
Pascal Voitot Dev
"Learn Scala to use Scala templates, otherwise use any other templating system."But do we have any option in 2.0 ? :(
why would japid or cambridge not be supported in play2.0?
Sadache Aldrobi
2. Supporting Play 1.x for only "at least 8 months more"
www.sadekdrobi.com
ʎdoɹʇuǝ
Piero Sartini
> months" comes from.
Nicolas Leroux stated this earlier in this thread (email from 30. Sep):
"Play 1.x will still be actively maintained for at least the next 8 months."
sas
> properly in Play 1.x)
https://github.com/playframework/play/tree/master/samples-and-tests/zencontact/app/controllers
what's wrong with this?
public static void form(Long id) {
if(id == null) {
render();
}
Contact contact = Contact.findById(id);
render(contact);
}
public static void save(@Valid Contact contact) {
if(validation.hasErrors()) {
if(request.isAjax()) error("Invalid value");
render("@form", contact);
}
contact.save();
list();
}
saludos
sas
On 3 oct, 09:18, Guillaume Bort <guillaume.b...@gmail.com> wrote:
> > But this example shows that the application developer should know some
> > Scala to be able to use the new more powerful templates.
>
> Not exactly. I've written it using Option here, but it could be
> written this way:
>
> @helper.html.form( if(maybeId == null) routes.Tasks.save() else
> routes.Tasks.update(maybeId))
>
> Also the complexity of this line comes from the fact that both create
> and edit templates are merged into a single template that handle both
> actions. Actually in the previous post I've posted a simpler example
> Being able to properly use a single template to handle both edit and
> create is an advanced use case (almost impossible to achieve it
> properly in Play 1.x). As beginner you will probably use more
> On Mon, Oct 3, 2011 at 2:09 PM, Martin Grigorov
>
>
>
>
>
> >> views in scala makes me feel either im alien or the view !
smallufo
Steven Elliott Jr
--
Pascal Voitot Dev
Play2.0 core will be written in Scala (because it will bring features/designs that Java can't provide nowadays) BUT you will be able to write controllers/modules/models in Java. The only thing that won't be kept is the Groovy templating which is not really satisfying basically.
Keep in mind that Java and Scala runs in a JVM, that you can call Java from Scala without any problem and Scala from Java also.
But when using Java in Play2.0, you won't be aware of the Scala core except if you use the new Scala templating engine.
Pascal
Stéphane Godbillon
- play 2.0 will support both java AND scala at the same level (none of
them will be second class);
- play 2.0 is written both in scala and java, especially to provide
nice APIs in both languages. Yet it's true that most parts of the core
will be written in scala for convienence and efficiency;
- play 1.x.y WILL be maintained. There is a strong community here,
many apps in production, so don't worry.
The goal is the same as the first version's: to provide a fun and a
very productive java framework. And Play 2 adds an other focus: a
better reliability and maintainabilty (thanks to static typing
everywhere it is possible).
Please keep in mind that Play 2.0 is currently under heavy
development. It's not even an alpha so many things (including APIs)
may change before the official release. It's too soon to worry about
moving from Play 1.x.y.
--
Stephane Godbillon
carlosayam
My recommendations for Play 2.x with respect to Scala:
1) Functional programming allows you to write one liners. So,
developers then to omit the API documentation because the code is
easier to read (to the trained eye). However, this assumes framework
users go to the code and then to the API doc. At least for me, it is
always the other way around, first the API then the code. So, please
provide API documentation, even if the code is a one liner !
Corollary: good naming is paramount, a single line of unrelated verbs
and nouns is harder to read than many lines of probably not that smart
but easier to understand code.
2) Choose carefully third-party libraries in the Scala world (as you
would do in Java). I really think that using the parser API in Anorm
was an unfortunate choice: I don't see a use case for a parser
like .as( (A ~ B) *)... I would recommend to create a mapping DSL
(Scala is supposedly good for this) based on the Rails model (or
similar). So, Play doesn't need to reinvent the wheel (the use cases),
just change the implementation... or Java expert may recommend another
one...
3) I would prefer to use custom operators scarcely, as the Scala
creators advocate. So, pick the really common ones and then stick to
those. But this will be discovered with practice; so don't feel the
urge to turn every method into an operator. And also corollary to (2)
above: stay way from a Scala library that uses them, unless it brings
lot more. Also, if you use operators then Java users won't be able to
call them easily and the promised Java/Scala integration will be
harder.
4) Make the template engine plug-able as many have suggested. Scala is
great for templates, I have already played with it using 1.2.3 and
liked it. But I guess there is people out there that despite the one
based on groovy is not your option now, still want to use it (whatever
the reason). I have heard of jamon (www.jamon.org) which provides a
template language with a compiler to Java, maybe worth exploring if
more type safety is desired.
Hope these suggestion help.
cheers
Carlos
Florian
T.J. Crowder
> Play 1.x will be supported and maintained, period. I don't know were the "8
> months" comes from.
--
T.J. Crowder
Independent Software Engineer
tj / crowder software / com
www / crowder software / com
Sadache Aldrobi
--
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ǝ
T.J. Crowder
> As I stated above, Play 1.x will be maintained, period. We at Zenexity have
> big actual projects with thousands of screens using groovy templates and
> that is not going to disappear any soon.
and makes a lot more sense than the "at least 8 months" statement from
Nicolas Leroux.
Sorry if I (and others?) haven't recognized you speak for the company/
project, it's just really hard to tell who actually does other than
Guillaume. I can't find an "about the team" page on playframework.org,
the closest I can find is the "Contributors" link[1], but of course
not all contributors will speak for the project. So mostly I've tried
to work out who's who by looking at that list, the list of top posters
to the group[2] (though that of course only tells me who posts a lot,
not who has any standing), and searching. The name I was using for
searching was the name in the header of your messages: Sadache
Aldrobi. It doesn't appear anywhere on playframework.org or
zenexity.com, whereas Nicolas Leroux does, repeatedly. Nor does it
appear anywhere on the contributors list, or the top posters to this
group.
But you said "We at Zenexity..." and so I got curious and looked a bit
further, and realized I should also search for Sadek Drobi -- and of
course that name shows up quite a lot on playframework.org (though not
on zenexity.com or .fr, and not on the contributors list), including
places where it seems to be associated with a zenexity.fr email
address. So I assume you must work for/with them and have some
standing to speak for the project.
Just explaining why I, and possibly others, didn't realize you spoke
with any standing other than your own opinion when you said "Play 1.x
will be maintained, period" and why, when you said you didn't know
where that "8 months" thing came from, I told you where: From a source
*seemingly* more closely tied to the project, until I thought to use
the other form of your name.
[1] https://github.com/playframework/play/contributors
[2] http://groups.google.com/group/play-framework/about
Nicolas Leroux
The bottom line is that you can safely start your project with Play 1.2 right now, since the current version of Play is still the best web development platform out there, and because support for Play 1.x is not going to disappear any time soon.
Play 1.x
We will continue to contribute to Play 1.x development for at least six months after Play 2.0 is released. We expect this to include:
• enhancements
• bug fixes
• documentation.
As contributors to the open-source project, we believe this is important to ensure continuity until Play 2 is established and Play 1.x users are able to migrate.
Lunatech Research currently provides consultancy and support for Play 1.x and will continue to do so for up to 5 years. Lunatech is in the same position as many Play users: we are involved with ongoing development and support for several customer projects that use Play 1.x. We are committed to maintaining the applications we develop for our customers, in some cases for more than ten years so far.
Play 2.x
Play 2.x development is ongoing. We want it to be as easy as possible to migrate Play 1.x to Play 2.0, not just for our own projects, so we plan to work on a migration path.
Lunatech will continue to use its Play expertise to support commercial projects. In particular, we will offer assistance with migrating to Play 2.0 as well as long-term commercial support for Play 2.x.
Java vs Scala
Please note that none of the above is about Java vs Scala. Play will not force you to choose between the two; Play is more interested in simpler and more productive web development. After all, Play is for ‘web developers’, not Java (or Scala) developers.
Meanwhile, most of our customers will continue to use Java exclusively, and we also be using Play 2 with Scala.
Nicolas Leroux & Peter Hilton
Play framework committers
Lunatech Research
PS: when I said "at least 8 months", I was talking about enhancements of course.
T.J. Crowder
> Following the discussion around the Play 2.0 announcement, we would like to clarify our position on development and support of both Play 1.x and Play 2.x.
-- T.J. :-)
Maxime
GrailsDeveloper
Just a small comment about
not force you to choose between the two; Play is more interested in
simpler and more productive web development. After all, Play is for
‘web developers’, not Java (or Scala) developers."
of the framework and sometime it was necessary to fix there
something. This is easy to do and I think this is a strength of play.
At the moment we (at my company) switch a batch job from grails/
hibernate to play/ebean, because it's nearly im possible to track the
problem down. The hibernate and grails-code are to big and
complicated. Hope it will become easier with play/ebean. However with
this in my head I think Play 2.0 force you at least to learn scala
reading. How great this problem will be, we will see in the future. So
please have always good source-documention, readable code in your mind
and don't forget Unit-Tests
Niels
Julien Richard-Foy
<openso...@googlemail.com> wrote:
> So
> please have always good source-documention, readable code in your mind
> and don't forget Unit-Tests
+1
TAN Yee Fan
original impression of the situation (partially because I don't know
who's who in this mailing list). I look forward to Play 2.0 and
especially the migration path for Play 1.x users.
Regards,
Yee Fan
On 10/4/2011 6:35 PM, Nicolas Leroux wrote:
> Following the discussion around the Play 2.0 announcement, we would like to clarify our position on development and support of both Play 1.x and Play 2.x. This refers to two things: our work on the open-source project in our roles as committers, and the commercial support that we provide as part of Lunatech Research.
>
> The bottom line is that you can safely start your project with Play 1.2 right now, since the current version of Play is still the best web development platform out there, and because support for Play 1.x is not going to disappear any time soon.
>
> Play 1.x
>
> We will continue to contribute to Play 1.x development for at least six months after Play 2.0 is released. We expect this to include:
>
> � enhancements
> � bug fixes
> � documentation.
>
> As contributors to the open-source project, we believe this is important to ensure continuity until Play 2 is established and Play 1.x users are able to migrate.
>
> Lunatech Research currently provides consultancy and support for Play 1.x and will continue to do so for up to 5 years. Lunatech is in the same position as many Play users: we are involved with ongoing development and support for several customer projects that use Play 1.x. We are committed to maintaining the applications we develop for our customers, in some cases for more than ten years so far.
>
> Play 2.x
>
> Play 2.x development is ongoing. We want it to be as easy as possible to migrate Play 1.x to Play 2.0, not just for our own projects, so we plan to work on a migration path.
>
> Lunatech will continue to use its Play expertise to support commercial projects. In particular, we will offer assistance with migrating to Play 2.0 as well as long-term commercial support for Play 2.x.
>
> Java vs Scala
>
> Please note that none of the above is about Java vs Scala. Play will not force you to choose between the two; Play is more interested in simpler and more productive web development. After all, Play is for �web developers�, not Java (or Scala) developers.
>
> Meanwhile, most of our customers will continue to use Java exclusively, and we also be using Play 2 with Scala.
>
> Nicolas Leroux& Peter Hilton
sas
I think there should be at least a link to these statement somewhere
in the play 2.0 page. More over, here you talk about play users being
able to migrate to play 2.0, so it's reassuring that you are thinking
about making the transition easier.
I know it's a burden, but nevertheless I would ask you to reconsider
the 6 months period of contribution, specially talking about bugs. You
have several apps on production you'll have to mantain so you'll
surely need to take care of bugs anyway...
Thanks a lot
saludos
sas
Ivan Meredith
the 6/8 months statement - "PS: when I said "at least 8 months", I
was talking about enhancements of course."
Stefan Gündhör
GrailsDeveloper
Hibernate-Solution, but it wouldn't be the default. The goal is that
the default hasn't so much advantages as it's know the case. How ever
even know I can't see really disadvantages using ebean. For example
CRUD works out of the box. The main disadvantage is that you can't use
modules with an JPA-Persistance. For GIS ebean may be a disadvantage,
however with play 2.0 it should become easier to use a database with
are specialized on GIS-Data.
Niels
type...@me.com
> Java vs Scala
>
> Please note that none of the above is about Java vs Scala.Play will not force you to choose between the two;Play is more interested in simpler and more productive web development. After all,Playi s for ‘web developers’, not Java (or Scala) developers.
> Meanwhile, most of our customers will continue to use Java exclusively, and we also be usingPlay2 with Scala.
team to move from ASP.NET MVC to start using Java/Play! instead after
taking over as CTO. I love Scala but my team is not able to adapt that
quickly and transitioning from C# to Java is easier than C# to Scala
right now (not the strongest developers I've ever seen, but we're
working on it). We've built our first app with the Play! Framework and
it was a great experience; it would have been a shame to know it was
going to be unsupported in future releases; but clearly that is not
the case. Great work!
Jeff
experience. I like many others on this thread are
concerned about the radical changes to the framework as we start
comercial products on the soon to be unsupported
existing framework.
In support of the change I tried to pick up scala despite delaying my
current project. Overall the experience was so so with
IDE issues,slow compile times, and lack of documentation.
I even considered moving to Ruby/Rails but could not warm up to
dynamic typing. However I do see value
in the focus of the Rails community compared to the fragmentation on
the JVM and frameworks such as play.
I am new to the opensource world and was wondering if it makes sense
to branch off the existing 1.2.3 framework and have a core
group continue on the java development or will 2.0 be a seamless
transition. It looks like for starters we will need to redo view
templating in scala.
I also have concerns beyond 2.0 with further shifts.
Just a thought I wanted to put out there to others that understand the
internals of play and what the transition will mean to commercial
projects
and those that are not interested in moving to scala.
Cheers,
Jeff
T.J. Crowder
On Oct 31, 3:35 am, Jeff <jeff.tho...@gmail.com> wrote:
> Been using play-java for a few months now and have really enjoyed the
> experience. I like many others on this thread are
> concerned about the radical changes to the framework as we start
> comercial products on the soon to be unsupported
> existing framework.
Play! 1.x is *not* "soon to be unsupported."
From Sadek Drobi ("Sadache Aldrobi" in the mailing list here), a Tech
Lead at Zenexity (the company where Play! was created by Guillaume
Bort et. al.) (http://groups.google.com/group/play-framework/msg/
958b5aad70f83a51):
On Oct 4, 9:21 am, Sadache Aldrobi <sadek.dr...@gmail.com> wrote:
> Play 1.x will be maintained, period. We at Zenexity have
> big actual projects with thousands of screens using groovy templates and
> that is not going to disappear any soon.
consultancy with lots of Play! projects which also provides commercial
Play! support), both of whom are committers on the project, a more
comprehensive statement that same day (http://groups.google.com/group/
play-framework/msg/a484dc9ae41b87df):
> I am new to the opensource world and was wondering if it makes sense
> to branch off the existing 1.2.3 framework and have a core
That will depend on whether a critical mass of people want to do that
such that a project to fork Play! 1.x and develop it separately from
the existing committers is viable. My impression is that the current
committers on the project are pretty enthusiastic about Play! 2, so it
would have to be others who are using Play! 1.x and are so
dissatisfied with Play! 2 for some reason that they're willing to put
in the work required. But this is open source, it's certainly an
option.
On Oct 31, 3:35 am, Jeff <jeff.tho...@gmail.com> wrote:
> Just a thought I wanted to put out there to others that understand the
> internals of play and what the transition will mean to commercial
> projects
> and those that are not interested in moving to scala.
said very strongly that to _use_ Play! 2 you will _not_ need to move
to Scala. The Java API will be a first-class citizen. You'll be able
to use Play! 2 without using Scala at all if you don't want to. I
don't have a specific quote for you a'la the ones above, but just read
this thread from the beginning. You'll probably even be able to use
the old Groovy templates if you want to, although templating is
already different from normal coding and the examples Guillaume's
posted for the default templating (which is Scala-based) look pretty
darned accessible, so you might choose to use them.
In Play! 2, some (substantial) parts of the internals will be written
in Scala, but the API to the framework will be both Java and Scala,
even down (Guillaume has said) to writing plug-ins. So the claim is
that you'd only need to read or write Scala if you wanted to
contribute to the framework itself.
(Lest you think I'm a big Scala fan, I'm not. I'm just re-iterating
what's been said in this thread by the core team behind Play!.)
Hope this helps,
Jeff
I would prefer to see no fork and to proceed on a single code base. We
have too much fragmentation and duplication of efforts
already in the java world :-)
If the java folks can take advantage of and get all the features in
play that the scala folks do without huge changes to how we do things
now
that wil be awesome. In my readings I have found that it can be
difficult to call certain Scala contructs/classes from Java so not
sure how this
will affect us going forward.
Play is the best framework out there so I will keep my fingers crossed
as well as continue on my Scala journey for our next project so we can
stay with Play.
Cheers,
Jeff
Sadache Aldrobi
In my readings I have found that it can be
difficult to call certain Scala contructs/classes from Java
--
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ǝ
Merrick Christensen
Pascal Voitot Dev
I think that if play2.0 is good in java, people will try the scala version when they are ready! It's exactly how I came to scala and now I really think that writing my backend core in scala is certainly more efficient than doing it in java! But I can go on providing java for interfaces in this way.
Pascal
Patrick Decat
On Wednesday, September 7, 2011 11:39:15 AM UTC+2, Guillaume Bort wrote:
[...]On the dedicated page at http://www.playframework.org/2.0, you can
track progress on this exiting project.
there was a nice interactive timeline at this url, but it is now responding 404.
The only mirror I found is http://playdoces.appspot.com/2.0
Is there another place at playframework.org where it is maintained?
Best regards,
Patrick.