Smells Like Java

Sometimes, there are issues that seem to be strongly tied to a particular ProgrammingLanguage and some particular ApplicationProgrammingInterfaces.

OK, I'll bite. Name two.

It would be good to know what this page means! When I try to think of JavaLanguage smells, they usually exist in other languages too

I don't know what the original poster meant, but the phrase "smells like Java" makes sense to me.

A lot of the time, I hear people talking about various techniques or patterns that exist solely because of limitations of the ProgrammingLanguage they're using. I hear a lot of talk about "iterator objects" and "factory objects" and "accessor methods". Just the other day my father asked me, "So, do you think it's a good idea to always use factory methods?" In some languages, you'd never ask that question, because the problem that factory methods solve doesn't even exist. It only exists in Java because "new Something()" is always a hard-coded reference to the Something class.

These kinds of smells appear in every language, but some languages have more of them than others. The JavaLanguage happens to be popular right now, and it also happens to be a very restrictive language, so I get this feeling more often with Java than with anything else these days.

-- AdamSpitz

With a little bit of luck, some kind soul is going to put some words to that funny feeling I have about JavaLanguage, but for now I'm just going to have to put up with the smell instead!

Describe this feeling? What kinds of Java experiences evoke this feeling?

 Someobject someobject = (Someobject)someobjects.elementAt(i);

What part of this SmellsLikeJava to you? Casting? The lack of generics? Plenty of languages meet either of those criteria.

It's not TypeSafe, it's hideously verbose, it's manually mucking about with list indices, and it doesn't even let you use the square-bracket syntax to do it. Yup, SmellsLikeJava to me. Smells like poorly written Java, to me.

How much SyntacticSugar do you need? At least now, Java has generics [JavaGenerics]:

 List<Someobject> someobjects; 
 Someobject someobject = someobjects.get(i);

Re: How much SyntacticSugar do you need?

The syntactic sugar isn't the problem. I'm fairly certain that any statically-typed language using manifest typing will have similar issues. However, Java code, professionally written and amateur alike, well-written and horridly written alike, all have code in it that follows the pattern XYZ xyz = (XYZ)xyzSource.acquire(), for any XYZ you care to mention. Generics simply do not help with this; notice the generics example above is actually more verbose than the first line.

What Java needs to not smell like Java is a touch of functional programming, where this kind of code simply never occurs, because the language is better equipped to handle construction or acquisition of values. Another approach towards solving this rampant verbosity is to adapt Java to support some kind of destructor or finalizer mechanism, and use ResourceAcquisitionIsInitialization, so that some cases of the above pattern can be shortened: Timer timer = new Timer(); simply becomes Timer timer;. Or, we can take a page from the book of SatherLanguage, and remove some of the manifest typing: Someobject someobject = (Someobject)someobjects.elementAt(i); becomes someobject ::= (Someobject)someobjects.elementAt(i);. Note the "::=" operator -- it's a very small amount of syntactic sugar that truly can positively impact a programmer's experience with the language. -- Samuel A. Falvo II

When something SmellsLikeJava, do we mean that it is a JavaLanguage-specific CodeSmell, or simply a JavaIdiom? The name implies the former, but I'm having trouble coming up with anything but the latter.

The way I think of it, it's sort of a cross between the two, in a specific kind of ugly way. A lot of the time, we use the word "idiom" or "pattern" to mean "smell that the language doesn't let me fix." I've put some examples on the LanguageSmell page.

I don't mean to say that these issues are entirely clear-cut - there are probably performance penalties to worry about, and some cultural things too. (I suspect that some JavaProgrammers wouldn't want their co-workers to have this much power and flexibility.) But there are a lot of people out there spending time thinking and learning and arguing about these issues, and I wish that more of them realized that they're just working around the limitations of their ProgrammingLanguage.

I'd like to get rid of this page altogether, and just use the LanguageSmell page. It's fun to pick on JavaLanguage :), but this kind of thing really does happen in every language.

-- AdamSpitz

That last part is close to the point I was trying to get at. In my mind it's more useful to think about ProgrammingLanguage characteristics and the idioms they might imply. Something doesn't "smell like CeePlusPlus", but it may "smell like MultipleInheritance", or better still, we have "multiple inheritance idioms". Very rarely will a language name be the most precise way of describing the "smell".

(To provide my own counter-example, Integer/int and the hoops one must jump through to deal with them might be associated the CeePlusPlus/JavaLanguage family of languages more than most. Most-but-not-all-things-are-objects?)

The GangOfFour thought factory to be a useful idiom, and they were working with SmallTalk. Clearly there are languages in which factory is a useful concept, and languages in which it isn't. What distinguishes the former from the latter? It's certainly not the letters j-a-v-a.

Good points. I've tried to refactor the above discussion into less of a ThreadMode kind of thing, because I agree with most of what you've said. -- AdamSpitz

SmellsLikeJava means that there is a problem which is not attached to any ProgrammingLanguage but the nature of the problem itself makes one think that it was made for JavaLanguage (in positive or negative).

This issue is not specific to Java (or even to programming). For example FunctionalRequirements for a program might not specify a certain database vendor but can include feature requirements that are only supported by a certain database. The person who made the requirements may have been prohibited from specifying vendors directly.

PublicStaticVoidMain SmellsLikeJava. I can't believe how many programming languages use it. Classes are not modules; classes are object factories, possibly with baked-in modules.

See LanguageSmell

CategoryJava