I need a stack that won't drive me crazy

[Bo Larson]

So I've been playing around with Java web development thinking that it would somehow save me from the hell of PHP. Unfortunately, things on the Java side seem to have become a giant mucky swamp of technologies and frameworks and containers and whatever else.

I've looked into things like JSF, Spring, GWT, and about a half dozen other projects and haven't found one yet that feels like it'll get out of my way and let me work on what I want to work on. Google Web Toolkit thus far has been very interesting and I love the feature set and overall simplicity, but the proprietary (perhaps not the right word) back end is driving me nuts. That is, trying to make it work on Glassfish in hosted mode is a mess, and getting it to play nicely across multiple projects isn't fun.

Basically all I've got is some simple databases and I'm doing some relatively basic CRUD operations in a corporate environment. This stuff won't be facing the public internet. I would, however, like to provide a UI that is modern and provides a good user experience. I would prefer to work with something that has good Eclipse support, but Netbeans is doable. I prefer not to spend a whole lot of time writing XML files and or having to rely on naming conventions to make sure the code will run. (I'm definately one of those guys who needs his tools to help him remember what the hell he's doing.) I would also like some automation for database operations - that is, some kind of persistence and entity generation tools etc.

Right now I've got some headless EJBs (3.0) running in Glassfish, but frankly I could probably start over. (JPA can be used without a J2EE container, right?) I'm a little more comfortable with Tomcat 5.5, actually.

So there it is, can somebody recommend a pathway to developing simple, maintainable applications?

Sorry if this is the wrong forum.

[Sachin Kumar]

Yes, you are right J2EE is a forest and you you have to look , what suits you.

I guess JSF with Ajax kind of will be good for you. (Haven't tried Google Tool Kit)
Server Side is some thing I spent many years .. my suggestion is go with
(Spring +Hibernate)
Can go with JPA with annotaion to get rid of xmls but it needs little understanding while debuging and doing some relation tasks.
I can say java is still not rich in view front but integration is marvellous in this world.

Hope JavaFx and Flex Api with GWT can do some good in this.

[Bo Larson]

Thank you.

I'm not so sure about JSF -- I certainly don't like the markup and frankly it just feels like there's a lot of code and meta junk to generate just to perform a relatively simple operation. Not to mention that there is still a lot of reliance on naming convention and string parsing for flow, etc, for which the tools I'm currently using don't help much with.

The hard thing here is that learning JSF requires a pretty good amount of time and effort that, in my case, might be wasted if there is something simpler for building the UI. Yet I'm also wasting time by trying out simpler tools like GWT that turn out to complicate the back end.

I worry that I'll put a lot of effort into JSF only to reach a point where I'm efficient with a technology that is a chore to work with. Back to square one in a way. Thoughts?

[Bear Bibeault]

In my opinion, JSF is an abomination that should never have left the drawing board.

And I'm not a big fan of Rube Goldberg frameworks that try to be everything to everybody.

So I set up a simple Front Controller implementation (Front Man), and do everything else pretty simply using Servlets. JSP, JSTL/EL and Ajax (via jQuery).

On the server I sometimes use Hibernate.
[ November 25, 2008: Message edited by: Bear Bibeault ]

[Bo Larson]

Well it's nice to have someone actually confirm that for me. I went through a couple JSF tutorials and really just felt like it wasn't something I wanted to do.

I noticed your links and looked at your Front Man framework. It might be the simplicity I'm looking for.

However, I think I'm going to give GWT another go... but this time do it within the narrow margins they provide. The idea of writing a web application in much the same way that I'd write a traditional GUI is very appealing. I do really want to use JPA with it, because I don't want to write DAOs by hand. I know there are some technical details that make this challenging.

[Pat Farrell]

Originally posted by Bo Larson:
EJBs J2EE

Run away from traditional J2EE.
See my thread of "do I need a framework"
https://coderanch.com/t/420860/oa/Frameworks-Do-one-want-one
[ November 25, 2008: Message edited by: Pat Farrell ]

[Ulf Dittmer]

Run away from traditional J2EE.

I suspect this should read "traditional EJB", meaning EJB 1.x/2.x. EJB 3 is very different, as was pointed out in that other tread.

J2EE/JEE is big area that also covers servlets/JSP, JMS, JavaMail and various and sundry other technologies. I don't imagine Pat advocates not using any of those.

[Bo Larson]

Thanks everyone. I read the thread that Pat linked to and I believe that my problem stems from not really having a problem. I want to use what I'm "supposed" to use, but really I'm just looking for something to help deal with two things: persistence and the UI. The in-between stuff I'd like to be as close to "just java" as possible... and this shouldn't be an issue since my projects really are small. I'm thinking too big instead of just getting to work.

I'm settling on GWT for the time being because it looks sorta fun and I like the idea of developing an application in a browser rather than a bunch of web pages and forms clobbered together and called an application. In my case I don't need web sites, I need applications that are accessible. I'll likely use Eclipselink(Toplink?) for persistence because I already have it setup so what the hey. But I swear, if there are too many instances of something not working and having no clear indication of why it's not working, I'll just use plain old JDBC.

I must say that it is nice to see published, experienced Java developers being pragmatic about frameworks instead of just recommending a favorite to everyone. I feel like I wasted a fair amount of time trying to wade through all of these frameworks and whatnot only to realize that most of them weren't for me because they don't solve a problem I'm currently having. It's hard not to run with the herd and it's good to hear someone in-the-know say "you don't really need all that stuff right now." This is a good forum.

[Ulf Dittmer]

I think it may boil down to the difference between "the problems you have" and "the problems you have that are so bad that you like to have them addressed by code other than the one you have to write yourself". If the apps you work on are fairly small, none of the areas addressed by the common frameworks may be significant enough for you to get tired of coding them yourself. But the issues themselves arise in just about each web app: flow control using MVC, form parameter to Java variable binding, validation of form parameters and automatic recreation of forms with faulty values and appropriate error messages, easy display of I18N text etc. If none of these strikes you as a problem in the apps you work on, lucky you :-)

[Pat Farrell]

Originally posted by Bo Larson:
I'm just looking for something to help deal with two things: persistence and the UI.

Persistence is a constant problem. Hibernate appeals to me, as its fairly lightweight. But as long as we insist on using relational databases with Object oriented languages, there is a serious impedance mismatch, and its not going to go away.

After writing assorted ORM things for 20+ years, in C++, Smalltalk, Java, and probably a few others, I believe that there is no universal solution. When you look at serious scaling, you find at least two universal characteristics: (1) you denormalize for performance and (2) to get serious, you use memcached or something similar.

Even with lighter stuff, you end up having to figure out what is important when you "save" a compound object that maps into six or ten tables. So far, the only way to solve that one is to get a really good DBA and get serious. So it stops being a framework issue, its really "what is important" and no one knows that in advance.

Making a "good enough" UI is fairly easy, you can do it tons of ways, its not worth a lot of religious arguments about which UI technology is "optimal". But when you want current state of the art UI, which changes with the state of the art, its a lot more complex. Doing a great UI is really hard work by a team of very talented folks.