Discussion:
Everything That's Wrong With Java in a Single Class
mrosgood
13 years ago
Permalink
The object of derision:

http://static.springsource.org/spring/docs/2.5.x/api/org/springframework/aop/framework/AbstractSingletonProxyFactoryBean.html

The kibitz:

https://plus.google.com/105201233571140699617/posts/1QhcnQizuPc

I make this joke ad nauseum. I start with a bunch jargon, add -able suffixes, string them together into a run-on sentence of almost plausible jibberish, and top it all off with an "Impl" capstone suffix.

Not because it's funny (to anyone other than me). But to vocally and repeatedly mock bad behavior.

It's not just long names. There's also wrappers, proxies, helpers, delegates, annotations, data objects, views, etc, etc.

So much redundancy!

This isn't a Java thing. There's nothing about Java that forces senior architects, business analysts, data managers, language pundits, or shocktrooper consultants to keep renewing this endless stream of crap.

Though I'd agree that it's the culture of Java community / users thing.

I mostly blame XML and design patterns. Which hit about the same time as Java. (The trifecta for the nascent subindustry of enterprise solutions architects.)

XML is always incorrect. That spring and maven use XML means they are also incorrect. Incorrect by association.

Also, the notion of indirection and lazy initialization, lazy design, lazy decision making comes directly from design pattern's functional programming envy. (The book even says so.)

On the design pattern mania, I'm just as guilty as anyone else. I started the Wing Ding so that we geeks could study the first Design Patterns book. We chewed thru that book 3 or 4 times. Always in need of another fix, and excuses to argue, we fixated on every new patterns book we could find.

I was never one to make an abstract factory service registry for every single domain object or action. But not every one is as discerning, wise, and humble as me. (ahem)

During the third iteration of the Design Patterns book, I finally figured out it was either stupid obvious stuff (eg prefer composition) or stuff you shouldn't do until you absolutely had to (factories). However, it is my observation that all layers of crap get laid down before even a single functional requirement is fulfilled.

Peddling Design Patterns, XP, and Agile swag and seminars to all comers was less wise than giving free amphetamines to school children. Though probably just as profitable. Grenades and flamethrowers would have done less damage.


Cheers, Jason



------------------------------------
Eric Jain
13 years ago
Permalink
Post by mrosgood
During the third iteration of the Design Patterns book, I finally figured out it was either stupid obvious stuff (eg prefer composition) or stuff you shouldn't do until you absolutely had to (factories).
Even for the obvious stuff, it's useful to have established names for
things like "factories" and "singletons".

I'm not sure what it is about Java (or people who use Java?) that
encourages creating indirections prematurely--especially since Java is
more refactorable than most languages...


--
Eric Jain
CEO & Founder
zenobase.com


------------------------------------
Stan Dyck
13 years ago
Permalink
...
There's an intriguing theory (no opinion on whether it's true or not) in traffic engineering that removing signs and
curbs and lane markings actually improves traffic safety [1]. Hans Monderman is the pioneer of this I think. The theory
being that signs and such are crutches that provide us licence to pay less attention. Perhaps Java's problem is
something akin to this. If Java were less refactorable it would force people to be more circumspect in creating their
abstractions because if they weren't they'd be stuck with a big mess that they couldn't fix.


[1] http://www.csmonitor.com/Environment/Bright-Green/2008/0625/do-traffic-laws-cause-accidents



------------------------------------
Konstantin Ignatyev
13 years ago
Permalink
Well, IMO that is caused by the fact that most today's managers grew up
when refactoring was hard, so the old school way of dealing with change was
to create boat-load of interfaces and factories just in case they would
need to change something someday, and then add factories of factories for
the good measure. And those folks do not code any more and they missed
reading about refactoring.

Also refactoring usually means changing "significant" amount of code across
many classes, which immediately causes alarm to go off because "big" change
could cause problems.
...
--
Konstantin Ignatyev

PS: If this is a typical day on planet earth, humans will add fifteen
million tons of carbon to the atmosphere, destroy 115 square miles of
tropical rainforest, create seventy-two miles of desert, eliminate between
forty to one hundred species, erode seventy-one million tons of topsoil,
add 2,700 tons of CFCs to the stratosphere, and increase their population
by 263,000

