
Unsure if I understand TransactionAwarePersistenceManagerFactoryProxy - ericdc
http://stackoverflow.com/questions/14636178/unsure-if-i-understand-transactionawarepersistencemanagerfactoryproxy/14636231#14636231
======
mindcrime
Long names are a Good Thing as far as I'm concerned. Having spent FAR more
time than I care to admit working with IBM crap that uses name like QXMGRTBL
and QWRKQITM, I'll take TransactionAwarePersistanceManagerFactoryProxy any
day... and twice on Sunday.

The only bit about this that even strikes me as a little bit unreasonable is
the "Proxy" bit at the end. Not sure why you need another level of Proxy on
top of TransactionAwarePersistenceManagerFactory, but it's not like you type
that name particularly often. Most likely it's referenced once in a Spring
config file somewhere, and given a bean name of "persistenceManagerFactory"
which is what would be referenced in code once at most. Hell, probably not
even that... that's probably wired into another bean that just gives you the
PersistenceManager... which you might not actually ever reference in code
either, since Spring can auto generate JPA implementation classes that use
JPQL queries, etc., and eliminate the need for most hand coding of anything
JPA related.

OK, sure, just to look at it, at first blush, the name looks long and silly,
but when you actually think about what it is and how it's used, it's not
exactly a big deal.

~~~
rbehrends
The problem is not the name, but the ridiculous overdesign of which it is a
symptom.

At which point I bring you the story of the king's toaster [1] (which is a
cautionary tale, not an aspirational story, just in case that should be
unclear to anybody).

\------------------------------------------------

Once upon a time, in a kingdom not far from here, a king summoned two of his
advisors for a test. He showed them both a shiny metal box with two slots in
the top, a control knob and a lever. "What do you think this is?"

One advisor, an engineer, answered first. "It is a toaster," he said.

The king asked, "How would you design an embedded computer for it?"

The engineer replied, "Using a four-bit microcontroller, I would write a
simple program that reads the darkness knob and quantizes its position to one
of 16 shades of darkness, from snow white to coal black. The program would use
that darkness level as the index to a 16-element table of initial timer
values. Then it would turn on the heating elements and start the timer with
the initial value selected from the table. At the end of the time delay, it
would turn off the heat and pop up the toast. Come back next week, and I'll
show you a working prototype."

The second advisor, a computer scientist, immediately recognized the danger of
such short-sighted thinking. He said, "Toasters don't just turn bread into
toast, they are also used to warm frozen waffles. What you see before you is
really a breakfast food cooker. As the subjects of your kingdom become more
sophisticated, they will demand more capabilities. They will need a breakfast
food cooker that can also cook sausage, fry bacon, and make scrambled eggs. A
toaster that only makes toast will soon be obsolete. If we don't look to the
future, we will have to completely redesign the toaster in just a few years.

With this in mind, we can formulate a more intelligent solution to the
problem. First, create a class of breakfast foods. Specialize this class into
subclasses: grains, pork and poultry. The specialization process should be
repeated with grains divided into toast, muffins, pancakes and waffles; pork
divided into sausage, links and bacon; and poultry divided into scrambled
eggs, hard-boiled eggs, poached eggs, fried eggs, and various omelet classes.

The ham and cheese omelet class is worth special attention because it must
inherit characteristics from the pork, dairy and poultry classes. Thus, we see
that the problem cannot be properly solved without multiple inheritance. At
run time, the program must create the proper object and send a message to the
object that says, 'Cook yourself'. The semantics of this message depend, of
course, on the kind of object, so they have a different meaning to a piece of
toast than to scrambled eggs.

Reviewing the process so far, we see that the analysis phase has revealed that
the primary requirement is to cook any kind of breakfast food. In the design
phase, we have discovered some derived requirements. Specifically, we need an
object-oriented language with multiple inheritance. Of course, users don't
want the eggs to get cold while the bacon is frying, so concurrent processing
is required, too.

We must not forget the user interface. The lever that lowers the food lacks
versatility and the darkness knob is confusing. Users won't buy the product
unless it has a user-friendly, graphical interface.

When the breakfast cooker is plugged in, users should see a cowboy boot on the
screen. Users click on it and the message 'Booting UNIX v. 8.3' appears on the
screen. (UNIX 8.3 should be out by the time the product gets to the market.)
Users can pull down a menu and click on the foods they want to cook.

Having made the wise decision of specifying the software first in the design
phase, all that remains is to pick an adequate hardware platform for the
implementation phase. An Intel 80386 with 8MB of memory, a 30MB hard disk and
a VGA monitor should be sufficient. If you select a multitasking, object
oriented language that supports multiple inheritance and has a built-in GUI,
writing the program will be a snap. (Imagine the difficulty we would have had
if we had foolishly allowed a hardware-first design strategy to lock us into a
four-bit microcontroller!)."

