Live data from Hacker News

Java: Real or Not?

java.metagno.me

21–30 of 68 posts

Re: Java: Real or Not?

#21
post #14

The names are extremely predictable (as shown by this Markov chain), which is actually a Good Thing (tm). The bad thing is that things got complex enough to warrant these names. It's the knee jerk reflex of decoupling everything, to the point that you have 80% configuration/wiring/setup vs 20% of code that actually does something useful. Each extension point in the framework is represented by a couple of these classe…

> Maybe Spring should run a study and see which of their extension points is actually used, at all, or by more than x % of users

That last part seems key: I'd be shocked if you didn't find someone, somewhere for every one of those features – and, based on some of the enterprise apps I've seen, doing so because it allowed a quick hack rather than solving a problem more correctly and expensively. The question really should be “Is the value from having this work the non-trivial obscurity and maintenance cost?” to emphasize that features and extensibility aren't free.

Re: Java: Real or Not?

#22
post #12

Some answers are not 100% right. I got: - HttpServlet - AbstractXmlWebMvcResultProcessingInterceptorAdapter - MockJtaTransaction While there is HttpServlet class, it is considered wrong, and 3rd option is considered correct :(

It's only talking about classes from Spring specifically. HttpServlet isn't a Spring thing.

That makes it even-more-pointless. It's like people criticizing command-names in linux and going "LOL a computer made that one" even though the command actually exists in another distribution or shell.

Re: Java: Real or Not?

#23
I don't like complaining about submissions not working in my browser, but this time I feel like I'm missing a lot of fun.

On Firefox DevEdition nothing past "Pick the one that's not made up!" appears. On latest IE it's every time "ComplexPortletApplicationContext.EditController" vs "ModelMapBasedHandlerMethodProcessor" vs "AbstractPlatformTransactionAttributeSource". 16 times the same question. Well, this could be just bad luck if questions are random. With randomness you never know.

Re: Java: Real or Not?

#24

I don't like complaining about submissions not working in my browser, but this time I feel like I'm missing a lot of fun. On Firefox DevEdition nothing past "Pick the one that's not made up!" appears. On latest IE it's every time "ComplexPortletApplicationContext.EditController" vs "ModelMapBasedHandlerMethodProcessor" vs "AbstractPlatformTransactionAttributeSource". 16 times the same question. Well, this could be ju…

Trust me you are having more fun than anybody out here.Unless being humiliated in a way that you will never dare claim mastery on any thing (even when its the only thing that you think you are good at) sounds like fun to you ;)

Re: Java: Real or Not?

#25
post #10
post #4

It never hurts to study the masters in serious enterprise software: https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpris...

This is great but it brings up a serious question I've always had. Taken to the extreme, things like the single responsibility principal, the open closed principal, etc, result in messes like this. I've been wondering if anything has been written around a concrete methodology of doing OOP that doesn't naturally converge onto something like this, and why it happens.

SOLID are not rules but guidelines. Design patterns allow the code to be written in a reusable manner by decoupling some responsibilities. But YAGNI, no code should be written until it is needed.

That's why TDD is absolutely fundamental. In theory TDD can help fight over-engineering, and keep focus on relevant code. SOLID and design patterns are then here to help refactor code when a spec changes. They are recipes.

Obviously TDD fizzbuzz done correctly would have resulted in a single class implemented. Now imagine requirements changes and booze should be printed if the number can be divided by 20,breeze if the number can be divided by 40,bubble when divisible by 56, the easiest way to refactor that single class would be to introduce a CHAIN OF RESPONSIBILITY. Which again is not necessary at first place, if the number of cases remains small.

Re: Java: Real or Not?

#26
post #10

Earlier quoted context omitted.

This is great but it brings up a serious question I've always had. Taken to the extreme, things like the single responsibility principal, the open closed principal, etc, result in messes like this. I've been wondering if anything has been written around a concrete methodology of doing OOP that doesn't naturally converge onto something like this, and why it happens.

I use Spring and I'm not agree that it's a mess. It has a lot of functionality but good architecture allows to keep it under control and easily enhance when needed. Spring is one of the best open source frameworks I've ever seen.

Both Spring and JavaEE (as compared to J2EE) have gotten a lot better by using annotations for meta-programming. I was about to give up on enterprise Java programming when the clutter/over-engineering started to get better.

Curiously, I'm going to at least partially credit Ruby for introducing the idea of convention over configuration.

Re: Java: Real or Not?

#28

Are the generated names verified to be non-real? There could be some overlap.

They're not, there is quite a bit of overlap because most of the names are reused (i.e. once you know what a Context is, Handler, etc., smashing these words together makes sense

Re: Java: Real or Not?

#29
This is sort of like making fun of German for using long combinations of smaller words to denote a concept.

Or making fun of medical jargon. (ha ha, you said subdermal hematoma not bruise)

Once you know what the individual words mean, you can use them in different places, and know right away what the class does. Do you need to use 80% of these? No, but they're there, like parts in a car, in case you need to tinker.

Re: Java: Real or Not?

#30
post #5

It's not surprising that a Markov chain could put together plausible sounding class names, because yeah, there are definitely patterns that class names fall into. What's surprising is that one third of the names it's showing me are actually real. I mean, "MetaMetaContextHierarchyConfig" actually exists?

I got "ConfigClassesAndProfileResolverWithCustomDefaultsMetaConfig.ResolverConfig" as real (which I failed to pick... I mean, really?) and had to doublecheck it really is.

Sadly, it's true. What the hell, Spring Framework?

Post reply on HN