Related
I don't have much experience in frameworks or languages, so i need your help.
Here's what i've done so far so you can understand where i'm coming from.
I've developed a web app using Java/Spring MVC/Hibernate. on the front end i've got some jquery datatables doing ajax calls to a db, another pages executes a stored prod and thats about it.
Now i got fed up with all the configuration, beans, hibernate mapppings, spring mappings, apache tiles, and the list goes on.
I had a play with Groovy/Grails and that seems so much easier, but that means i need to learn groovy and i've heard about it's performance weakness.
So i ran into Play Framework, can someone tell me if Play would make my life easier with the above scenario or should i just go into Groovy/Grails or even scala/lift.
I don't have too much time on my hands to pick up another language so if i can stay with core Java and use Play that would be great.
So is my described headache the reason why there's RoR/python-django, grails ect,ect? or is it something else?
thanks,
glenn.
I can tell you from the perspective of a 10 year J2EE developer who went from JSP/servlet to Grails to Play. 6 years ago I discovered groovy and I liked it very much, I've been using groovy and it's GSP templates in my other projects for code generation. I really love groovy syntax. Because you can do a lot in a single line of code ;) Because of groovy I tried Grails. But, besides the use of the language to code something in perhaps some 20% of the project time, you are 80% dealing with Grails conventions. How do they map this and that and to the persistence layer (which is JPA underneath the surface). So you're browsing the docs most of the time.
Then I found play. It really felt natural. Everything is so quick with it. Everything is direct, it is 80% undisturbed, productive coding, only 20% reading the docs. The code completion of any Java IDE is literally sufficient support. In Grails you either need a Grails IDE or you find yourself frequently browsing the docs.
The biggest attractor of Play to me is the hot code swap feature, which nearly completely eliminates the build phase. Play's class enhancers give you enough comfort to get over the loss of those dynamic finders in Grails. In the meantime, I even write my own enhancers to get even more comfort.
In a real project, the strongly typed Java language is a huge benefit to all developers. You just can't break it so easily as you can with groovy.
Also, if you look at the Play package, you always get reasonable defaults. Things that all developers like. jQuery based CRUD, beautiful code samples, good visual experience. And it's all as minimalistic as possible. Which means, you can always go to the play framework source itself and read the code to understand play's behavior.
So to sum up, after 10 year of Java and J2EE frustration and almost giving up on Java I switched back to it as implemented by Play, because in Play it is so much fun and I now love it again. I recommended play to 2 other developer friends and they love it too. It feels like the Java that it should have been in the first place. Fast, clean, secure & a lot of fun. I will never use something else based on Java, not even for a simple main() ;)
Play!
After 6 or 7 years of Spring/Hibernate, a couple of more with JSP/EJB I was done with the Java world, looking for other alternatives like Scala, Node.js, Rails, etc. Play Framework has made me fall in love with Java all over again, even though I do recommend Scala.
I have lots of information about Play on my blog http://geeks.aretotally.in and http://playframework.info.
It's super easy to pick up, it's crazy productive and you will have lots of fun!
If you ask a Play framework guy, he will tell you to use Play. If you ask a Scala/Lift guy, he will tell you to use Scala/Lift.
Ideally you'd like to find someone who has used Groovy/Grails, Scala/Lift, and Play, but unfortunately there are not too many of those around.
FWIW, I use Groovy and Grails, and like it a lot. If you already know Java, Spring, and Hibernate you already know most of what you need to be productive with Groovy/Grails.
If you don't want to spend a lot of time learning a new language, I'd stay away from Scala, as it's a very different language to Java, whereas Groovy is almost a superset of Java, and with a familiar syntax.
I know virtually nothing about Play, but I'd be concerned about the size of the community - check the number of Play and Grails questions on stackoverflow for a rough comparison.
Grails 2.0 performance will be pretty much on par with the static typed languages out there.
Based on your current architecture, Grails would be the most natural fit - you can re-use all existing classes and code without an issue, and have it directly picked up. You can freely use #Autowired and other Spring annotations, java code, and Grails picks it up - because Grails is Spring under the covers. The only part that might need a little tweaking are JSPs, but I was able to get existing JSPs and custom taglibs working without an issue. Grails uses SiteMesh to compose it's Groovy Server Pages (think JSP groovy-ized, and removing some of the JSP restriction gotchas).
Nothing against Play, Lift, Clojure's web framework, SEAM, or any of the other frameworks out there -- but if you want a simple transition from what you have to something a little more productive, then Grails would be the closest fit.
Of course these days, just about every one of those frameworks supports polyglot programming - you use Scala for something, Groovy for something else, and Java all around - compilers, build environments, and tools are all addressing polyglot development.
Long story short, it comes down to requirements and risk management - do you need functional programming, dynamic typing, re-use of your Spring controllers, or just some simplification and productivity boosts?
Even a simple Spring 3.1 upgrade may eliminate some of your XML files for annotations and solve most of your problems.
Happy Hunting!
A legacy web application written using PHP and utilizing MySql database needs to be rewritten completely. However, the existing database structure must not be changed at all.
I'm looking for suggestions on which framework would be most suitable for this task? Language candidates are Python, PHP, Ruby and Java.
According to many sources it might be challenging to utilize rails effectively with existing database. Also I have not found a way to automatically generate models out of the database.
With Django it's very easy to generate models automatically. However I'd appreciate first hand experience on its suitability to work with legacy DBs. The database in question contains all kinds of primary keys, including lots of composite keys.
Also I appreciate suggestions of other frameworks worth considering.
Use sqlalchemy. On any framework you choose. It can reflect your database as ORM.
I’m currently rebuilding a legacy PHP web application with a MySQL database my self.
The PHP code was kind of spaghetti and is now rewritten in Java as it type safe, promotes well-structured code, has excellent tooling and has superior unit testing capabilities. For database to Java mapping I use Hibernate/JPA.
The web application is incrementally delivered to production. Meaning we run both Java and large parts of the old PHP code together until the application is fully converted.
But in order to use hibernate effectively we needs the database to be logical correct (something MySQL MyIsam does not enforce). So with each production release I run an refactoring scripts for the database (also used to build the development environment and do unit testing) and update the PHP code with a new version that works with the schema changes.
As a web framework I use Stripes as it’s simple, elegant and easy to learn.
I have very good experience with Django. Every time I needed it was up to the task for interfacing with existing database.
Autogenerated models are the start, as MySQL is not the strictest with its schema. Not that it will not work only that usually some of the db restrictions are held in app itself.
My first thought would be to use Hibernate and Java, but I may be biased because that is what my experience is in. You generally map your Model classes via Hibernate after you create the database anyway, so it might not be a bad choice.
I'll let it explain itself to you: Hibernate's website
I suppose that any PHP Framework (I'm a PHP guy, so I will only talk about PHP) could be OK for you ; but you should use one that's well-supported, has a large community, ...
To make things short, I'm thinking about one off this list :
Symfony
Zend Framework
CakePHP
Kohana
Code Igniter
Now, if you're asking "which framework is the best", it's a question that doesn't really have an answer : it's mainly a matter of personnal preferences...
Still, here's a couple of questions+answers that could bring you some interesting informations :
Best PHP framework for an experienced PHP developer?
What PHP framework would you choose for a new application and why?
To use a PHP framework or not?
PHP Framework Decision - Analysis paralysis!
PHP - MVC framework?
Which PHP Framework is right for this project?
Also, note that choosing a Framework is an important decision -- which means you should take some time to evaluate each framework and how it'll answer your specific need.
Really : you should definitely not rush that decision.
You know, there's a whole Ruby web dev world away from Rails, e.g.:
Sinatra
Ramaze
Webby
With such a general question it's always a bit hard to help...
Try web2py, extremely easy to prototype any webapp, and IMO a bit easier to grasp (overall) than other similar web frameworks, HTH
There are no clear cut winners when picking a web framework. Each platform you mentioned has its benefits and drawbacks (cost of hardware, professional support, community support, etc.). Depending on your time table, project requirements, and available hardware resources you are probably going to need some different answers.Personally, I would start your investigation with a platform where you and your team are most experienced.
Like many of the other posters I can only speak to what I'm actively using now, and in my case it is Java. If Java seems to match your projects requirements, you probably want to go with one of the newer frameworks with an active community. Currently Spring Web MVC, Struts2, and Stripes seem to be fairly popular. These frameworks are mostly, if not totally, independent of the persistence layer, but all integrate well with technologies like hibernate and jpa; although you have to do most, if not all, of the wiring yourself.
If you want to take the Java road there are also pre-built application stacks that take care of most of wiring issues for you. For an example you might want to look at Matt Raible's AppFuse. He has built an extensible starter application with many permutations of popular java technologies.
If you are interested in the JVM as a platform, you may also want to look at complete stack solutions like Grails, or tools that help you build your stack quickly like Spring Roo.
Almost all of the full stack solutions I've seen allow for integration with a legacy database schema. As long as your database is well designed, you should be able to map your tables. The mention of composite keys kind of scares me, but depending on your persistence technology this may or may not be an issue. Hibernate in Java/.NET supports mapping to composite keys, as does GORM in grails (built on hibernate). In almost all cases these mappings are discouraged, but people who build persistence frameworks know you can't always scorch earth and completely recreate your model.
I'm considering developing a school information system using the Grails web framework. Before a school can use the system, they will need to setup the following data
School data
Students
Teachers
Subjects
Classes
etc.
I'm considering using a CMS in order to get the ability to CRUD these entities "for free". The CMS may also provide other features out-of-the-box that I could use.
Ideally the CMS should be implemented in Java or Groovy, does anyone know of something suitable? I looked at the Weceem CMS plugin for Grails, but it's missing some core concepts I need, e.g. the ability to add users to groups.
Thanks,
Don
Java is good for rock-solid, high-performance, secure Enterprise apps. Java is considerably less good for getting a relatively simple Web project out the door in a short time.
Therefore, were I in your position, my personal gut feeling would be to go with something Grails based. I'm not very aware of any projects that already partially implement what you want, but if you can find one (Google?) then grab it! That will leave you more time for polishing and adding bells and whistles.
If you're not tied to Java, I'd recommend looking at Drupal for PHP as your CMS. Many sites, even sites of major Java organizations such as SpringSource, have used Drupal as their CMS because it offers so much out of the box.
Magnolia CMS 1 in version 4.3 has full-blown Groovy support. After 7 years of active development, a CMS like Magnolia provides you with a ton of stuff you need to run a website. I wouldn't even think about starting from scratch no matter what framework you use. Understanding the problem you are trying to solve and finding a solution to it is usually taking more time than actually implementing said solution. Even if you believe you know what you need now, rest assured your requirements will overrun you before you know it.
I know it's not Grails related, I would use the DaisyCMS, as it's java based you can add an extra Java Web applications to the Jetty and add extra functionality to the CMS using Grails for your other functinality. I hav enot tried this, it's just a suggestion.
Use Grails scaffolds to get simple CRUD functionallity.
Do you really want to build it from scratch? There are already open-source CMS. In your case I would evaluate open-source CMSs and if necessary would contribute code.
Does it need to be Java/Grails? There are good ones written in PHP or Python (django, joomla).
I tried Grails 1 year ago. It is very straightforward as long as you align with the concepts and standards (e.g. simple CRUD scaffolding). But if there a special requirements you get to similar efforts as with a Java framework like Spring MVC (though grails is also based on Spring MVC).
I'm a full time Java developer of around 4 years, professionally. I'm a GWT fanatic. I love Java. Here's the problem: In my free time I often fall victim to the verbosity of my favorite tools for doing "heavy" development. I also often fall into the trap of obsessively engineering my software. I'll end up with the most beautiful unfinished implementation, ever.
So, here's what I normally work with.
GWT - I use this for dynamic UI and web layout. I love the ease of re-use and it has taught me to absolutely hate javascript. I really can't even bring myself to do much HTML/JS anymore.
Hibernate - POJO to Database, easy-peasy. What i really need from this other than the mapping is that it allows me to have an application that works across multiple databases.
Spring - Mostly security. I've written my own custom LDAP bits for a project.
XML - I've used dom4j and other implementations, including xstreamer. I'd like to use JiBX for XML transport. The problem with this is that I need XML messages that conform to a specific standard rather than being autogenerated. Object->XML->Object are also common enough that it can be a performance bottleneck with large messages (250KB+).
I tried Lombok for a little while and liked it but had occasional issues with it and then I blew up a partition and lost all that work. I don't really feel like doing the same thing again (half the fun was in learning how to do it, now that I know... meh). This taught me why other people want to reduce the explicit code and replace it with an implicit system.
I've been looking into Grails but that runs me into the JavaScript problem (you know, that I don't like it) pretty quickly. I could use GWT with Grails on the back end but I get back into the problem of getting deep in the weeds with GWT. It has also occurred to me that there might be a way to have Grails tags in GSP that are made up of GWT widgets. I'm not really sure how I feel about that.
Another problem I have with Grails is that validation logic before form submission is separated from validation constraints after submission. I don't see how they can be unified (yet) to produce "pretty" front-end validation. I went out of my way to start a JSR-303 compliant validation project for GWT to help solve some of this problem for GWT and really liked the results. It isn't finished but I still find it useful.
So, help me find a better way!
TL;DR - I want to have a Database (and Database-Independent) to GUI solution that allows for dynamic web programming all in one language. Failing that, as close to one language as possible.
TL;DR is TL;DR - I hate JavaScript now, help.
EDIT: I know that it is techincally impossible to do "Web 2.0" development without JavaScript. I'm just trying to not be the guy who has to write it. (Getting a tool such as GWT to do it for me from a language I do like, for example.)
Just learn JavaScript.
Resistance is Futile
...and you will be assimilated.
PD: I'm an ex JavaScript enemy. Now it's my favourite language.
You can certainly develop an entire Web 2.0 project without coding Javascript using GWT (we have), but at the end of the day you still have to know HTML/CSS & Javascript.
This might sound like a stupid statement, but it's not once you consider that GWT is not a perfect abstraction, nor is it designed to be. It wasn't written in Java so that you didn't have to ever code in Javascript again, instead they did it because Java has better IDE's, is statically typed and makes maintenance a hell of a lot easier.
So yes, by all means go with GWT (and check out the new OOPHM, because it's AWESOME) but don't forget that you'll always need an understanding of the underlying frameworks of the web, if you want to develop for the web.
Have you heard of Echo?
It doesn't provide the database part of the problem, but it would work well with any database that you can work well with.
Echo is a platform for building
web-based applications that approach
the capabilities of rich clients. The
applications are developed using a
component-oriented and event-driven
API, eliminating the need to deal with
the "page-based" nature of browsers.
To the developer, Echo works just like
a user interface toolkit.
The latest iteration, Echo3, features
the ability to write applications in
either server-side Java or client-side
JavaScript. Server-side applications
run in any Java Servlet Container and
do not require developer knowledge of
HTML, HTTP, or JavaScript.
You might want to take a look at some of the AJAX powered JSF libraries. IceFaces and RichFaces are both solid.
Been there, done that. I was a GWT developer for 3 years... I started using it in v1.1! GWT is fantastic, and works really well for small applications. But the development comes to a crawl once you it a moderate application size, even if you divide your application in sub-modules.
It is also quite ironic that a UI framework has such limited UI creation tools. :)
Personally I bit the bullet and learned javascript. It isn't as bad as I thought. Especially with jQuery. :)
Obviously there is no perfect framework. But just the fact that GWT has been out for 3.5 years now, and it still largerly ignored in the Java world should tell you something. Since you're doing this on your free time, I would recommend learning the most popular framework: Struts. You'll see its limitation, and also why it is so popular. Of course, you'll need jQuery for that 2.0 functionalities. :)
Take a look at JRapid, a rapid development platform for Java developers. It generates very powerful Ajax enabled UI without the need of coding.
Not sure if you would like this , but have you heard about Haxe?
You might not like it but its AIO (all in one) solution (sort of).
I can understand your dislike of JavaScript and it certainly has its problems but I think your fighting nature at this point.
Web 2.0 is strongly based on JavaScript for a good reason as it provides the ability to perform tasks on the client machine without requiring page loads.
I'm sure there are alternatives but if you want the look and feel of Web 2.0, you will end up doing a lot more work with little reward. JavaScript is the accepted and functional tool for the job.
I'd say stick with GWT and just drink more of the Koolaid. It's a completely awesome development model that seems to be lost on those who haven't tried it.
If you want to improve your GWT experience, jump to the bleeding edge (I work off trunk, it's quite stable) and use the other Google originated projects like GIN, gwt-incubator and Guice. Especially watch Ray Ryan's GWT best-practices Google I/O talk: http://www.youtube.com/watch?v=PDuhR18-EdM
As for the "framework" part: forget 'em. Just use normal servlets and let GWT take care of the RPC for you. Servlets are a pain when you have to deal with JSP and you're own AJAX calls, but when they're only implementing asynchronous app logic, it's not that bad at all. Guice Servlet makes it all quite easy. You can still use a JVM hosted language to write your servlets if you want.
GWT has an incredible advantage over other JavaScript frameworks in that the layer of abstraction it provides allows for major future advances without any changes to your code. If the GWT compiler and browser detection scripts can take advantage of new browser features then you benefit from a simple recompile.
The big annoyance I see in your requirements in XML... hopefully that's just for integration with a 3rd party service and your client-server communication can just be GWT-RPC.
I don't use javascript or ajax, in medium-large application they create a lot of problem with compatibility, because moving some part of code inside client, create security breaches and problem with different browser.
I use only HTML(5) and CSS2/CSS3, and I have a lot successes.
I use this 2 ways:
using "puzzle-techinque". Write a lot of small and simple template (or tiles) to create the big page. I use only JSTL and Spring tag, with Rich/Prime/Ice-faces I encountered a lot of problem with rendering, page building and flow controller, so I discarded them.
using my custom library to parse HTML pages. I create template with my custom grammar, put inside the parser and write on output stream. This is the best way.
If you say me your preferred language and context, I can help you to perform JS-free.
I'd like to know how you address the seemingly low productivity of Java EE-based web application development compared to other technology stacks (Seaside, Ruby on Rails, etc).
The constraints are:
The finished web application must be deployable on Java EE compliant application containers
If possible, previous investment in Java-based solution should be preserved, i.e. native interoperability with Java-based systems and libraries should be possible
Due to team structure, Java as implementation language is preferred, although less exotic JVM-based languages (i.e. Groovy) might be acceptable as well
The resulting system needs to be architecturally sound
The resulting system needs to be extensible and maintainable
To not let this dwindle into a philosophical discussion, I'm only interested in suggestions that are based on practical experience. Possible examples include domain specific languages, frameworks and MDSD.
If you point to an abstract class of solutions (like MDA / MDSD), please provide details on how you implemented it as well as information about common pitfalls and best practices.
If you disagree on the assumption that Java EE-based web application development implies inferior productivity, I'd like to hear your reasoning as well.
EDIT:
As there are a lot less answers than I expected, I'll accept accounts of abortive attempts as well, basically extending the question to "How (not) to improve productivity when developing Java EE based web applications?".
I believe the Java EE Java stack is actually very good. There are a few reasons explaining the low productivity of Java EE:
Being “the enterprise stack”, it is often used to create boring, ugly, “good enough” applications and, in general, enterprises tend not to attract great developers who love programming, and think and care about what they do. The quality of software in the enterprise world is not great.
Being the enterprise stack where the money is, software vendors try to sell something to them. They create huge, complex and expensive solutions not because they are good, but simply because they could sell them to enterprises.
Enterprises are often very risk averse and everything they do better be “standardized”. Standards are created either after some technology proved to be successful or before. In both cases, it’s bad for enterprises (and Java). Enterprises end up using either good technology too late or a downright failed technology. The latter case is also very dangerous because it creates a false perception that a technology (otherwise a complete failure) must be good if it is standardized and everyone is using it.
Historically, Java EE platform seemed to have attracted a lot of architecture astronauts and developers in big companies promoted to architects whose only purpose was to create more layers, more frameworks, more abstractions and more complexity.
It’s not that there are no good Java tools and frameworks; it’s that there are too many bad ones, too many over-engineered ones, too many bureaucratic processes and methodologies, too many useless standards.
In such a messy world it’s not just the particular selection of tools you choose that affects your productivity. It’s mainly about you, about your values, about how you can reject the majority of solutions proposed to you by the community, vendors, co-workers and managers. It’s about you going against the current, about your common sense, about you questioning every mainstream belief and “best practice”.
That said, tools alone are not going to change your productivity much, and conversely, the right people can be productive with inferior tools too.
My advice:
Don’t use a technology only because it’s standard, because everyone uses it, or because it’s officially recommended by Sun. Use a technology only if you personally think it’s the best tool for your job. This way you may find yourself rejecting technologies such as JSF, JSP, Web services, JMS, EJB, JTA, OSGi, MDA.
Keep it simple, use your common sense, question everything. Do you really need to publish your objects for remote access? Do you really need to create another abstraction layer so that you can switch from Hibernate to TopLink? Do you really need to convert your data to/from XML ten times every time you need them? Do you really need XML schema? Do you really need everything to be configurable are interchangeable? At runtime? By non-developers?
Keep the process simple. Be agile. Do you really need that documentation? Do you really need to describe every screen in a huge table, have it approved, type it in to some home-made tool and then generate JSP? Do you have competent programmers or you design everything first and programmers only “translate” to Java?
WYSIWYG design of HTML doesn’t work.
Graphical programming in general doesn’t work. This includes UML as blueprint and UML as programming language, MDA, drawing page flow diagrams. Code generation is bad.
Never design a framework prior to using it, always harvest a framework.
Prefer frameworks that have only little XML configuration.
Strive for low LOC count. Look at actual characters in your code. Is every character important? Think. What can you do to make your code smaller? Do you need that class? What does it do? Why do you need to do that?
Testing is not sacred cow; you don’t need 100 % test coverage. Test only what makes sense. If it’s difficult to test, make it simpler; or don’t test it at all. Don’t test visual appearance.
And finally, some concrete Java recommendations:
For presentation layer try Tapestry. Why do I love it? Because with Tapestry you can create beautiful code. It’s designed specifically for that, so that your code can be beautiful. Your code. By beautiful I mean everything that matters – it’s short, easy to change, easy to read, easy to create your abstractions, and still flexible, it doesn’t try to hide the fact that you are developing for the web. Of course, it’s still you who makes your code beautiful.
Feel free to use Hibernate, especially for CRUD and large apps. Don’t bother with JPA. It’s not a silver bullet though, with ORM you are always going to trade one set of problems with another.
Only a little Spring, you shouldn’t need much since you’ve carefully avoided all the Java EE traps. Use dependency injection sparingly.
After all of that, you may find the Java language too verbose and not very helpful when abstracting away you copy/pasted code. If you want to experiment, try Scala. The problem is that the main selling point of Scala is that you get all the benefits of modern languages while still keeping type safety, and at the same time, there is no solid IDE support. Being used to super-cool Java IDEs, it doesn’t make much sense to switch to Scala unless there’s an IDE support that is stable and reliable. Stable enough is not enough.
Frameworks like Spring, Hibernate, Wicket certainly help to simplify and accelerate web development as they provide a high degree of testability and integrate very well. But it's not enough to reach RoR productivity, even if you have a good set of development practices. There is still too much technical stuff and plumbing required.
Grails is maybe the missing piece in this picture to get closer to RoR. It's my next experimentation.
BTW, my MDA experiences are the contrary of a productivity improvement so I won't mention them (actually, MDA was killing our productivity).
Javarebel can greatly reduce time spent during web development using Java.
Let me quote here the official website:
JavaRebel is a JVM plugin (-javaagent) that enables you to see changes to your code immediately, without the need to redeploy an application or perform a container restart. If you're tired of watching the logs roll by, and want to see your changes so that you can keep going - JavaRebel is your new best friend.
One important point when discussing Java EE productivity: you should be using Java EE 5 and EJB3.x since they provide for new level of productivity (and functionality) compared to previous releases.
Staying within standard Java EE specs is absolutely important, e.g. using Hibernate instead of JPA is not beneficial to productivity. There is no limitation to fall back to Hibernate features when using JPA, but by using Hibernate instead of JPA you are locked in into single persistence provider with no cheap way out. The whole idea behind using standards is the same: conceptual flexibility (by plugging in different implementations) with available extensibility (by using proprietary extensions if absolutely necessary). Java EE 5 and EJB3 are huge steps in this direction. Of course, you want to minimize any proprietary features but if some seem absolutely necessary it's a good sign that they will be part of spec in next release...
Main obstacles to Java EE productivity are in its enterprise focus (offers a lot more than than needed for majority of projects) and in its legacy (backward compatibility). There is also a lot more to be done in presentation tier with JSF and state management - watch for JSR-299 to address these among other improvements.
Grails is a Java webapp framework very much modelled after Ruby on Rails, with similar principles (DRY, CoC) and productivity gains, but based on existing Java frameworks (Spring, Hibernate, several others).
I've been working on an exploratory project using Grails for a few weeks now (no previous experience in Grails or Groovy), and I'm quite impressed. There are a few rough edges - it's not as mature as RoR, but you can get results quickly and there's never the feeling that the framework is getting in your way.
Maybe it's best illustrated by this concrete example: I wanted to edit a 2D array of domain objects in a grid on a single webpage and found that the automatic mapping of the resulting HTML request data to the domain objects (provided by Spring MVC, I believe) had a bug that caused some data to be mapped to the wrong objects. I looked around on the web for an hour, but apparently nobody had encountered or solved the problem. Eventually I decided to forego the automatic mapping and do it "manually" - and then found that it took me no more than about 10 lines of code...
It's often cited that RoR and similar frameworks based on dynamic languages are more productive environments, but I am really interested to know if there are hard data to back this up. This wouldn't be easy, as one should be made certain that she is not comparing apples with oranges. Things like type of project (web 2.0, enterprise application) and team size should be taken into consideration. However, for small projects it is more than evident that such frameworks are indeed far more productive than Java EE. So this is a short list of arguments used to support this and what you can do for them in the Java world.
Ruby is a more intuitive and concise language. You can do the same thing with much less code.
I don't think you can have the same thing in Java, unless of course you use a dynamic language that runs in the JVM (JRuby, Scala, Groovy). Otherwise, your IDE can help. In Jave an IDE is an essential tool and it will pay you back if you learn to use it well (code generation, snippets, refactoring). In fact there are many things you can do with a Java IDE that are simply impossible to do with a Ruby or Python IDE. Plus you have the benefits of a static typed language. It may take more time to type, but it helps you avoid common mistakes.
Ruby is much more fun to use. Makes the developer happier and more productive.
Same as above. Highly subjective argument in my opinion though.
Convention over configuration makes things faster
A dependency injection framework like Spring or Guice can help
Scaffolding, MVC already there for you.
Again Java MVC frameworks can help
Databases made easy. Load database items as objects. Can change the database on the fly.
Hibernate, iBatis or another ORM framework can help. With Hibernate Tools you can achieve similar functionality with what you have in RoR with yml files
Load new modules instantly
Maven or Ant Ivy can help
Easy deployment for testing
Your IDE or Jetty can help. In fact debugging is easier with Java
Testing integrated with the framework. Use of mock objects facilitate testing
A dependency injection framework can help with mock objects. JUnit was a pioneer of unit frameworks. I don't think that Java is less easy to test.
I would definitely go for Spring together with Hibernate for persistency related stuff.
Why Spring?
The advantage of using Spring instead of another framework is that Springs philosophy is to be "non-invasive". Usually when you're using a framework most probably you'll start to depend on that framework which can be a bad issue if the application is considered to run for a longer time where you then have also to do maintenance etc. Spring uses the so-called "Inversion of Control" (IoC) pattern. Basically your code doesn't (it can but it doesn't have to) call Spring, but Spring will call you (Hollywood principle: "don't call me, I'll call you"). So for instance you can use normal POJOs (Plain Old Java Objects) and you don't have to inherit from any framework-related classes/interfaces.
Another big problem (if not the biggest) in Software Engineering are dependencies. You'll fight for reducing them as much as possible since they will make your life harder (especially in maintenance later on). Spring reduces dependencies among your components drammatically by managing the instantiation of components through configuration files and the dependency injection pattern. I wouldn't want to go on, the best thing is that you start reading some tutorials at the official Spring website. Initially it may need some time in the understanding but once you got it you'll earn a lot of benefits.
Since Jython 2.5 you can use django to satisfy the requirements you listed. It's pretty easy to generate war files from django projects and deploy them on J2EE application servers.
Just wanted to pitch in another idea... you can actually use JRuby and Rails (similar to the previous comment about Django and Jython).
If you use JRuby with Rails and JRuby Rack (and maybe some other utilities... I wasn't the one to actually get the integration going initially), you can deploy JRuby Rails additions to an existing Java web app. We have a legacy JSP application deployed with Tomcat, and are now starting to add new pages using Rails with just that setup (in addition to extending the JSP side when necessary). So far it has been quite successful, though we don't have any of the major high traffic pages implemented in Rails, so I don't know how well it will scale.
We have full access to the session, and have even set up mechanisms to invoke JSPs from Rails pages (such as existing header and footer type JSP includes). It takes some effort and trial and error to fully integrate the 2, but if Rails and JRuby is an option, I highly recommend it (as a personal fan of Ruby).
A colleague has dabbled in JBoss Seam, which is a framework by Gavin King (the guy who brought us Hibernate), which was meant to emulate Rails. Having seen both, I feel Rails is a lot easier to develop with.
Use AOP (Aspect Oriented Programming) for cross cutting aspects like logging, authorization etc. You can either use Spring AOP or AspectJ. It makes code clutter free and maintainable.
I've used Jboss Seam for the past couple of years and find it to be very productive way to develop in Java EE (utilising EJB3, Hibernate, Facelets). I also do the odd bit of PHP coding on the side and can honestly say that I'm more productive with Seam (although that's probably also an indication of my PHP skills.)
For me a couple of the highlights would be:
Hot deploy of code (an absolute must-have)
DRY with Facelets
Annotation based configuration
Extensive drop-in components (especially ajax4jsf)
IDE Support from Jboss Tools
There are tools in the IDE and from the command line to build skeleton code in a similar way to RoR.
Well, I'm not really a Java guy, so I can't say much, except for... JSF
We tried to use it for some time and it was a disaster. Almots all basics steps had to be passed with lots of pain, no documentation, no examples, no community knowledge. We used then one plugin for Eclipse (Exadel Studio), we had a look at a few other JSF frameworks, they were all incompatible and poorly documented. As a matter of fact, of all those we tried, only Sun framework (forgot its name, based on NetBeans) could create a new JSF project even compilable out of the box. The rest required many days of configuration of apache and other things, which for an unexperienced person is a real challenge (though I managed it).
Our team spent a few months on something which was done later in just a few weeks with ASP.NET. People were both inexperienced in JSF and ASP.NET.
If JSF ecosystem is still that bad as it was in 2007, I would recommend avoiding it altogether, productivity is out of the question anyway. Maybe stick with JSP or something that is time-proved and well developed?
I would go with the Lift framework written in Scala. You will see a great productivity boost just by switching to Scala. Scala is also very stable and it's extremely easy to call Java code from your Scala code. Not only that but it's quite similar to Java but with some added features. For some examples you should refer to 5 Things a Java developer needs to know about Scala. Twitter will move part of it's codebase to Scala.
You will never "get stuck" on a piece of code because you can just think about how you would do it in Java and write similar code. First class functions and actors will give you an even greater productivity boost and are both in Scala. Scala is of course statically typed and has a performance that is similar to Java.
I will quote the author of the Lift framework for an description of it:
Lift borrows from the best of existing
frameworks, providing
Seaside's highly granular sessions and security Rails fast flash-to-bang
Django's "more than just CRUD is included"
Wicket's designer-friendly templating style (see Lift View
First)
And because Lift applications are
written in Scala, an elegant new JVM
language, you can still use your
favorite Java libraries and deploy to
your favorite Servlet Container. Use
the code you've already written and
deploy to the container you've already
configured!
Some basic rules:
Kick out the appserver - a HUGE win in turnaround and quality. Keep a web container if you have to, but configure everything in Spring and/or Hibernate so the web.xml is minimal.
Test everything, which you can now do because of step 1 (no deploy-time XMLs or code generation needed: everything is configured in the development already).
Use Wicket to implement your web tier - nobody needs JSP any more; Wicket is 10 times more productive plus easy to test (see step 2).
Use SCRUM and agile development methodologies
The result is Java productivity as high as 4GLs allow - we at Atomikos have several migration projects we did like this. Because we migrated from 4GL platforms to Java/Java EE, we could compare the estimates in both.
Also see this blog post: http://blog.atomikos.com/?p=87
HTH
Guy