Re: What Are Your Java Pain Points, Really?
Posted: Feb 16, 2007 1:41 PM
> > I think method overloading is an incredibly bad idea,
> > exactly because it introduces this sort of complexity
> > while providing almost nothing in return. Even in the
> > current language, reflection/introspection has all this
> > expensive, added baggage, which exacts a significant
> > performance penalty and greatly complicates the API.
> There is no performance penalty for the use of overloading
> in Java. It is compiled by the JIT into zero-lookup
> execution because it get statically bound at that moment.
Right. Overloading exacts a performance penalty for dynamic method lookups. But isn't that what I just said?
> If you use introspection at runtime, then you have to
> "find" the method. At issue is whether it makes more
> sense to code with overloading, or extended method names.
> We've heard some people complain about more text.
> . without overloading, there would have to be a different
> method name and still the same text representation of the
> arguments to that method. So, those who don't like to
> type text, would perhaps create unfavorable or obtuse
> method names that would add to the problems of
> understanding the software a the source level.
It probably doesn't make sense to hold the language designers hostage to the practices of lazy or incompetent developers though, does it? Nor to let fundamental language design decisions be determined by whether a subset of developers (hm, possibly the same group from above ;-) will whine about them?
> > On the other hand, there are optimizations that can be
> > done to reduce some of the overhead,
> The JIT compilers are quite good at eliminating pretty
> much any runtime resolution of namespaces. See my earlier
> post about changing the JIT configuration to compile
> methods after many fewer entries than the client default
> of 1500. That can optimize a lot of things quickly on
> smaller programs. Larger programs might benefit from the
> longer delay to compilation.
> As I stated, one of my clients sped up by 75% at startup
> when I switched 100 entries. The Netbeans IDE doesn't
> really get faster with such a change that I can tell
> because there is so much code run at startup, that
> compiling it all is much more expensive than interpreting
I'm puzzled. How does this improve the performance of runtime method lookups?
> I'd say that the software architecture and development
> process is at fault then. Interfaces are meant to be
> public contracts. If you don't design them with
> everyone's input and then make them publically visible,
> then you don't get much benefit from using them.
It's not that interfaces can't be useful in the way you describe; my point is that interfaces are not a one-size-fits-all solution. They provide some limited compile-time API checking, but they don't guarantee that the methods in question have the right semantics or that they're safe to call; they can only guarantee existence.
However, if Java had a better reflection implementation (especially if it were built directly into Object), it would be trivial to check for method existence at runtime. So in cases where there's widespread agreement on an API set that's likely to be invariant over time, by all means use an interface and take advantage of compile-time checking. For all the other cases, though, why not use runtime binding? Having something as inflexible as an interface is useful for APIs that are never likely to change, but really doesn't provide much value in other situations.
> There are mulitple types of interface uses. Certainly if
> you're designing some kind of listener registration and
> eventing, that model is pretty well recognized in the Java
> world, and people know how to use such things. If, you're
> design a more complicated system where an interface is an
> SPI or something more extreme, there are numerous issues
> to deal with. Interface versioning also has to come into
> play. It is usually better to leave methods out of an
> interface if you are unsure, and create subclasses of the
> interface to add new functionality then to include the
> whole enchilada because you are not sure of the exact
> usage patterns.
> This is not an easy task, but it is necessary step to
> really get something out of having an interface.
Or, you could just not use an interface at all. It's possible to use Java's current reflection capabilities to work around its lack of support for dynamic binding, and like most Java framework designers, I often find myself doing just that, but it's an awful lot of extra work. So if it takes Java framework developers on average five to ten times longer to do the same work as their brethren in the Objective C world, that would be a bad thing for Java, no?
> > Most of the Java projects
> > I've personally witnessed -- including massive ones with
> > budgets of hundreds of millions of dollars -- have
> > suffered from astonishingly poor design. Many of them have
> > failed utterly. That's real pain for you!
> Okay, so this sounds like a training and execution issue
> more than a Java issue. Are you wanting Java to protect
> you from this kind of thing?
No, but I'm hoping for Java to improve enough to give some of these teams a fighting chance. I do think that the design of the Java language itself contributes in significant ways to the appalling lack of sophistication I've observed in the wild when it comes to OO design. And it is definitely design, or the lack thereof, that is killing these projects, IMO, and the costs of that are absolutely staggering.
> Unfortunately the internet caused a huge swell in the need
> of software engineers. Unfortunately, most IT departments
> seem to equate software developers with software
> The end result is that we have way too many inexperienced
> and/or untrained developers trying to engineer software
> systems that are large and/or complicated.
In my experience, it's primarily the so-called 'architects' and lead developers -- the guys (and gals) who are supposedly 'experts' at Java development -- rather than the rank and file developers who have been the real culprits.
> I don't use J2EE/App servers.
Well then consider yourself very blessed. ;-) That's an option that many of us don't have.