The king had the computer scientist thrown in the moat, and they all lived
happily ever after.

[1]
[http://www.ee.ryerson.ca/~elf/hack/ktoast.html](http://www.ee.ryerson.ca/~elf/hack/ktoast.html)

~~~
mindcrime
It's an amusing story and a good cautionary tale, no doubt. But not all
complex designs are over-engineering. Some problems are complex and require
complex solutions. And sometimes complexity in one place is just a way of
moving it from somewhere else, because somebody thought that tradeoff made
their life better.

See what I said below about how much I prefer JPQL and Spring Data...
Personally, I really do not have a problem with this.

~~~
wldlyinaccurate
> Some problems are complex and require complex solutions.

And yet some very complex solutions were solved with very simple languages,
before Java was conceived.

~~~
jfb
Java is not a complicated language. Something about its affordances pushes
developers into these giant labyrinthine swamps of abstraction violation, but
the language isn't that complicated, either syntactically or semantically.

~~~
casual_slacker
The heavy emphasis on classes is what is strange about it. Many programmers
don't realize the strangeness since they've used classes their entire careers.
A class isn't really a procedural concept. Nothing in a processor knows what a
class is. It's more of a modeling language with an assumption that you'll
architect your program to group similar methods into abstract trees of domain
concepts, with your data at the leaves (instances).

So we're stuck with these complicated compile-time rules for defining
everything in terms of a procedural language. We come up with complicated
templates and generics for getting one set of methods to work with two types
of data. Objects are needlessly serialized and deserialized to pass between
systems, and programmers are needlessly spending time writing such methods.

I'm surprised that scala's paradigm of having actors work on data hasn't
caught on more. When you separate them from the start, new modules are way
easier to right, and integration time drops to near zero.

~~~
jlgreco
If I had to pin down Java's problem on one thing, I would say that its problem
is really C.

Or more accurately, the problem is that Java was a new language shoehorned
into being "like" a language that was never meant to hold the concepts that
Java demands. In some cases this manifests itself in more syntactical ways;
C's pragmatic but unsophisticated approach typing works well for C, but starts
to become a real burden when you start adding more sophisticated concepts onto
the language. (Were generics _really_ a concept that were ever appropriate for
something like C? Generics deserve a more considered treatment; a language
with structure and syntax designed with them in mind.) In other cases the
impact is more clear but inexplicable; _" In Java Everything is an
Object"_(tm)... except for the things that are not.

The end result is a language that is ugly and clumsy to work with without some
pretty advanced tooling, all for reasons that _really_ have no business being
real problems. Shameful (primarily cosmetic) flaws forced upon Java by the
business decision: _" make it reminiscent of C"_.

I have the same complaint about C++. Had Java and C++ not burdened themselves
with the design requirement of looking like C, they would be much better
languages. Languages that stray further from the mold, like Scala or Go (I am
thinking particularly of their abandonment of C inspired defines, in favor of
a more Pascal approach), are more pleasant to work with for it. Perhaps this
damages adoption.. but that is another matter I think.

~~~
DougWebb
I don't think I agree with your analysis. C# was originally designed to look a
lot more like Java than Java ever looked like C, but it hasn't been hampered
by that and has evolved to be a much more advanced language than Java has. It
also doesn't have the over-engineering culture that Java has (aside from a
number of "Enterprise-Class" add-on libraries Microsoft has tried to push
out.)

The same could be said about Ruby and it's relationship to Perl and Python. It
has cultural roots in those languages, but is often regarded to be better
rather than worse. (As a die-hard Perl developer I disagree, but I don't hold
a grudge.) All three are also considered to be C-like languages too, and they
don't suffer the problems Java has.

One could argue that Java's problem was that it was designed for programming
VCRs, DVD players, and Cable-TV boxes, and similar equipment, but the got
stretched and pulled into environments it just wasn't ready for. That, plus
Sun's hyper-aggressive marketing machine to turn Java into the language-for-
everything, created the beast that it has become.

My personal view is that Sun turned Java into a programming language for
charge-by-the-hour consultants. The culture of over-engineering exists because
it takes a lot more time to design software that way, more time and larger
teams to implement software that way, and specialized hard-to-transfer
knowledge to maintain that kind of software. This all benefits the consultants
and hurts the companies paying for the software to be built, which only makes
sense if Sun was intentionally pushing Java that way.