Bowers, C.A. The Culture of Denial: Why the Environmental Movement Needs a
Strategy for Reforming Universities and Public Schools. New York: State
University of New York Press, 1997: (4) (5) (p.206)
Joe Bowbeer
13 years ago
Permalink
The name, though long, follows a standard order and employs standard terms.

One's feeling about this class may be closely aligned to one's feeling
about proxies. (What say you, George?)

Can anyone fine any instances of it or instances created by it?

Here's a talk by its author Juergen Hoeller about "The Challenges of Long
Term Software Quality in Open Source":

http://www.springsource.org/node/2720
http://blog.springsource.org/author/juergenh/

--Joe
...
Eelco Hillenius
13 years ago
Permalink
I'm not a fan of Spring's fat layering either. I prefer a little more
hand coding myself, and I like a framework like Guice because it is
pretty minimal (and elegant imho) itself, and also encourages that
coding style.

As for bloat in my day-to-day experience... I think I see more of that
due to people staying too much within the boundaries of the specs they
build for (which often aren't very abstracted either) than that I see
framework code that is over the top. I've definitively had to learn
(still am actually) to find a balance between over- and under-doing
design, but I'll take a well-thought-out design with a little bit of
fluff you don't end up needing, over chunks of code where someone
worked his/ her way linearly through the specs with the code an almost
direct translation of it. Code like that tends to be brittle and
repeated in slightly different variations all over the place. And yes,
refactoring is good, I do it all the time to my own code, but there
too, refactoring a well designed system is much easier to do.

Now as for Java having a bad rep for bloat... true for Spring.
Certainly true for parts of JEE and some of the JSRs. But there's
plenty of examples that show you the opposite, like these we had a
presentation on this week: dropwizard and metrics. Very to-the-point
frameworks (ironically heard some questions from people in this thread
in the "can't it do this or that..." fashion), elegant, abstracted,
but not over-the-top so. And like the presenter recommended, take a
look at Jackson or Jersey, two of my other favorite frameworks, for
code that's very well abstracted, yet not overly so, fast in
execution, flexible in use, etc etc.

Eelco
...
------------------------------------
George Smith
13 years ago
Permalink
Is Java "Too" Bloated?

IMO, most languages (not their libraries) are actually rather "clean" (APL,
Cobol, & PL/I excepted).

However, when you look at the bundled libraries, "warts" can be found in
all languages. When you have a popular language with lots of 3rd party
libraries or frameworks, then there will always be some library or
framework out there that someone will find is the "worst code they have
ever seen"!

For example, when I was at Google, I found some code that it was
recommended that I use, Eclipse told me that there was an unhandled
exception on the method (while many of you know I am not a fan of checked
exceptions, they are used, so I "get over it"). Since I couldn't
understand why this relatively (in threory) simple code should need to
throw a checked exception, I jumped to the method. What did I find? The
method threw "Throwable"! Talk about "forcing" bad practices!

One of my favorite quotes:

“*There is not now, nor has there ever been, nor will there ever be,
any programming
language in which it is the least bit difficult to write bad code.* ”
- Flon's Law

Now, given the above, "Spring", IMO, is a good example of a "Framework"
that is bloated and most of the time an actual productivity
"anti-pattern"! I have lived with it at two companies, and it provided the
following valuable capabilities:

1) Dependency Injection - A useful technique that IMO should be used
"sparingly". So sparingly, that spinning up your on simple "Context"
object is usually quite easy.

2) Automatic Form to parameter mapping - Sounds useful, until you realize
how much "magic" is needed to generate appropriate localized error messages
when the mapping fails. IMO a good home grown Form validator w/ registered
field validators is clearer to maintain.

3) Delegating Servlet framework - Not that hard to produce a simple
replacement.

4) Security - Worked nicely, but it took 3 man-days to get it working! I
don't have a good "replacement" story here!

