Join 3,512 readers in helping fund MetaFilter (Hide)


MetaFilter​FrontPage​BlogPost​TitleContent​String
April 18, 2014 9:51 AM   Subscribe

Two of these Java class names from the Spring framework are made up. One of them is real. Can you guess the real one?
posted by schmod (60 comments total) 17 users marked this as a favorite

 
ObjectiveC method + parameter invocations are so much more graceful, they read like little stories.
NSDictionary *myDictionary =
    [NSDictionary dictionaryWithObjectsAndKeys:
        [NSArray arrayWithObjects:
            [NSDictionary dictionaryWithObjectsAndKeys:
                @"value1", @"key1",
                @"value2", @"key2",
                @"value3", @"key3",
...

posted by Space Coyote at 10:00 AM on April 18 [5 favorites]


AnnotationMethodHandlerAdapter? Really? That's the real one? Jesus Christ, Java.
posted by savetheclocktower at 10:13 AM on April 18 [5 favorites]


OMG, BurlapExporter.
posted by onalark at 10:30 AM on April 18 [4 favorites]


ObjectiveC method + parameter invocations are so much more graceful, they read like little stories.

Except that's the thing: these aren't invocation chains. They're just class names.
posted by my favorite orange at 10:31 AM on April 18 [6 favorites]


Pro tip: Random guessing will almost definitely improve your score.
posted by schmod at 10:33 AM on April 18 [5 favorites]


Once I ate a LifecycleContextBean (not made up, btw), and I was filled with a sense of inner peace and understanding. Whoops, I'm sorry. I meant SenseInnerPeaceUnderstanding.
posted by mcstayinskool at 10:34 AM on April 18 [5 favorites]


>Jesus Christ, Java.

more like "Jesus Christ, abstract framework piled on top of abstract framework all the way down." It's perfectly possible to come up with short, meaningful, and useful Java class names.
posted by xbonesgt at 10:49 AM on April 18 [2 favorites]


just like the weighty hyphenated names of old money, the root cause of these naming monstrosities is often inheritance
posted by idiopath at 10:52 AM on April 18 [31 favorites]


It's abstract classes all the way down.
posted by robotmonkeys at 10:54 AM on April 18 [1 favorite]


One of the choices it gave me was ModelAndProfileValueHandlerMethodInvocationCallbackPreferringPlatformTransactionAnnotationHandlerInterceptor2, which is just the best.
posted by pinacotheca at 10:55 AM on April 18 [8 favorites]


xbonesgt: and it is possible to write readable perl, to check error codes in C, to write lisp code without useless obfuscatory macros, to use haskell without pointless monads (no pun intended) - it's possible, but each language has its easy vice (by culture and by design)
posted by idiopath at 10:55 AM on April 18 [6 favorites]


The worst part is that this rubs off on Java people: I'm working on some .Net code written by an ex Java guy, and it's full of ThingHandler and OtherThingHandler and SpecialOtherThingHandler classes, and of course all of them are completely different animals but the names give you no idea.
posted by Dr Dracator at 11:03 AM on April 18


Java is a language that was eaten alive by terrible, terrible frameworks. Once Design Patterns hit and enough dollar signs lit up, the market was flooded with new programmers who had been reassured that development was a rule-based process and all they had to do was apply the latest set of Patterns, Methodologies, Tools and Techniques to their particular problem. The new devs were uncertain, untested, and generally in over their heads, and the new frameworks provided a reassuring whiff of authority and structure. After all, writing your own system from scratch was obviously bad, but if you were using Spring or JBoss or whatever then you were at the very least clearly Following Industry Trends.

My favorite bit of Java code remains a snippet from an anonymous contractor who created a class that wrapped Map<String,String>, called it StringToStringMap... and included a test suite.
posted by phooky at 11:05 AM on April 18 [17 favorites]


I've done about 20 of these so far. I got exactly one right.

I've been writing Java more-or-less continuously for the past twelve years, for the last seven of them professionally.

So... yeah.
posted by Tomorrowful at 11:13 AM on April 18 [6 favorites]


ConfigClassesAndProfilesWithCustomDefaultsMetaConfig.ProductionConfig

That was the real one.

THE REAL ONE

THAT WAS THE REAL ONE
posted by Tomorrowful at 11:14 AM on April 18 [21 favorites]


Don't forget the old classic AbstractSingletonProxyFactoryBean. You can see a full list here.
posted by Rhomboid at 11:17 AM on April 18 [3 favorites]


It's perfectly possible to come up with short, meaningful, and useful Java class names.

Well, naturally, but the intersection of static typing with OO absolutism and influence of the design patterns people means Java as it exists in the world shows the very worst of this sort of thing.
posted by atoxyl at 11:21 AM on April 18 [1 favorite]


> Jesus Christ, Java

Java, what an asshole!
posted by vbfg at 11:23 AM on April 18 [1 favorite]


I will be quietly weeping over in the break room, where the AbstractDonutFactory can be invoked
posted by thelonius at 11:27 AM on April 18 [14 favorites]


My other favourite Java thing are 40 level deep stack traces. I mean, even a dim-witted authoritarian follower must realize at some point that maybe 40 levels of function calls cannot really be needed for his serious business application that copies files from A to B, surely?
posted by dhoe at 11:33 AM on April 18 [1 favorite]


I remember when someone asked about JDate on AskMe, and I thought, who would go to a dating site for Java developers?
posted by thelonius at 11:35 AM on April 18 [8 favorites]


S3BucketLifecycleConfigurationTransitionUnmarshaller
posted by Combustible Edison Lighthouse at 11:43 AM on April 18 [2 favorites]


ObjectiveC method + parameter invocations are so much more graceful

I'll try to remember that next time I'm using my NSAccessibilityLayoutPointForScreenPointParameterizedAttribute.
posted by RobotVoodooPower at 11:58 AM on April 18 [2 favorites]


dhoe: "My other favourite Java thing are 40 level deep stack traces. I mean, even a dim-witted authoritarian follower must realize at some point that maybe 40 levels of function calls cannot really be needed for his serious business application that copies files from A to B, surely?"

40? Hah.

I have a 253-line stack trace up on my screen this very moment. Reading from the bottom, you need to go 100+ lines up before you even get out of Tomcat...

(For whatever it's worth, our room full of Java developers who use Spring extensively all scored terribly on this thing too)
posted by schmod at 12:13 PM on April 18 [4 favorites]


Space Coyote: "ObjectiveC method + parameter invocations are so much more graceful, they read like little stories."

Where the stories in question are micro-fiction written by Hawthorne on amphetamines.
posted by invitapriore at 12:19 PM on April 18 [1 favorite]


so, so much OOP naming sadness can be replaced by first class bound object methods. I am very thankful that I started my C++ programming career after std::function was invented.
posted by scose at 1:05 PM on April 18


so, so much OOP naming sadness can be replaced by first class bound object methods. I am very thankful that I started my C++ programming career after std::function was invented.

Sigh. 16 years ago...
“The newest version of the Microsoft Visual J++ development environment
supports a language construct called delegates or bound method
references. … It is unlikely that the Java programming language will
ever include this construct. … bound method references are unnecessary
and detrimental to the language…. bound method references are
harmful because they detract from the simplicity of the Java
programming language and the pervasively object-oriented character of
the APIs. “
posted by Combustible Edison Lighthouse at 1:34 PM on April 18 [1 favorite]


Best one so far: MockPortletRequestHandledEventRequestMethodArgumentResolver

Although a straight google search does not turn up a javadoc entry. Perhaps it's constructed dynamically, if so some of the fake methods may turn out to be real with a bit of finagling.
posted by sammyo at 2:00 PM on April 18


Dyslexia alert, got that one backwards. Looks legit to me though.
posted by sammyo at 2:02 PM on April 18


Almost as good: CallbackPreferringPlatformTransactionManager
posted by sammyo at 2:04 PM on April 18


This thing doesn't check that the Markov-generated class names aren't also real ones. I was presented with the following choices:

1. SavepointManagerUtils
2. ConvertingEncoderDecoderSupport.TextEncoder
3. Exception

The second one, it claimed, was the real one. However, over 10 years of Java experience is telling me that maybe Exception is something that rings a bell.
posted by axiom at 2:44 PM on April 18 [4 favorites]


This thing doesn't check that the Markov-generated class names aren't also real ones.

Proving that a thousand monkeys at a thousand terminals can write Java code.
posted by five fresh fish at 3:03 PM on April 18 [1 favorite]


Yeah, I just got TransactionManager which was marked as being made up. I have 3 different TM classes in my current code base. Though, 2 are javax and one is from hsqldb, so technically not spring, but Ill be damned if thats a made up class name.
posted by lkc at 3:07 PM on April 18


> ObjectiveC method + parameter invocations are so much more graceful, they read like little stories.
NSDictionary *myDictionary =
    [NSDictionary dictionaryWithObjectsAndKeys:
         [NSArray arrayWithObjects:
             [NSDictionary dictionaryWithObjectsAndKeys:
                 @"value1", @"key1",
                 @"value2", @"key2",
                 @"value3", @"key3", ... 


To be fair, some of that verbosity has been reduced with Modern Objective-C / LLVM 4.0's literal and subscripting syntax. Your example above can now just be written:
NSDictionary *myDictionary = @{@"key":@[@{@"key1": @"value1",
                                          @"key2": @"value2",
                                          @"key3": @"value3", …
Not that there aren't still plenty of verbose method calls.
posted by JiBB at 3:16 PM on April 18 [1 favorite]


In a way, I like the Spring naming conventions. They're like bright coloration in animals: if you find yourself typing out seven camelcased words to name a class, you'd better realize it's dangerous, or know it's something you want to mate with.
posted by Riki tiki at 4:08 PM on April 18 [4 favorites]


"My other favourite Java thing are 40 level deep stack traces. I mean, even a dim-witted authoritarian follower must realize at some point that maybe 40 levels of function calls cannot really be needed for his serious business application that copies files from A to B, surely?"
Have any of y'all ever dealt with Apache's built-in XSLT processing? Some clever person somewhere decided that the anonymous inner class for handling function calls should identify itself as GregorSamsa. XSLT is a procedural language. Guess what happens when your base case in a recursive method fails to execute? That's right! A stack trace thousands of lines long, all exactly the same:

at GregorSamsa.applyTemplates()
at GregorSamsa.applyTemplates()
at GregorSamsa.applyTemplates()


This isn't mentioned anywhere prominent in the documentation, of course. You just see thousands upon thousands of lines of it the first time you cause a stack overflow. More often than not, before you've had your first cup of coffee.

I still haven't forgiven them for the most surreal moment of my professional life.
posted by Mayor West at 4:08 PM on April 18 [11 favorites]


I've mostly managed to avoid Java; I'm just slightly too old to have done it at university (we started off with toy Pascal-like languages and went on to C/C++ and Lisp), and other than playing around with Java Applets when they came out, I managed to not have much to do with it, instead my professional coding career going into Perl, Python and more recently C++ and Objective C. Having avoided it for the first few years, I've felt my choices validated every time I saw some report of horrendous "enterprise-class" codebases, with custom classes encapsulating integers or whatever and the sort of unimaginative cargo-cultisms that seem to be the currency in Javaland.

This blessed state has been somewhat undermined by my starting a new job in a Scala shop last year, and the awareness of the horrors of Java lurking just beneath the nice functional surface of Scala does fill me with a sense of vague unease.
posted by acb at 4:10 PM on April 18


We've all got our problems.

Scala has a lot of cruft due to its on-again/off-again relationship with the Java ecosystem, no question about that. But that's a two-way street: using the JDK gave it a boost that allowed them to get way ahead of themselves on language features and API, and now they're paying the price. Scala needed a slow-and-steady approach, making damn sure they didn't add something they'd regret. But as soon as people saw an alternative to javalang, with functional semantics as first-class citizens, and a boilerplate-free future, restraint went out the window followed closely by the maintainability of the tooling. You can't put that all on Java, which was only complicit by being a product of its birth and upbringing.

A "purer" alternative is Clojure, which uses the JDK and JVM but binds itself most strongly to LISP. Unfortunately, LISP dialects are dynamically-typed by nature, outside of the purest abstractions of "atom" and "list". The JVM is really not equipped for fully-dynamic languages, and probably never will be — the invokedynamic JVM instruction covers the 90% of cases where types are only dynamic until instantiation, but can't handle much nuance (e.g. mixins, traits), nor type changes after the fact.

I say this as a long-time Java developer in complete awe of the JVM's (and HotSpot's) role in modern development: it is anchored by its ties to the Java language, which is itself tied to a late-1990's view of language "migratability". The fact that they added invokedynamic without feeling compelled to support it in the language syntax is breathtakingly impressive, but going further than that would require breaking changes in the JVM, which just ain't gonna happen.¹

But getting back to Clojure, I fear for its sinful, prideful ways. Homoiconicity is a very powerful characteristic for a language, but with great power comes great responsibility. Any modern LISP dialect will face the temptation of dynamic runtime plugins: submit this text, we'll interpret it, and voilà! First class executable code. But almost two decades in, a language with the public visibility and financial backing as Java still has not learned that evals are evil.² Clojure needs a level of self-discipline that has never been required of a LISP dialect, if it is to prevent people from being tempted to blend their data and their code.

Rust's syntax consistency is terrible. In its majestic equality, Haskell forbids rich and poor code alike to violate its type system. Python will sit on the 2.x/3.x fence until PyPy raises enough donations for the 3.x migration, at which point both will promptly become obsolete. C is finally being properly roasted for its role in enabling the Heartbleed bug. JavaScript will become the assembly language of the world, and so people will continue to treat it as a modern language no matter how far it falls behind.³ As that happens, it will cease to be an approachable language for new programmers, which is pretty much the best thing the language had going for it.

Everything you currently believe about the programming language spectrum is changing, as much for the worse as for the better. I hold out hope for SQL, which uniquely among such widely-adopted languages has true dialects (change X to Y and it works the same, for all practical purposes!).

Beyond that, we had all better be on our toes.

¹ My company is currently upgrading to Java 7 after two years of my insistence, and it would never happen if there were real risks about breaking backwards compatiblity... we don't even know how to test a lot of our code.

² Yes, Struts is not Java, but casual reflection support is like handing out loaded grenades.

³ Okay, for all of Eich's problems, you have to admit that JavaScript is ten million percent better than it had any right to be.

posted by Riki tiki at 5:17 PM on April 18 [4 favorites]


Riki tiki: mainstream Clojure dogma is that any usage of "eval" at runtime is a bug (or at least shitty design) until proven otherwise. Data that your code touches is runtime code, in any language (every program, regardless of language, is a DSL over the input provided to it at runtime; with any luck you can at least limit the power of that DSL).
posted by idiopath at 5:24 PM on April 18


Scala is pretty wonderful, though sometimes the Magic of traits can leave some serious teethmarks in your ass.

I'm looking at you, concurrent.map extending MapLike and its incredibly non-atomic getOrElseUpdate. Right at you. Ruefully.
posted by flaterik at 5:58 PM on April 18


Yeah, take a look at the classes for HAPI (a Java HL7 API)

Example: ORM_O01_ORCOBRRQDRQ1ODSODTRXONTEDG1RXRRXCNTEOBXNTECTIBLG
posted by MikeKD at 6:15 PM on April 18 [2 favorites]


Riki tiki: "Unfortunately, LISP dialects are dynamically-typed by nature, outside of the purest abstractions of "atom" and "list"."

I would amend this to say "by convention" rather than "by nature," since something like Typed Racket maintains basically all of the upsides of a Lisp dialect while also providing a pretty expressive type system.
posted by invitapriore at 6:23 PM on April 18


Even the language mentioned, Clojure, has protocols that dispatch by type, and the ability to define and extend Classes. The usage of polymorphic containers that can hold any Object is a design choice rather than an unavoidable limitation.
posted by idiopath at 7:23 PM on April 18


the anonymous inner class for handling function calls should identify itself as GregorSamsa.

Obviously the developer woke up one morning and discovered it was broken.
posted by Dr Dracator at 11:50 PM on April 18


I will be quietly weeping over in the break room, where the AbstractDonutFactory can be invoked

I'm just getting over some dietary issues, so that's not really an option for me. So I'll weep quietly for a while, and then write Perl until I feel much better.
posted by mikelieman at 2:48 AM on April 19


Oldie but goodie: I had a problem so I thought to use Java. Now I have a ProblemFactory.
posted by Nelson at 7:14 AM on April 19 [6 favorites]


I can't stand Spring. It's a bloated piece of crap that makes your project a bloated piece of crap. It's like vampires or zombies or something. You let just one element of Spring creep into your project, and pretty soon, you're project is overtaken. Before you know it, you're doing things The Spring Way. What an overwrought and unnecessary way to do something as basic as dependency injection.
posted by evil otto at 10:50 AM on April 19 [1 favorite]


Java is a language that was eaten alive by terrible, terrible frameworks. Once Design Patterns hit and enough dollar signs lit up, the market was flooded with new programmers who had been reassured that development was a rule-based process and all they had to do was apply the latest set of Patterns, Methodologies, Tools and Techniques to their particular problem. The new devs were uncertain, untested, and generally in over their heads, and the new frameworks provided a reassuring whiff of authority and structure. After all, writing your own system from scratch was obviously bad, but if you were using Spring or JBoss or whatever then you were at the very least clearly Following Industry Trends.

I so, so wish I could favorite this comment more than once.

Sometimes I feel like this whole adventure in OOP was a mistake. OOP begets design patterns, and design patterns beget architecture astronauts. You know the people I'm talking about. There's no problem they can't "solve" by making it more complex. I really do think something in the nature OOP encourages this kind of thinking. It's like, they get so into the building of the thing, that they forget the thing only exists because it's supposed to do something. And of course, their byzantine masterworks carry the implicit assumption that said astronaut will always be around to maintain them, even though that never, ever turns out to be the case.

And as much as I tire of the platform jockeys and the platforms they love (I'm looking at you, Spring!), about the only thing worse is an architecture astronaut. At least the platform jockeys leverage third party code instead of reinventing the wheel every time. You can tell the architecture astronaut in the wild by their standard war cry : "LET'S BUILD A FRAMEWORK!"

LBAF is actually worse than Not Invented Here, because at least Not Invented Here stops with the wheel that engineer is trying to reinvent. If you let LBAF run wild, not only do you re-invent the wheel, but you spend so much time re-inventing wheels that your company essentially becomes a wheel factory, even though you're really supposed to be running a lemonade stand.

The antidote to LBAF, of course, is YAGNI, the Occam's Razor of the software engineering world. And the reason to seek a leadership role in your company is so you can smack your devs upside the head with a YAGNI stick before they go all LBAF on you and turn your company into an AbstractWheelFactory.
posted by evil otto at 11:23 AM on April 19 [2 favorites]


These names would be impossible in FORTRAN77.
posted by double block and bleed at 12:17 PM on April 19


Six characters: make it fit.
posted by double block and bleed at 12:19 PM on April 19 [1 favorite]


This is from fairly recent personal experience, but might I suggest calling it "WAGNI" instead of "YAGNI" if you're smacking anyone else around with it? "We ain't gonna need it" is constructive, and a useful reality check that there's a team of my peers depending on me to deliver. "You ain't gonna need it" is condescending.

And it's not actually accurate. An individual developer has needs that go beyond implementation and maintenance. In the end, "It" might not have any immediate value to the product, but may still be useful as a thought experiment and as relief from the grind of simple feature development.

Michaelangelo had it right: craftsmanship and art often mean starting with everything, then removing anything that isn't part of the solution. People who stop thinking about unproductive things end up programming by rote. That's great as long as they're in their comfort zone, but falls apart as soon as you have a real problem.

That said, dreamers often get lost in the dream ("architecture astronauts" being among the worst offenders). I'm totally that guy, or at least I was back when I had time to program instead of doing project planning and code reviews. But for us, it doesn't take much introspection to realize that "you ain't gonna need it" is a useful personal mantra.

It can't be heard as a directive, though. If people had told me "YAGNI", I'd have felt insulted, just as if they'd told me "be less smart." Not that that's a fair interpretation... I'm just saying that that's how it would have been received.

In contrast, hearing "We Ain't Gonna Need It" from someone I respected would have allowed the "You Ain't Gonna Need It" seed to take root.
posted by Riki tiki at 12:55 PM on April 19 [2 favorites]


Good point! Totally agreed. WAGNI is a good approach to take.
posted by evil otto at 1:15 PM on April 19


I refuse to believe FooBarAliasInitializer is a real thing
posted by I've a Horse Outside at 1:21 PM on April 19


Foo and bar are metasyntactic variables. That's just a programmer's way of saying "this thing initializes aliases". Also it's in a unit test, so I guess an argument could be made that it's not a real thing, but a test for a real thing.
posted by axiom at 8:47 PM on April 19


I don't think it's about the meaning or realness of 'FooBarAliasInitializer', but rather the putrid stench that emanates from this bizarro newspeakification of code.
posted by mysticreferee at 1:06 AM on April 20 [1 favorite]


I have a 253-line stack trace up on my screen this very moment. Reading from the bottom, you need to go 100+ lines up before you even get out of Tomcat...

So Java creates a lot of objects; this is simply to increase the power of Object Oriented Programming. Also, if the exception actually did anything but dump the trace, that would be bad, since it would be using exceptions for flow of control.
posted by thelonius at 5:31 AM on April 20


Hey what? Doing something in responce to an exception is considered bad now?
posted by Dr Dracator at 8:59 AM on April 20


I've encountered people who seemed to think so, Dr Dracator.
posted by thelonius at 10:07 AM on April 20


Oh was this a joke? I can never tell with Java.
posted by Dr Dracator at 10:31 AM on April 20 [1 favorite]


Yes, my idea that more objects means that OOP works better is a joke
posted by thelonius at 1:58 PM on April 20


« Older Digger is a classic IBM PC game from 1983 made by ...  |  VC for the people... Newer »


This thread has been archived and is closed to new comments