Solution: Don't use SEAM or the frameworkey aspects of Spring.

It's so easy to embed a Jetty web server in Java and just solve your problem from the basics, I'm always astonished at the work that goes into getting these frameworks to do the job for you.

This is pretty much why I switched my career from Java development to Ruby and Rails.

Java is a fine language and I still enjoy programming in it. The problem is that a large portion of the professional community is very obsessed with these huge frameworks, libraries, and convoluted design patterns. I often faced a lot of opposition trying to simplify our Java platform at my previous job. In the end we were able to completely replace jboss with a simple tomcat instance, which is vastly simpler and much quicker/easier to develop with.

Just the word "factory" sends chills down my spine.

I think it may have even influenced my decision to use Machinist instead of factory_girl as my fixture replacement in Rails.

Rails has a lot of the same frameworkiness. If you're writing a big webapp, Ruby's a more appropriate language (Integer.parseInt(request.getParameter("id")) isn't exactly beautiful), but Rails is just as much a framework as SEAM is, up to and including the sort of problem the author complains about. It's just a better one for many applications.

I agree, but I find rails to be very pragmatic. Of course it's no silver bullet, but for many of the projects I've worked on in the past it was a good fit. I feel like it is pretty low friction and has a moderate learning curve as compared with more 'enterprise' frameworks.

Yeah, for sure, I've done very little Rails so I'm not speaking from experience but it seemed that for the variety of problem the author was facing (have to solve a problem "the framework way" for something that should be simple), rails is susceptible as well -- it's just a better set of design choices for the web so it doesn't fall down as often.

After using Akka and Scala I cringe at the thought of going back to use Java, even for simple dimple projects.

As one commenter already put it, so much of Java frameworks are overly engineered. Which begs the question as to why do so many implementations at so many corp situations I've been in have developers under engineering usage...

I take it business probably sees over engineered goods as "less work" for developers to code. This perhaps allows the hiring of "lesser qualified" engineers...hm...

The excuse I've heard is it "let's people who are specialists do the 'hard' stuff." you know, like reading a configuration file...

There are some cases this makes sense for (scientific computing, machine learning, etc), but I think nirvana in the community is being able to write an app via XML configuration files.

I find it ironic that programmers that would be otherwise extremely averse to dynamic typing are willing to write so much code in the form of a dynamically typed XML mess that is interpreted at runtime

And how afraid people are to type "new XXX()" in their code. A dependency is a dependency, and I'd rather have it in the source code, myself, than in some configuration file held outside the source.

In fact, it seems downright dangerous, because it encourages changing implementation directly on a production system rather than forcing changes through a change-management process.

I wouldn't say Java is full or wrappers but the java ecosystem/community is full of them. Everybody has freakN something with a little twist. It's too much!

Agree on the Quartz though. Oracle uses it for all the scheduling within it's all the applications. It has some jdbc connection leakage that Oracle wouldn't fix and it will require restart of your app almost every week.

The API might make HNers cringe but quartz is a tried and tested scheduler that we've used in production for six years without any issues.

Relaible software that you don't have to maintain is really valuable.

Totally agree with this. I've used Quartz on and off for about 5 years and I've always been able to get it doing what I want relatively easily.

Sounds like Java development, all right. I think the problem lies with the idea that learning an uber-framework is a one-time cost. "Just learn it, you will be more productive aftwerward", they say. But that never happens. In reality, you keep working with new problems, which require new tools, which mean you're learning this stuff all the time. If the tools are complex, you're paying a high "tax" in term of your time and productivity.

Java is a fine language, but the community suffers from rampant over-engineering and frameworkitis. There's this belief that frameworks save time by saving you from writing code, but in the end the amount of time you have to spend learning and applying the confusing bloated over-engineered framework exceeds the time it would have taken to just write the damn thing yourself.

But, they say, if it's written with frameworks then it's written in a "standard" way. You don't want to sift through a bunch of "cowboy code!"

I have never seen this work in practice. Framework spaghetti is every bit as opaque as badly written uncommented crap code. At least the latter tends to be concentrated in one place, rather than shotgun-scattered all over a bunch of weird .XML configuration files and different projects all over the place.

I routinely find myself asking: "what problem does this solve?"

"But it's enterprise!"

Edit: just remembered the best term for what afflicts the Java community: architecture astronautism.

I remember seeing a possible explanation for this behavior on Joel on Software a few years back - Java seems to be particularly popular in environments where the design is handed down to developers as a finished spec, so the only outlet people have for any kind of creative expression is in the structure of the application rather than in what the application is actually doing.

Not that this excuses the mad world of enterprise Java applications....

I agree with your points on frameworks. I deplore the over-use and reliance on huge swathes of code to accomplish what is a simple task in vanilla code (want to select a div in js? use jquery - come on!) But this is not an affliction limited to Java.

You right stranger, but whartarewegonnadeuh? What do you think of avoiding frameworks and just going with the servlet spec?

I'm not kidding here. I got fed up with Java about 5 years ago and taught myself Rails and Ruby, but I kept programming in Java largely because of work requirements. Every time I got to write nice, clean POJOs, life was pretty good, and I felt productive and enjoyed coding for long stretches. Every time I was deep in frameworks (spring, struts, hibernate, etc), I felt like checking email or HM or just going home.

I like Rails, but even then I find myself fighting with the framework eventually. I'd say with Rails, the trade-off is easier to stomach - I get so much out of Rails that I'm not as unhappy when I have to figure out how rails does something. With Java, I'm even more tempted to just use the lowest level I possibly can, in the belief that the up-front cost to productivity will be offset when I need to do something that isn't easy with the existing frameworks. Another factor in all this is mental space. I can keep the core language in my head, but I can't possibly keep all the frameworkish stuff in there, and in Java, even if you find an article on using spring to do something, the example never works (strangely, in Rails, it usually does).

The problem is... I still do need these things in Java as well. It does feel a little dumb to write my own MVC framework. I like auto-generating the dev database from annotations. I don't like Spring, but Dependency Injection actually is pretty damn useful for swapping out different implementations of a constant interface. I could go with something else, I guess...

This is a tough one, and it's typical of complexity creep. Each individual decision makes sense, but after a thousand little tiny pieces of complexity are added, you step back and realize you have a monster on your hands.

I can't help thinking that design patterns are often used as an excuse to avoid documenting the API.

Extreme programmers are bad enough, but at least they encourage things like minimal interfaces, test suites, and pair-programming to stop the API becoming unreadable.

The bare Java is not very fine as I see after comparing it with more concise languages, like Clojure.

The enterprise Java conventions are even worse, like a convention for mandatory getters/ setter.

Good framework in a good language can save a lot of work even for a big complex application.

This is a problem of too much abstraction.

I can only say just use the parts you like and ignore the rest. I lived through EJB 1.0. Spring and Hibernate are massive improvements compared to that and the community and software parts will continue to evolve.

BTW, I would like to point out that design patterns are just syntactical/mental constructs for programmers to do something in a less expressive programming language. For example, the Visitor pattern makes very little sense if you have functions as first-class values, i.e. closures. Same for the pub-sub pattern if you have used a programming language which support dataflow variables.