How to improve productivity when developing JEE based web applications?

I believe the JEE Java stack is actually very good. There are a few reasons explaining the low productivity of JEE.

I believe the JEE Java stack is actually very good. There are a few reasons explaining the low productivity of JEE: 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. JEE 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 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 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 JEE 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.

You just stole my words. Incredible answer. – Fernando Miguélez Mar 24 '09 at 15:54 Thank you for sharing your experience!

– Nils Wloka Mar 24 '09 at 21:42 1 Tapestry is unacceptable for enterprise use, unless you are a committer. It might be nice, it also has an unacceptable policy w.r.t. Maintaining current stable versions.At the switch from 4 to 5 there was no bug harvesting for 4 and no stable 5 for a long time.

– Stephan Eggermont Jun 26 '09 at 7:23 2 I disagree upon the "do not use standards, but the best tool for the job". Your code may live for a VERY long time, which may be a LOT longer than the "best tool of today", so your employer may end up in 10-20 years time having to maintain your code written in a toolkit/language which is completely unknown to everybody else. Proof-of-concept: Visual Basical stopped to be backwards compatible with version 6.

This means that those applications are stuck in a timebubble, but may still be important applications. Standard based projects tend to live longer and have multiple implementations. – Thorbjørn Ravn Andersen Jul 10 '09 at 10:55 1 "Code generation is bad" : you're totally wrong on this.

Most of the code in a JEE app is boring, repetitive, boilerplate code. You have to generate it to be more productive: you generate the boring part, that lets you spend your time on the real problem your app try to solve. Actually this is what frameworks like Django and Ruby on Rails do.

I agree that UML can't be use as a programming language and that makind sequence diagrams is bad: this this slower than coding. Also modeling does not mean graphical: see tools like xtext for example. I see modeling as a way to quickly create dsl.

– Alain Michel Oct 29 '09 at 18:19.

Frameworks like Spring, 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 JEE productivity: you should be using J2EE 5 and EJB3. X since they provide for new level of productivity (and functionality) compared to previous releases. Staying within standard J2EE specs is absolutely important, e.g. Using bernate instead of JPA is not beneficial to productivity.

There is no limitation to fall back to bernate features when using JPA, but by using bernate 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). J2EE 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 JEE 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.

Being "locked into a single persistence provider" sounds scary - but in reality a reasonably sized project is not going to switch persistence providers. Therefore using JPA as well as bernate just adds more abstraction and confusion and will hinder productivity. – Daniel Alexiuc Mar 23 '09 at 2:17 I don't agree.

Rejecting persistence API will hinder productivity in any JEE application except rare cases: no need in persistence operations in Java, all stored procedures approach, batch jobs only, etc. Before JPA came around I was against using entity EJBs but not anymore... – topchef Mar 23 '09 at 4:12.

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 JEE. 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 URL2 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. Ghly 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. IBatis or another ORM framework can help. With bernate 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.

Of course I agree with the notion of using frameworks. Still, you have a lot of structural redundancy in your average JEE web application. Regarding "easy databases": I've seen many a project coming to a sudden stop when the hidden complexity of ORM tools surfaced due to corner cases or misuse.

– Nils Wloka Mar 21 '09 at 0:20 Just to clarify. Scala is not dynamically typed like the rest of the listed languages. – Daniel W Apr 2 '09 at 7:24 You are right.

I should have said "functional programming oriented" languages. – kgiannakakis Apr 2 '09 at 7:50.

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, 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...

I would definitely go for Spring together with bernate 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.

The same holds true for JRuby on Rails. Alas, I might be in a situation where a huge investment in Java (skillwise) exists. Groovy might, due to syntactic and partial idiomatic similarity, work.

Python would probably be rejected. Out of curiosity: Is Jython 2.2 considered production quality? – Nils Wloka Mar 21 '09 at 17:34 I recommended django since it's not another rails clone and it's better suited for "enterprise" stuff than rails/grails.

Jython 2.2 is stable so is 2.5 (it's getting out of the last beta). I don't see why anyone would use 2.2, the language has come a long way since. – Vasil Mar 21 '09 at 18:05.

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 which was meant to emulate Rails. Having seen both, I feel Rails is a lot easier to develop with.

This sounds very tempting, considering how far JRuby has come. Seamless usage of Cucumber/RSpec sounds tempting as well, but I'm afraid JRuby will not meet the "Java or less exotic JVM-language" criterion. Out of curiosity: Can you share details about the JSP-Rails-Integration?

– Nils Wloka Mar 23 '09 at 23:00 I can't go into too much details because it's for my job, but we did things like create a jsp helper to load a jsp, using a mock response I created... the helper will take variables that will be stored in the request which the jsp can then reference. – Mike Stone Mar 24 '09 at 17:46 Our view template automatically calls the header and footer, and we have a before filter that will check the session to ensure the user is properly logged in (all 3 of those using the jsp helper to invoke existing code for almost no duplicated logic). – Mike Stone Mar 24 '09 at 17:47 We can even use a jsp tag that came with JRuby Rack to embed some Ruby partials into an existing jsp page.

One note that bit us... Rack or some other tool was converting session Integers to Longs... but a simple JSP filter resolved it by watching variables and converting them back when changed. – Mike Stone Mar 24 '09 at 17:54.

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, 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.

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!

Do you have any real life experience with either Scala or liftweb in an enterprise environment (i.e. Customers usually being risk averse late adopters)? While I find Scala beautiful and liftweb promising, I'm not sure either one is yet ready for production use yet.

– Nils Wloka Mar 22 '09 at 19:52 Scala is definitely ready. The reason is that it just piggybacked on suns jvm which is stable. It is not that hard to compile down to it.

I have used Scala in small interweb projects. I have some doubts about Lift, albeit small. Innovationgames.Com Wish I could help you more.

– Daniel W Mar 26 '09 at 8:07.

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 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/JEE, we could compare the estimates in both.

Also see this blog post: http://blog.atomikos.com/?p=87 HTH Guy.

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?

1 JSF isn't so bad. Sure it is a bit ugly in places but when you use it with Facelets and a framework like Seam it's actually very handy. – Damo Mar 23 '09 at 11:45.

I cant really gove you an answer,but what I can give you is a way to a solution, that is you have to find the anglde that you relate to or peaks your interest. A good paper is one that people get drawn into because it reaches them ln some way.As for me WW11 to me, I think of the holocaust and the effect it had on the survivors, their families and those who stood by and did nothing until it was too late.