5) Hibernate Session Management - I spun up a Dynamic Proxy based Interface
wrapping replacement in 4 hours. When it was later decided to increase
performance be eliminating Hibernate and using strait JDBC for the Web
Services, I simply "dropped" the "Proxy" from my DI "Context".

Does the above mean that Spring shouldn't be used? Of course not! But
shouldn't Spring (or for that matter any and all 3rd party libraries /
frameworks) actually have to deliver positive ROI?

George
...
--
"And the users exclaimed with a laugh and a taunt: It's just what we
asked for but not what we want." -- Unknown
Konstantin Ignatyev
13 years ago
Permalink
Post by Eelco Hillenius
Post by Eelco Hillenius
Now as for Java having a bad rep for bloat... true for Spring.
So, in the nutshell we now complain that Spring/Java already have
implementation for all the typical problems and therefore one does not need
to reinvent the wheel.

C'mon - lets not blame Spring or Java for bloat, they are pretty modular,
nobody forces you to use every piece of what is available.

I think it is we developers deserve blame for bloated solutions, in large
part I blame uneducated developers for reinventing wheels all the frigging
time time without bothering to check what is available or checking but
immediately dismissing on the ground of 'bloat' without faintest attempt to
understand reasons for complexity.

Yes, Spring, Java, <you name the library of framework> solutions might be
not ideal for all the situations, but statistically speaking they are
better than average team can deliver in 99% cases.

For the next 0.5% cases solution delivered is actually better than provided
by <solution X>, but all the advantages wiped out and turned into
disadvantages as soon as original developers/drivers move on and the wave
of maintainers/enhancers now misunderstand and misuse the good solution.

George's email is good illustration: Spring provides solutions, and it
might be easy to reinvent that wheel, but why?

I think that IT as a whole need to be beaten with a good big stick to be
more humble and study preexisting body of knowledge. I suggest that it
needs to be mandatory to provide answers to 5 questions for any moderate
project in the format like this:
- I have need to do:.....
- I have tried the following 3 solutions for my needs:.....
- Those solutions are not satisfactory because:....<detailed explanation
here>
- I cannot contribute and modify any of those solutions because:....
- Therefore I need to implement solution that will be different from 3
above-mentioned solutions in this way:.... describe what will be different

Usually when we do it this way the #5 contains long list of assumptions and
corner cuttings that it makes it obvious that either we can and should use
one of 3 explored solutions, or that problem/need was not understood
properly initially.

Sincerely,

Konstantin
...
--
Konstantin Ignatyev

PS: If this is a typical day on planet earth, humans will add fifteen
million tons of carbon to the atmosphere, destroy 115 square miles of
tropical rainforest, create seventy-two miles of desert, eliminate between
forty to one hundred species, erode seventy-one million tons of topsoil,
add 2,700 tons of CFCs to the stratosphere, and increase their population
by 263,000

Bowers, C.A. The Culture of Denial: Why the Environmental Movement Needs a
Strategy for Reforming Universities and Public Schools. New York: State
University of New York Press, 1997: (4) (5) (p.206)
Neel Kumar
13 years ago
Permalink
Dear Konstantin,
You have stated my position so very elegantly that I cannot add/remove
even one word. We developers deserve a lot of blame for the insanity that
is software. :)

Neel

