This is not a code smell, but something larger, and much worse. Java is fundamentally an imperative language, and these names are evidence of the disconnect between that nature and what people think Java is.
One can argue that this is the result of ignorance, that "good" Java programmers will avoid this trap. And yet, for all it's restrictions, it doesn't give much refactoring guidance. The proliferation of patterns (both for creation and relation) in Java is a weakness, not a strength, and the result is monstrosities like this. Training, experience and convention avoids these traps, but why do we create new languages if not to reduce the amount of training, experience and convention that a programmer needs to learn in order to be productive with an environment?
I don't see how this name is a problem beyond giving cannon fodder for language hipsters to rant about Java.
How many programmers have been affected by this internal class? How many programmers have used it and complain about it?
Java allows long identifier names and gives people the freedom to name however they like. Why is that a bad thing? You want syntax rules in the language to force short identifier names? We had those long while back and it's a really bad idea.
And BTW what is so wrong about imperative? It's simple to learn and simple to follow. It has solved many problems, given whatever the real world constraints. Just because functional is the in-thing now doesn't mean imperative is totally bad.
Nothing! The problems occur when people think that it's not.
And I really disagree with your hipster comment. You can indeed accomplish any task with Java, but that is damning with faint praise. The question is whether or not the environment gives the programmer adequate refactoring pressure to guide his decisions. Java provides almost no such pressure, resulting in a mess.
Many problems have been solved in Java despite of this, not because of it.
> Nothing! The problems occur when people think that it's not.
I don't really understand what you are trying to get at. Is it wrong or it isn't?
The hipster comment is spotted on. This post is evident of that attitude. The OP has to dig up an internal class whose name is probably generated to bash Java. And your original comment basically went further and claimed this long class name is the evident of what is so wrong with Java in general.
If there's no pressing pressure to refactor, then it has work well for its purpose. You want to limit class name to 8 characters to force programmers to pick shorter name? It's an internal class, for god sake. What's the impact on 99.99% of the programmer out there?
Development is a process of compromise and trade-off. Developers don't have infinite time and infinite budget to code. They have to pick their battle and do the more important things.
1. You seem to know what most Java programmers think. What do Java programmers think of Java as if not imperative? And what is the thing that they assume Java to be leads to problems? Again what specific problem is the long class name causing?
2. Thank you for correcting my grammar. BTW the period goes inside the quotation marks as in "spot on."
3. While not often used, generated source code are useful as design calls for it. Not everything revolves around static and dynamic.
2. Both styles are valid and used (just be consistent about it in a single body of text). Arguably the period after the quotation marks more closely matches the actual sentence structure.
One can argue that this is the result of ignorance, that "good" Java programmers will avoid this trap. And yet, for all it's restrictions, it doesn't give much refactoring guidance. The proliferation of patterns (both for creation and relation) in Java is a weakness, not a strength, and the result is monstrosities like this. Training, experience and convention avoids these traps, but why do we create new languages if not to reduce the amount of training, experience and convention that a programmer needs to learn in order to be productive with an environment?