

Another Java Disaster: Jobs - Garbage
http://www.jroller.com/robwilliams/entry/another_java_disaster_jobs

======
jbooth
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.

~~~
mberning
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.

~~~
jbooth
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.

~~~
mberning
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.

~~~
jbooth
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.

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

~~~
SoftwareMaven
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.

~~~
EdiX
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

~~~
SoftwareMaven
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.

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

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

~~~
superafroman
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.

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

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

~~~
arethuza
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....

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

