Simplest way to develop web applications in Java?

[Ido.Yehieli]

Java EE seems to be mind-numbingly complex, is there a simpler way to
develop web applications with java?

What would be the advantage of a full fledged Java EE framework
compared to a more lightweight solution (for instance: tomcat
(JSP+servlets) + hibernate (persistency))?

What would be your choice for the best/simplest way to do it?

Thanks in advance,
Ido.

 

[David Segall]

Java EE seems to be mind-numbingly complex, is there a simpler way to
develop web applications with java?

What would be the advantage of a full fledged Java EE framework
compared to a more lightweight solution (for instance: tomcat
(JSP+servlets) + hibernate (persistency))?

What would be your choice for the best/simplest way to do it?

For simplest, but not necessarily best, I would go for Java Studio
Creator <http://developers.sun.com/prodtech/javatools/jscreator>.
Java Studio Creator is being reincarnated as the Visual Web Pack for
NetBeans <www.netbeans.org> so if you want a single Java IDE you may
prefer NetBeans.

 

[Daniel Dyer]

Java EE seems to be mind-numbingly complex, is there a simpler way to
develop web applications with java?

What would be the advantage of a full fledged Java EE framework
compared to a more lightweight solution (for instance: tomcat
(JSP+servlets) + hibernate (persistency))?

JSP and servlets are parts of JavaEE. Hibernate also provides an
implementation of the Java Persistence API (JPA), which is part of Java EE
5.0. So I guess you are talking about avoiding EJB? Rod Johnson's book
"J2EE Development without EJB" may be of interest. The key piece of
advice is unless you *really* need distributed business objects, do not
use EJB. You can still use all the other EE stuff like servlets,
messaging (JMS) and transactions without having to write EJBs. Most web
applications don't need EJB and the complexity it brings (particularly
prior to EJB 3.0) is best avoided where possible.

Dan.

 

[Ido.Yehieli]

So I guess you are talking about avoiding EJB?

Mostly, yes. I also want to avoid the huge amount of (often repetetive)
xml text that seems to be a part of every j2ee web app. i understand I
can do a lot of it with annotations now, which I will also like to look
into.

Can you think of a better approach then tomcat + hibernate like I
suggested?

Thanks in advance,
Ido.

 

[Daniel Dyer]

Mostly, yes. I also want to avoid the huge amount of (often repetetive)
xml text that seems to be a part of every j2ee web app. i understand I
can do a lot of it with annotations now, which I will also like to look
into.

Personally, I strongly dislike EJB. However, if it were possible to
rescue the situation, I think they may have achieved it with EJB 3.0.
Much of the XML cruft and all of the Home and Remote junk has disappeared
(or at least is hidden from you). EJB 3.0 entity beans are almost a joy
to use (well, in comparison to EJB 2.1 at least). The annotations,
borrowing much from Hibernate, make the ORM simple. The inheritance
restrictions are gone too.

Can you think of a better approach then tomcat + hibernate like I
suggested?

No idea what your requirements are but, if you just have web pages that
read and write to a database back-end, then Tomcat + some web framework
+ POJOs for business objects + Hibernate for ORM is probably sufficient.
Keep things as simple as you can. There are dozens of web frameworks to
choose from. Struts is mature and widely used. I've also heard good
things about Wicket but haven't used it myself.

Dan.

 

[Lew]

... There are dozens of web
frameworks to choose from. Struts is mature and widely used.

Mature is one word for it.

Struts does a great job of automating the controller and navigation logic for
Web applications, but some of its older libraries overlap functionality of
newer standards like JSP EL, JSTL and JSF. The Struts project has done a great
job of moving with the changes in its most recent incarnations; its web site
is chock-a-block with advice on how to use these standards in conjunction with
Struts.

Many people ignore this advice and use Struts libraries instead. There are
also ways to use the core Struts framework to engender horrid complexity
should one choose to do so. One could argue that any web app should have
sufficiently straightforward navigation requirements that Struts action
classes need not each dispatch to a zillion different processing stages, but
then some seem to disagree. Struts is flexible enough to satisfy the most
twisted spaghetti-logic addict.

I suggest using Struts in its leanest pure form, expecially its most recent
incarnation, preferring the newer standards to the older non-core Struts
libraries.

One could also write one's own controller servlet and simple "action" handler
layer. It's not a whole lot of work for most straightforward applications, but
it will help you appreciate Struts's value and how best to use it.

Going back to the original point about developing in the "simplest way": if
you ever think you need to "disable" the browser back button or refresh, you
have seriously lost your path. Make your transactions idempotent and don't
every try to change browser buttons. The misguided attempt to suppress
browser navigation idioms introduces amazing difficulties and astounding
schedule slippage to your projects.

The larger principle is that no framework or technology mix will protect you
from having to do correct analysis and modeling, or against the consequences
if you don't. Achieving the "simplest way to develop" depends on an
architectural approach and mindset more than on your tools.

- Lew

 

[rxreyn3]

The Spring framework is ideal for the solution you are looking for.

http://en.wikipedia.org/wiki/Spring_Framework_(Java)

Ryan

 

[Simon Brooke]

Many, most of them good.

None whatever. You want to read this book here:

http://www.oreilly.com/catalog/bfljava/

It contains a great deal of common sense.

Someone else has recommended Spring; I'd also suggest you look at Struts.