No offense, Chalain,
None taken. I will rebut, however.
but if I'm reading this correctly, it's the (non-standard) error logging and database libraries that your company is using which you should be bitching about, not the language itself.
You are reading it wrong. The logging system is log4j, a very fast and quite standard logging system. The database is jdbc, with a custom query layer written for it. However, nothing in that function relies on that code. It just happens that the HashSet I was working with there was keyed by a string contained in resultSet.
All that method does is get a value from a hash, or a default value if it is missing. And it needs 10 lines of code to do it.
But there are reasons why the language works the way it does, even if those reasons are really applicable to the situation you're in.
I think most of those reasons are well-considered, sensible, and outmoded. Java's greatest accomplishment was getting people to realize that a garbage collected, interpreted language really could be used to write Real Programs. Lighter-weight, scalable languages like Python and Ruby have followed in its sheltering wake, and are now emerging and challenging many of the concepts we converted to when Java challenged C++ a decade ago.
This a topic for a whole 'nother thread.
Perhaps the real problem is that Java is too heavyweight for what you're doing - using a nuke to swat flies.
Not really. Our project is of sufficient complexity that it requires a full-blown application. Also, as mentioned in the OP, the problem is that the fly I'm trying to swat is to get a value, or a default value, out of a hash by key without having to write a novel.
Consider the same code in Ruby:
# assume @selectExpansionCache was initialized with Hash.new("")
def expanded_select resultSet
return @selectExpansionCache[ resultSet.signature() ]
That's so succinct it almost doesn't need a wrapper function to enclose it. The Hash.new method in Ruby takes an optional default value that the hash will return if a missing key is read. In Python, you have to hand the default value in with every call, but that is also still extremely readable:
def getExpandedSelect( resultSet ):
return selectExpansionCache.get( resultSet.getSignature(), "" )
I concede that similar code can be achieved with Java. But only by writing my own HashSetWithDefault class, and adapting everything that selectExpansionCache touches to use the new class.
Java scales up quite well, but scales down rather less so; it's optimized for massive, distributed systems, being written by dozens of coders working independently (which is ironic when consider it was originally meant for embedded software). In this regard, it really is in many ways more like Ada than like C++ or Smalltalk (both of which are over-engineered in their own ways). Of course, if this is from a really large project - and it sounds like it is - then I hate to say it, but a certain increase in complexity is the price of scale, regardless of the language.
The project I am on is large enough to require a non-toy language, it is true. I occasionally talk Ruby or Python or smaller languages here because I dabble all across the board... this is why I take no offense at your earlier comment. Yes, I really am working on real software.
Java's problem isn't that it doesn't scale down, it's that it cannot maneuver well in tight spaces. This is a fatal flaw in my mind because, at the end of the day, every program eventually must be broken down into small pieces.
A few days ago I was at the bookstore. They had Java In A Nutshell there. It was THREE INCHES THICK. 1,224 pages. Does no one besides me see the inherent lie in the language?
I've said it before, and here it is again: "If Java is the answer, it must have been a really