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!
Related
I am php programmer but i am learning java now. i have finished the core java and build small projects using jdbc , mysql gui etc.
Now my boss wants to build the website where user will collect points and they can shop based upon points left.
But the initial phase will be only the logs/registration/admin area etc.
Now i have two options
1)Do in php
2)DO in java
I really want to do in java thats why i was learning it. Now now the project came early.
I wanted to learn spring , spring mvc , hibernate etc , design patterns but now i can't spend time first to learn.
i want to ask that what will be good solution to go at it. Initially was thinking of doing the website in JSP.Is that ok
O i am thinking of using Wicket and not using hibernate, is wicket enough to build ecommerce site. or i need anything else as well
I know only core java , what should i do
PHP development is very action/template-oriented, AFAIK. Wicket is a component-based framework, that heavily applies object-orientation concepts, and that may take some time to grasp. If you don't have much experience with OO, and your deadlines are tight, maybe you'll prefer an action-framework (Struts2, SpringMVC), which is far better than raw JSP. But, if you have some time to spend, and the will to learn, Wicket is definitely a great framework!
Spring is also nice, and while dependency injection is not something you see often in PHP, it's simple enough (Spring is well documented, its reference doc is actually useful, and you'll find many tutorials and examples on the Internet), and it's definitely worth learning.
Hibernate is a very good framework for persistence, but if all you know is plain SQL/JDBC, it takes some time to master it to the point that you don't get frustrated with mapping, and lazy-loading errors. Again, try it if you have some time to spare and the will to learn.
Wicket+Spring+Hibernate is a really nice combo, I use them a lot. It may or may not be the best stack for your case. As everything in IT, it depends on the context. But I think they are very sound technologies, individually or combined.
Consider Struts 2. It is both effective and there is a good size community here if you have any questions. I don't know wicket, but any web framework is better than straight JSP.
Hibernate is nice but since you have a lot on your plate you should probably stick with straight JDBC for now. Spring is also very nice, it is easy to integrate spring DI with struts2 (so easy as a matter of fact I would recommend you just start that way).
One of the fastest ways to get a Java webapp up and running is to use Play Framework.
I would like to start up a project from scratch. I am a java developer for years. I did even write my own mvc framework some time ago for fun. Now I am working in a company using in-house framework - which i think is a total loss of time and money. I respect the idea of teaming up with different skilled people for a large scale project. The separation of the project is very important; Graphics guys, front end developers, software architectures, software developers, database experts, etc. I cannot risk to use a scripting language like php.
Lately, I am researching java technologies for a large scale project in every aspects. What I mean by that, for the front layer I come across with very famous technologies.
Spring
MyFaces
Tapestry
Google Web Toolkit
Cocoon
Velocity
Every one of them states that it is the simplest, the fastest, the latest technology and whatsoever. Of course only one them can hold the truth. I need a front end technology for fast implementation for ajax, customer/administrator security, themes, templates, internationalization, caching static pages, clustering and a support of ejb. It should also have IDE support, community support, rich documentation and online tutorials. Still I have no experience of those frameworks which to choose from. Maybe there is even better one? And most importantly, I cannot risk to start up on a technology which has development limitations. Is there any suggestions for this layer?
For the business layer, I am sure of EJB and JPA. I do even considering a web service for facade of this layer for interoperability purposes for future extensions. However, I have no idea about securing that layer (it could be applied on its web service level) which is still a problem for me. For the application server I am considering GlassFish.
And for the last question is what IDE should be picked for development. Regarding all the technologies, which are going to be used, an IDE should help me in every step, either doing the configuration for me or helping me configuring with its ready wizards. I suppose the IDE will have proper plugins for to be used technologies.
I know that I want too much, however I have a hope for a combination of technologies which will help me saving time and money in my future plans.
I ll be really glad to hear your responses, experiences for a bigger picture.
edited: There is no ultimate answer, I know that. I am just taking advice. Any answer is appreciated.
Well, I'm going to go out on a limb and give concrete recommendations, since I think the question can be answered.
I'll simply recommend my stack.
My stack is Stripes for the front end, and Glassfish/Java EE 5 on the back end.
Stripes is a simple Action (or MVC, whatever floats your boat), that has a small, but robust and vocal community. It has tight integration with JPA (through a plug in), a very good, and current, printer book on the topic as well as excellent reference documentation. It's main rendering tech is JSP with JSP Tags and EL.
It is not a component framework like JSF/MyFaces, so it's implementation is simpler, and it's lifecycle is simpler. It works very well with Ajax.
The key factor around Stripes, since it's based on the HTTP request cycle is that it does most of the grunge work for you, yet is very lightweight. It's easy to pick up and understand. Creating a basic Stripes app is a couple lines in the web.xml and two jars (one of which is log4j). If you can think in HTTP, then Stripes is a good fit for you.
On the back end I would simply stick with EJB and GlassFish. Java EE 6 and GFv3 are out have been out for sometime. It offers a lot of new features over Java EE 5, and GlassFish offers most any web service tech you would like to use. Java EE 6 and Spring are pretty much equal on a bullet point by bullet point basis, and since you were looking at GF, you may as well use EJB since it's there and integrated in the box. If you were using Tomcat, then Spring might be a good choice.
And, that's it. That's all you need (I dunno what you wanted Velocity for, you can add that trivially if you like, but I wouldn't use it for pages, personally, modern JSP is much better IMHO).
Glassfish will secure your web services, you can use Java EE security with your web apps, you can share logic between the back end EJBs and your web app and web services. It all works out of the box with 15 minutes of configuration to get Stripes running.
I use NetBeans, but all of the other IDEs work as well. NetBeans is nice because it come integrated with Glassfish. One less thing to configure. Download it, fire it up, and it works.
There's a Stripes plugin for NetBeans, that I don't use. I don't see a need. Once you add your few lines to your web.xml that you cut and paste from the web site, you never see Stripes again. From there, it's all simple annotations.
Unless you have a crushing need for all of the complexity and learning curve of a component framework, it doesn't get any better than Stripes, and GF w/Java EE 6 has everything you need in the box.
So, in summary: Stripes distro from www.stripesframework.org, NetBeans download from netbeans.org, and stripersist from stripes-stuff.sourceforge.net. It's a rock solid foundation that will go wherever you want to take it.
Come on by to the Stripes IRC on freenode at #stripes, and we'll answer any question you have (or hit the mailing list).
Well, first of all, your question is not good. Every technology has it's bright sides and dark sides. To choose some specific technology - you need experience in all of them to estimate which problems can emerge with your project. Given your definition: fast implementation for ajax, customer/administrator security, themes, templates, internationalization, caching static pages, clustering and a support of ejb - 90% of frameworks support all of it either directly or using some plugins.
Moreover, various technologies are better optimized for various needs. You can't have a all-in-one-super-framework that is flawless and does everything the best way possible. Given that the framework is highly scalable and fast (example: Spring and/or Portlets) will make it hard to configure for some small tasks.
So the only thing I can recommend is to google "Java Web Framework Comparison" and hope for the best.
As about IDE, I can see only 2 choices: IntelliJ Idea and Eclipse. Again, there is no clear winner so yet again google is the only source of information you can get.
Added:
Talking about frameworks again, complex projects use several of them at once taking the best parts of each to aid with the specific project needs. But to do that effectively - you need to be a guru in all of the mixed technologies.
There is almost no way that someone can actually answer this question for you. In terms of frontend technology, one of the frameworks will work for you and others won't. It all depends on which one makes sense to you. My suggestion would be to try them all out and pick the ones that you feel the most comfortable with.
With that being said, I do have a few suggestions. First, don't limit yourself to using Java. If it were me, I would use Ruby on Rails running on jRuby as the frontend as it is the fastest framework for developing web applications that I have used. By running it on jRuby, it allows you to hook into Java and let java and its libraries do all the heavy lifting on the back end. I would stay away from web services and implement things using ReST.
In terms of an IDE, definitely go with IntelliJ IDEA. It may take a little bit to get used to, but it is definitely the fastest IDE on the market. However, both Eclipse and Netbeans are also very good for Java and a tad cheaper.
Once again, the answer is, "it depends".
All of the above projects started off with simple ideas. As they gained traction, they have all added neighboring features which are useful to some but not necessarily all. In other words, you will have to do deep analysis to pick the perfect framework.
You are not going to find a perfect match unless you just happen to be of like mind as the dozens of people working on the particular framework, assuming that all those minds were ever in perfect agreement. The only "perfect" fit is the one you write yourself, and even then you find it's not perfect as you are limited in time and effort on developing the framework; after all, you DO have a program to write, and the framework development time competes with the program development time.
As far as IDEs go, there's differences in taste and style. I tend to gravitate between the old standbys of Netbeans and Eclipse, and my next IDE to play with will be IntelliJ Idea. The thing to remember is that most people commit to one IDE and then defame the rest, so you really can't get a good comparison. IDEs take too much time to really learn for a person to give a honest unbiased opinion. A good candidate IDE "X" will be the worst in some eyes and be the best in others.
Given how the other answers look, I would say the biggest remaining factor is the learning curve for you and your team. Given your description of the separation of roles, your primary concern should be picking an overarching framework, such as Spring. From there, your database guys can pick whatever they want for data persistence (hibernate, jdbc, whatever) and your gui guys can pick whatever they want for their front-end (tapestry, jsf, etc.).
The primary concern I would have with such a distinct separation of roles would be the communication on the team. Make sure that their is a high degree of open communication, especially when discussing interface design, as those will be integral in the success or failure of your project (especially if you pick Spring).
As far as IDEs go, it's personal preference. The two mentioned in the other posts (Eclipse and IntelliJ) are the two I hear the most about, with Eclipse being my standard IDE for the last 4 or 5 years. I'm not familiar with IntelliJ, but I know that Eclipse has plug-ins to support Spring, Hibernate, and a host of other frameworks and ORM solutions. It also has plug-ins to support other languages as well, such as Ruby and PHP.
"I did even write my own mvc framework some time ago for fun" - at the end of the day it may happen that you will regret that you did not stay with it. In fact the technology that is better than currently "famous" most probably is the one that will be famous a little bit later, not now. Half of your list is already "famous" as obsolete.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I've just stumbled upon the following new java web framework: Play
http://www.playframework.org/
http://www.playframework.org/documentation/1.0/home
with such a stunning list of features, I'm pretty much surprised I haven't heard of it before...
Sounds like the java web development promised land...
has anybody tried it? any real experience with it? do you think it's worth studying it?
I agree with Jason that Play might just prove to be better than Grails. With four Grails projects under my belt (preceded by two Tapestry projects and one Wicket project), I'm seriously looking at Play next.
One of the things I thought was cool about Grails is that "everything's Groovy." That is, you use Groovy to write everything (except the HTML and the CSS) -- domains, controllers, services, page templates (GSP), tag libraries, Hibernate API (GORM), unit tests (GUnit), and build scripts (GANT). You can even write shell scripts in Groovy. So, being able to code all aspects of an app using a single language again seemed like a simplification that was long overdue -- hearkening back to the days of writing desktop apps in a single language like C++ or Delphi. However, I've learned that one size does not fit all here.
For one, the IDE support for Groovy isn't great. IntelliJ does the best job, but with Groovy being dynamic, it can only go so far. The refactoring tools do not (cannot) catch everything, so you can't trust them 100%. This means you have to be especially vigilant with unit testing. Here again, because Grails relies so much on dynamic "magic" that happens at runtime, the unit testing in Grails must rely on an extensive mocking layer to emulate it, and that mocking layer is quirky. A third issue is that much of the so-called Groovy code that you're writing is actually domain-specific-language (DSL) code. (To make a long story short, DSLs are short-hand Groovy, taking advantage of the fact that in Groovy and lot of the syntax is optional.) Grails uses different DSLs for various configurations, URL mapping, etc. and it is inconsistent. How you specify log4j settings, for example, looks nothing like how you specify the data sources, and neither looks like the pure Java upon which Groovy is based. So, the promise of "everything's Groovy" falls apart anyway.
That being the case, I see where the Play team is coming from.
Going back to regular Java for the domains, controllers, services, and JUnits makes sense. Strong typing means the IDE can reliably help with inteli-sense, code navigation, refactoring, etc. (And thus you don't need to pay for IntelliJ if you're happy with Eclipse.) Having to write more verbose code in order to gain back strong tool support seems like a good deal to me right now. We'll see.
I like that I still get to use Groovy in the page templates. I'm afraid I may end up putting more code in the templates than I should, though.
I have no experience with JPA, but it seems like it's pretty close to what GORM does for me, so that's cool.
The Spring IOC support in Grails is completely transparent whereas Play's support seems minimal; however, I think that IOC is way overused and I'm perfectly willing to hand code a Spring XML mapping on the rare occasion that I really need one. (One of my open questions is that I'm assuming that JPA has transaction support which is why Play doesn't need Spring for that like Grails does, no?)
I've never been a fan of Python, so I cringed when I read that Play uses Python for its build scripts. But I agree that Grails' GANT scripts run pretty slow. Plus I find that, while GANT is a huge improvement over XML ANT, it's still hard to wrap your head around the ANT concepts. The Grails GANT scripts are pretty convoluted. So, I'll go in to it with an open mind.
The Play "application module" model sounds to be just like Grails' "plugin" model, so that's cool.
I'm quite impressed with the Play documentation that I've read so far. I had a huge number of questions going in, but half of them were answered right off the bat.
I'll report back again later as I dive deeper in.
I've tried Play and I'm impressed: it does a great job of delivering a useful development model that is far simpler than most frameworks'. More than anything else, the runtime's ability in 'development mode' to parse .java files directly is worth a lot: just reloading the web page in the browser without running a build script or waiting for a redeployment is worth a lot of development speed. The error messages shown in the browser are really good too.
Another thing that impressed me was the overall aesthetic: it is perhaps a small thing that the tutorial application actually looks good (both the code and the web page design), but this extends to the whole framework, the API as well as the documentation.
After prodding from a colleague I looked at it, followed the tutorial, and got hooked. Getting immediate feedback right in your browser means you don't have to use an IDE. I love Eclipse, but let's face it: after you've added some extras, it's not as stable as a simple text editor. On a Mac with TextMate you can even click on the error message in your browser and TextMate pops up with the cursor on that line.
Testing in Play is also nicely done, with one button press you run unit tests, functional tests and Selenium-based tests.
Play is exciting because it's still small and uncomplicated. It uses just ant to build and does so in 25 seconds. Contributing to the beautiful documentation is a matter of editing the .textile files and reloading the docs in any play app.
That's how I wound up on a quest to translate the tutorial to use Scala, adding to the Scala support where needed to get it as nice as possible.
I like it, I'm using it for small projects and so far it looks perfect for the job.
However, there's one thing I miss very much that's been left out on purpose: Service/DAO/Model layers separation! Documentation says it clearly, one of the goals of Play is to avoid the "Anemic data model":
http://www.playframework.org/documentation/1.0.1/model
but in my experience the classical Service/DAO/Model layers separation saves tons of development time when the application needs to be refactored! With Play you're stuck with static methods that rely on Play-specific transaction management and peculiarities...
However, many thumbs up for: development speed, code cleanness, and in the end... fun!
I've used Grails, Tapestry 4/5 and straight Java/JSP/Spring/Hibernate.
I think this is going in the right direction for the first time in a long time. Grails was a really good first step but Play! looks like something that could really have legs. Scala support is coming in 1.1. If there is a chance I can write my controllers/domain in Clojure, I'm sold ;)
Since one year and no visible bug after 18 small releases, we use Play! 1.2.4 in a production "absences" intranet application for a school (actors: >100 teachers, > 700 students, administrativ team). Client side has been written with FLEX 4.6 from Adobe (very beautiful views). Data are send and receive in AMF3 format (Cinnamon module). We use a own simple dao layer based on JPA EclipseLink and MySql for the DB. Application is stored on a Linux virtual server. I'm a very fan developer of Play for its simplicity and its very productive approach.
I like the look of Play, but haven't tried it. From scanning through the docs one thing that stood out was the heavy use of static methods. From a unit testing point of view this always makes things much harder (I'm thinking mocks), and is a departure from the OO-everywhere approach in typical Java development. Maybe this is the point, but it's just something that made me a little less enthused...
I currently build web applications at work using play framework which does massive data processing. I must say that the speed that play offers alone is significant and more than what RoR can provide. Besides, play is a java based framework and hence Multi-Threading can be done easily. Next is the sheer performance you get when you use java-based modules like Japid and Netty along with play.It's like an endless amount of tweaking can be done for performance. A must try in my opinion.
I'm using Play in a small project, and seems to be exactly what they've said about. But one feature I think should to be present by default in the framework: ability to work with more than one datasource (e.g. use more than one database schema). This is the only missing feature I've found until now.
Regards,
Uilian.
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
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
This is half rant, half question.
Is it worth using Grails? I'm trying to develop a relatively simple database-driven web application. My expertise is in Java, so naturally Grails seemed like a good choice. At first I thought of using Spring, JPA and Hibernate, but I’ve used that previously and have run into all sorts of tedious configuration and coding work. Grails advertises itself as solving this.
My biggest frustration with Grails is all of the little things that don't work. What I mean is that it doesn't work as one would intuitively think it should. It's very rough around the edges. I run into problems constantly. Sometimes it's my lack of Grails understanding — other times I've discovered legitimate Grails bugs.
One major issue is the lack of good Eclipse integration. There is a Groovy and Grails plugin, but it doesn't do much other than syntax highlighting. Calling Groovy from Java and vice versa is very painful to configure. Not having good IDE support is a major bummer.
What happens is I sit down trying to develop my web application. At the end of the day I realize that I've spent about 85% of the day debugging Grails-related issues. If it isn't Eclipse problems then it's eager loading, fetching in the view, one-to-many relationships, weird empty file bug behavior, a weird property/getter bug — it just goes on and on. This is just a sample of the issues I ran into today. My last sit-down with Grails yielded a whole bunch of different issues.
I sometimes wonder if it's worth it. I'm curious if others have experienced this. Are there people actually using Grails to productively crank out a web application? Are there other frameworks for rapid web development that I should be considering?
We had a team of 12 people all seasoned senior Java devs who learnt Grails from 0.6B and we are all still working on projects based on Grails. I wouldn't go back to Java willingly, and we are all relieved to have broken the back of how to get somewhere quick with a Grails app.
It was a struggle, it was not easy and there was/is frustration.
Nevertheless we delivered something very quickly given our ongoing efforts.. There are bugs, many which have workarounds.
I have heard of several instances of developers who are good at Java trying to dive into deep, complex incantations of Grails projects. We eschewed all Java and went pure-Grails and Groovy. We made sure we started simple, built up the complexity as manageably and as practically as possible.. We dared not dive in the deepest end and hope that our Java knowledge was enough to carry us.
We had eventually created something huge and complex that worked fabulously and did so far faster than writing pure Java/Spring/Hibernate version; and thats without decent IDE support and a far worse situation in terms of bugs than today.
As regards Eclipse support, the only real IDE to use for Grails/Groovy is Intellij - the Eclipse support is way behind, sadly: I was an Eclipse lover and am far from being an Intellij convert - the Grails/Groovy support blow everything else away though.
Yes, Grails is immature compared to Spring perhaps. Or Hibernate. And I would wager that in the first 1.5 years of their existence they were equally as fraught with issue.
That being as it is, places the onus on you, to take care that you keep complexity to the absolute minimum, to carefully test-first (in our opinion) and build up to complexity gradually and with care.
There is no fast code solution with Java once you involve Spring/Hibernate in the stack. The complexity Grails embodies is a reflection of Spring's / Hibernate's own complexity. If you feel that you time is better spent doing it with pure Java, I wouldn't argue otherwise.. I still have my WTFs but now that the steep learning curve is behind me I think I will stick w Grails some more.
I very much enjoy writing grails application for two reasons:
I don't have to use Java
I can use Java
I think after having become familiar with grails one gets his things done very quickly and elegantly.
So much for the plus side. The minus side is performance, which hits me on two aspects: deployment and testdriven development.
I haven't managed to run more than 3 grails applications on a single (rented) server, because I quickly hit the memory and performance limits. There are simply too much frameworks included.
Plus, the testrunner of grails isn't worth that name. When I run unit tests, they should be done in an instant, not in 10 to 20s. So I find myself all the time writing business logic in plain java, because I can test it much faster. But I guess that this can be addressed with a better integration into the IDE (eclipse).
I think Spring's support of Grails is going to be a big boost. If anybody can move it past CRUD on the web, it's those guys.
I also think it's reaching a critical mass. There are several new books that will be hitting the market in 2009. I think those will help the adoption rate.
I fully agree with the original posters sentiments.
We are a Java + Spring shop and took the opportunity to try out Grails.
We first created a very small test application which turned out to be pretty simple to do and it worked pretty well. The main issues we had here were due to our lack of knowledge with Groovy and Grails.
Following this success (confidence boost) we decided we would attempt a slightly larger project. This has been a much more painful experience. As mentioned by others, we have uncovered all sorts of bugs and issues which were not immediately apparent on the surface. The app restart cycles get extremely painful and unless you have really good test coverage its a nightmare to do any sort of re-factoring.
Really frustrating is having code fail without a single error message! It just does not work and you don't know why?
I like the ease of use of plugins for JMS, Quartz and Remoting to name a few. Does away with a lot of tedious XML.
I almost like GORM for its simplicity though we have had several issues as well.
I don't like the loosely typed nature of Groovy and the fact that you have to run your application just to be able to catch a bunch of errors, reminds me too much of PHP or Rails.
At the end of the day we are asking ourselves if its possible to write a complex piece of manageable software using Grails...
We have a Grails application about to go into production....so we will see.
We are using grails + on the web layer + java with hibernate and spring on the service layer. It's the classic three layers (web, logic, data) where the web is grails and the logic is implemented in java. As is usual in java, we use bean objects that represents the data between different layers.
It works pretty well and it was the best solution for our case as the bean objects were already there, as well as the database structure. From our experience, I think grails has a great value as the web presentation layer, but I would stick with java to write the business rules and to persist the application data - as grails "is" java, all the grails-java integration is pretty straight-forward.
We use eclipse to develop the grails application and it's poor integration, as people said in here. But, as a suggestion from other developer, we run the grails application from the command-line and only use eclipse to save the source files, and it works pretty well, as the application is updated on the fly.
I yet don't feel comfortable for using grails in other places than in the presentation layer.
I have a lot more experience with Ruby on Rails than I do with anything in the Java world, so I'm coming in from a different perspective. Overall, Grails is much more rough-around-the-edges than Rails is, partially due to its immaturity, and partially because it relies on two insanely complex frameworks under-the-covers (Spring and Hibernate). Rails also has a much bigger community.
But, Groovy as a language has made huge strides, and is a pleasure to work with. Thanks to the improvements made in Groovy 1.6, Grails is quite a bit snappier than JRuby on Rails, and you get amazingly good XML support via GPath. There's a lot of nice features you get by being on the JVM (like concurrency and tons of threadsafe code), but without having to muck about with Java (a language I don't much care for), so I'm having a really hard time of convincing myself to use anything on MRI.
Python is looking tempting, though, I must admit.
As for your Eclipse problems, I can't help. I use Vim and Emacs, mostly because I can't stand using IDEs. For dynamic languages like Groovy, Ruby, and Python, though, I don't think IDEs really introduce any real benefit, as there isn't really any place for code generation, or a need to compile. Maybe try working sans IDE for awhile and see if things are smoother?
So, yeah, I think Grails is worth it. They've done a helluva job in getting things working as quickly as they have, and the Grails and Groovy teams are both really, really dedicated.
I am totally with you! Grails still feels so rough around the edges that it's almost a joke to compare it with Rails. If at least the error reporting was a little bit better. But I guess that's probably also due to the huge amount of libraries that it uses under the covers. One word: stacktrace! I am also not a big fan of the model->db approach (Rails has db->model). The scaffolding also leaves much room for improvements. Then "no restart required" also does not work as advertised. (I am not sure what's worse - having to restart all the time or sometimes finding weird behaviors that go away when you do restart) And don't get me started on GORM. (When it takes hours to find a way what would have been a simple SQL you start to wonder whether this whole ORM really saves you time) Maybe as long as it is simple.
I mean: it's still one of the better choices of a framework when you are coming from the java world. (So much useless crap out there that calls itself a web framework) ...it has potential. I just wish it wouldn't have build on top of so much other complex stuff.
Anyway - let's hope these things get sorted. At the moment I am lurking at playframework.org which also looks very slick and promising.
It will be worth it when they finish the eclipse plugin. The sooner the better I say. Trying to sell groovy to my boss isn't going to be simple until that happens.
I find that the biggest advantage of Grails is that I don't have to care about the database anymore - the schema is automatically created / updated, and the persistence is largely done for me (no more writing SQL queries). This is a huge relief. The other thing that is rather nice is that once you settled on the templates for controllers and views, adding new domain objects is pretty fast. Although I suspect that you will do ongoing changes for your views at least, back-fitting them to the existing ones.
As for the IDE - it seems that IntelliJ is the best option, but I'm happy using Netbeans 6.5. I use MyEclipse for all other development, but Netbeans just has better Grails support now.
I was an Eclipse user before I started using Grails. It was quickly apparent that wasn't going to cut it. So I tried Intellij and NetBeans. At the time Intellij was better as far as Groovy and Grails were concerned. However, NetBeans was free and that made it good enough for me. Since then all three have had new versions or new plugins released. I am still using NetBeans because of the cost of Intellij. With the acquisition of G2One by Spring Source one of the expectations is more support for Groovy and Grails in Eclipse. This will be necessary for increased adoption.
Using Grails for a new project is wonderful. So much of the Enterprise Java baggage is no longer necessary. I can imagine trying to port something would be difficult because until you understand where a framework strength's and weaknesses are it is hard to utilize it efficiently. It is promised that JSP support will come easier in Grails 1.1, I don't know if using a beta version while trying to grok a new framework is a good idea. The testing has also gone through a major revision for the new version. If time allows you may consider waiting as the 1.1 release should be very soon.
If you have an opportunity to give Grails a try in a different IDE when starting a project from scratch I think you will see it in a different light.
I have just started using grails on a new project...not having to write ANY xml files yet still have the power of Spring and Hibernate is truly amazing.
Use IntellijIDEA for the IDE though, I actually discovered Grails through the IDE (I might be biased though, I hate eclipse).
Totally. There are so many Java frameworks that the bar is set quite high for newcomers, and it's a testament to Grails that it was able to rise above in such a crowded space.
It still has a few edges that are sharp, but those are just a matter of time before they're matted down, the underlying project is VERY much worth it.
Grails might be to big for your type of application (based on the numerous files it created on the first initialization and the resources it takes). If you're looking for something simple, Grails might not be what you're looking for. If you are looking for something simple and works, so far I reckon django can do your job well. Take a look at how simple (how many files it requires) to create a CRUD apps from its tutorial. From here, your apps can (relatively) easy to scale as your needs and requirements grows.
I'm not sure they will ever be able to make Grails right you know. And by right I mean address all the details (small and big ones) which in the end makes it feel brittle and fragile. I'm not even sure that there is a real development team (meaning more than 2 people) behind it.
Every single time I iterate over a feature of my Grails projects, trying to improve something, it is the same workflow: everything falls apart, then it's a hundred of 'google' test cycles, then you find out the reason you can't do what you want and you do something else.
In the end, you're frustrated because you don't even want to touch anything that runs. And things that don't well, you drop them!
I'm considering a switch to Rails via JRuby. That may be the best of both worlds: a capable web framework with an active and large community, a dedicated team of developers, a platform which is not based on questionable and complex frameworks like Spring or Hibernate, a quick and ambitious release cycle. And JRuby because frankly, so many Java assets in my backpack, I can't just throw them away.
If your expertise is in Java as you say. You should have a look at Play Framework - it's a web framework inspired by Ruby on Rails with a very short development cycle - just save your Java source file and update your web browser. And if you want to try another language, Play Framework has a module that let you use Scala instead.
I like Play Framework since it's easy to understand and has good performance. You can also use JPA and Hibernate for the ORM-layer if you want.