~~~
jlgreco
I would say that all of those languages, while "officially" C-like (as Go is),
all stray much further from C than Java or C++ (as Go has). _Particularly_
Perl, Python, and Ruby, which are dynamically typed which singlehandedly
eliminates neutralizes a great deal of "C's baggage".

I wouldn't describe C# as a language that I like, but I think it too has
benifited from breaking the mold of C more than Java did (though I attribute
most of it's superiority to its designers simply making better decisions in
several places). Named and optional arguments stand out in my mind as ways C#
did something that had no precedence in C, while Java _still_ has not. (There
is that double squiggly bracket trick, but you have to admit that is _pretty
shoddy_ ).

------
cocoflunchy
Java does not own the monopole on this one...

Ever heard of
kBluetoothAMPManagerCreatePhysicalLinkResponseAMPDisconnectedPhysicalLinkRequestReceived

or

__AVAILABLE_MAC_OS_X_VERSION_10_0_AND_LATER_BUT_DEPRECATED_IN_MAC_OS_X_VERSION_10_5

or

cairo_atsui_font_face_create_for_atsu_font_id_REPLACED_BY_cairo_quartz_font_face_create_for_atsu_font_id

?

~~~
eridius
I'm not familiar with the first or the third, but the second example you cited
is working as intended. No 3rd-party developer _ever_ types this (and I don't
know if anyone at all ever types this or if it's machine-generated), and the
long name is meant as a form of documentation for anyone reading the header
file.

------
ante_annum
Remember that Sun led by example.

com.sun.java.swing.plaf.nimbus.InternalFrameInternalFrameTitlePaneInternalFrameTitlePaneMaximizeButtonPainter,
anyone?

[http://javadoc.bugaco.com/com/sun/java/swing/plaf/nimbus/Int...](http://javadoc.bugaco.com/com/sun/java/swing/plaf/nimbus/InternalFrameInternalFrameTitlePaneInternalFrameTitlePaneMaximizeButtonPainter.html)

~~~
sluukkonen
It's an internal, automatically generated class. No programmer is ever going
to use it.

------
strlen
Alternatively, this is why Java needs a real namespace mechanism. "package"
doesn't cut it. See: namespaces in C# or C++, or alternately modules in ML.

One thing I like about DI implemented in a language itself is that is that it
negates the need to make factories in all cases. So, essentially, imagine if
Java had C# style namespace and this was done using Guice-style DI.

    
    
      bind(Persistance::Manager.class).toProvider( 
        new Provider<>() {    
          public Persistance::Manager get() {
            new Persistence::Manager::TransactionAware();
          }
      });

------
nostromo
I've come back to Java recently via Play Framework. To my surprise, Java can
be a joy to use, so long as you avoid old-school frameworks, like Spring,
entirely.

~~~
jebblue
I'm starting to look more at play on the side, except for the SCala stuff I
keep seeing, as long as I can use it from Java and not have to deal with
Scala's weird syntax then I think Play could be the new best hope (since it's
not clear what Google plans to do with GWT - which rocked).

------
shmerl
Camel notation looks awful with so many words. C++ style with underscores is
way more readable.

~~~
veesahni
snake_case is 20% easier to read ( reference:
[http://bit.ly/11T1FWY](http://bit.ly/11T1FWY) )

~~~
shmerl
I always thought it's rather self explanatory. Reading a text without distance
between the words requires more effort. Capital letters don't help much for
that. Underscore gives a space between the words, which allows more fluent
reading.

~~~
regularfry
It might be self-explanatory, but there's a vast gulf between self-explanatory
and _correct_.

~~~
shmerl
In this case it's not only correct, it's easy to test.

------
jhare
Not necessarily a "Java" problem so much as it is a Spring problem.

------
bengoodger
It's not limited to Java. We have a rule in Chromium where if your class name
contains the same word twice you have to do a shot.

------
jcheng
This is obviously trolling but I'll take a stab at actually answering the
question, based on the javadoc[0]. (I have never used Spring or JDO and
haven't done Java server-side programming since 2002.)

The JDO framework has an interface called PersistenceManagerFactory that is
used to... well, create objects that manage persistence. Spring has its own
thread-bound PersistenceManager abstraction that you need to fiddle with when
you're doing transactions. This class lets you use the former's interface but
decorated with the latter's behavior, so code that is designed for JDO doesn't
need to be modified to call the Spring APIs explicitly.

(Am I close??)

[0]
[http://static.springsource.org/spring/docs/2.0.7/api/org/spr...](http://static.springsource.org/spring/docs/2.0.7/api/org/springframework/orm/jdo/TransactionAwarePersistenceManagerFactoryProxy.html)

------
smegel
Who keeps changing the title, it was "And this, dear children, is why Java
should stop taking drugs"?

Quoting part of an article as the title is not necessarily editorialization,
and when the link is not actually an article, but a SO question, the original
"title" may not be particularly interesting or informative.

Obviously inventing provocative titles simply to spark a flame-war is not on,
but in this case the title was humorous (and interesting). The new title which
is literally someones question on SO seems out of place on the front page, and
not really the point of discussion.

Interesting titles can form part of the culture of a site like this, and over-
zealous editing of titles damages the sense of community. It's probably the
thing I dislike most about HN right now.

~~~
eridius
The original title was garbage. The only thing at all it told me was that the
article was somehow related to Java. I did click on it when it was the
original title, and was very disappointed to see it was just a bad answer
(which has at this point been deleted by the SO mods) to a stupid question.

The new title, on the other hand, tells me this is going to be about absurdly
long factory classes, almost certainly using Java, and that I should probably
be expecting humor rather than, say, a long article about an obscure
interaction in Java that produces amusing results (which is what I had _hoped_
I was getting with the original title).

It also happens to be the title of the linked "article" as well, which I
believe is what HN says you should be using rather than editorialized titles.

------
soup10
I've always maintained that java itself is not so bad. It's the things people
have done with it that make angels cry. People are the problem, not java.
Leave java alone.

~~~
icambron
Languages aren't just syntax rules; they're ecosystems. And unless you want to
build everything from scratch, you're going to need to use libraries and
frameworks from that ecosystem, and you'll have to play by their rules.
Further, you'll probably end up impedance-matching your code to those
frameworks, just to make your architecture cleaner. Later, you'll seek help on
some aspect of your project and most of the respondents' advice will follow
the basic patterns of How Java is Written. Then you're going to hire
additional programmers with lots of Java experience to help you build it, and
they'll come with a bunch of notions on what the best practices are. So I'm
not sure there's a practical distinction between "Java itself" and "things
people have done with it". Java _is_ people.

------
Fauntleroy
That's not so bad. If you haven't seen the Windows 8 API documentation yet,
you should go ahead and have a laugh: [http://msdn.microsoft.com/en-
us/library/windows/apps/br21137...](http://msdn.microsoft.com/en-
us/library/windows/apps/br211377.aspx)

When most of your method/class names overflow your table of contents' width,
you've got a serious problem.

~~~
keithnoizu
The problem here isn't their class names. It's that everyone at the empire
decided to go metro a few years back and made a bunch of sites like msdn a
pain to use but with a nicer font and color pallet.

My guess is no one bothered to include UX in their annual commitments when
they got the memo for the design change.

------
speeder
I don't understood the question either...

I mean, it has so much jargon on it, that what I felt is what I think my mom
feels when I am talking with my dad...

I read, and re-read, and read again... And the only thing that I would think
was: "omgwhy? wtf? WHY THIS EXISTS IN FIRST PLACE???"

------
contingencies
_The problem with object-oriented languages is they 've got all this implicit
environment that they carry around with them. You wanted a banana but what you
got was a gorilla holding the banana and the entire jungle._ \- Joe Armstrong,
inventor of Erlang.

------
ww520
People are so easily trolled. This looks like a generated class name in
Spring.

------
krapp
knowing absolutely nothing about language design (and not many languages)
other than occasional experiments in notepad... is there no language which
attempts to allow spaces, maybe with quotes, for better legibility?

like instead of

    
    
        org.springframework.orm.jdo.TransactionAwarePersistenceManagerFactoryProxy
    

something like

    
    
        org.'spring framework'.orm.jdo.'transaction aware persistence manager factory proxy'
    

or is that just a terrible idea?

~~~
dxm
I personally think that's worse. The original declaration is easier to read
and immediately recognisable as to what it is, I can see clearly that it's a
namespace and a class. The second version would require me to think.

------
ojiikun
For my money, "ObjectFactoryCreatingFactoryBean" is the most mind-blowing
class name ever authored, especially when you realize it is actually useful on
occasion!

------
smegel
And I thought C++ led to complex abstractions.

It makes me wonder if it was just accident that Java developed this way, or if
it could have been an xml free, simple interface language.

------
finnw
Reminds me of one of mine:
[http://stackoverflow.com/q/137060/12048](http://stackoverflow.com/q/137060/12048)

------
mmariani
And people still complain about ObjC long method names...

~~~
ericdc
lol

------
jamesbritt
Wow. Naming really _is_ importantant.

[https://news.ycombinator.com/item?id=5944101](https://news.ycombinator.com/item?id=5944101)

:)

------
ovoxo
How did this post's title not get auto-modified?

------
EzGraphs
I kind of preferred the original title on HN that quoted a comment:

"And this, dear children, is why Java should stop taking drugs."