On Fri, Sep 21, 2012 at 9:50 AM, Konstantin Ignatyev
...
--
Neel Kumar neel-V0hOyZsTGozQT0dZR+***@public.gmane.org +1-408-418-6335
Eelco Hillenius
13 years ago
Permalink
Post by Konstantin Ignatyev
Post by Eelco Hillenius
Now as for Java having a bad rep for bloat... true for Spring.
So, in the nutshell we now complain that Spring/Java already have
implementation for all the typical problems and therefore one does not need
to reinvent the wheel.
I would argue that many of these 'problems' are trivial to tackle in the
first place, and there is a whole army of developers out there who are
better classified as 'spring coders' than 'java coders'. I've seen lots of
them when doing job interviews, and personally I don't think it's a good
thing, especially not if they don't understand why/ how the spring magic
works in basic terms.
Post by Konstantin Ignatyev
C'mon - lets not blame Spring or Java for bloat, they are pretty modular,
nobody forces you to use every piece of what is available.
They don't, but it's like Hibernate: you don't have to make a big bloody
(or anemic rather, so maybe bloodless is better) inefficient mess of your
server code, and yet that's what I've often see developers tend towards
when using that framework, especially the more junior peeps. Spring isn't
as problematic, but I found that it doesn't encourage people much to think
about their problem well, but just copy what everyone else seems to be
doing. I guess that's a potential problem with any form of framework.
Post by Konstantin Ignatyev
I think it is we developers deserve blame for bloated solutions, in large
part I blame uneducated developers for reinventing wheels all the frigging
time time without bothering to check what is available or checking but
immediately dismissing on the ground of 'bloat' without faintest attempt to
understand reasons for complexity.
You know, I've been inventing the wheel more and more the last few years.
Just to make the wheel a bit rounder every time. You assume that if there
is a solution out there, you should use it. Well, the advantage of not
doing that is that by doing it yourself you typically build up a much
better understanding of the problem than you would've when just using a
library, and you can often write a more pointed solution that doesn't
include all the fluff you don't need that's in the library just to make it
work for a wide range of users. I wouldn't recommend that for everything;
it just depends on the libraries that are available. I've also had a few
occasions where I started out implementing it myself, and then replacing
that with a library which I was then able to much better appreciate and
evaluate because I had a better understanding of the problem.
...
Hey, did you move on to management? ;-)

Seriously though, I agree with a structured approach. But let's be fair,
when we complain about the state of developers, we often complain about
them not getting the core CS skills down. How the hell are juniors going to
build that up if all you let them do is assemble solution from pre-fab
pieces rather than coding? And really, is Spring saving you that much work,
and are the solutions that fantastic? Not in my experience.

I also don't want to come across a Spring hater btw, I think it's been
great to move Java away from EJB, and it was certainly a better alternative
to the old EJBs back then, and I do think that DI is a useful invention for
Java. I'm just not in favor of kitchen-sink frameworks in general, for the
reasons I sprinkled my reply with.

Eelco
Konstantin Ignatyev
13 years ago
Permalink
Post by Eelco Hillenius
You assume that if there is a solution out there, you should use it.
Not at all. I assume that if there is solution(s) out there then need to be
thoroughly evaluate before rolling your own.
That is how junior-s should learn by the way, not by writing their own
first. It is like in math and physics - one studies previous body of
knowledge and guided to make sense of it, not reinvent calculus or theory
of relativity.

Note: IMO it is perfectly fine to dismiss existing solutions and go back to
basics, I have found myself doing that more and more in the past few years
too (see my comments in the JDBC thread). But I see that as a last resort.
Post by Eelco Hillenius
Spring isn't as problematic, but I found that it doesn't encourage
people much to think about their problem well

And it should not, Spring, and any other framework out there, should simply
provide paint by number sort of solution for a class of problems. They
supposed to free us from thinking about re-solving well understood problems
and let us focus on higher level challenges.
Post by Eelco Hillenius
And really, is Spring saving you that much work, and are the solutions
that fantastic?Not in my experience.

In my experience Spring and widely used solutions are way way better than
wast majority of home grown solutions I observe directly.
And there is contradiction in many statements: lots of people complain that
many developers create bloated mess when they use frameworks because they
do not think. Well what if the same people have to implement their own
solutions without help of frameworks? Think about that! :)
...
--
Konstantin Ignatyev

PS: If this is a typical day on planet earth, humans will add fifteen
million tons of carbon to the atmosphere, destroy 115 square miles of
tropical rainforest, create seventy-two miles of desert, eliminate between
forty to one hundred species, erode seventy-one million tons of topsoil,
add 2,700 tons of CFCs to the stratosphere, and increase their population
by 263,000

Bowers, C.A. The Culture of Denial: Why the Environmental Movement Needs a
Strategy for Reforming Universities and Public Schools. New York: State
University of New York Press, 1997: (4) (5) (p.206)
Eelco Hillenius
13 years ago
Permalink
...
Ok, agreed on that :-)

Eelco


------------------------------------

Continue reading on narkive:
Loading...