Weblogs Forum - What Are Your Java Pain Points, Really?

Articles |
News |
Weblogs |
Books |
Forums

Artima Forums | Articles | Weblogs | Java Answers | News

Sponsored Link •

Weblogs Forum
What Are Your Java Pain Points, Really?

264 replies on 18 pages. Most recent reply: Jan 17, 2008 7:07 AM by GJ sonke

Welcome Guest
Sign In

Back to Topic List

Reply to this Topic

Search Forum

Threaded View


Previous Topic		Next Topic

Flat View: This topic has 264 replies on 18 pages [ « | 1 ... 7 8 9 10 11 12 13 14 15 ... 18 | » ]

Jonathan Lehr

Posts: 18
Nickname: jlehr
Registered: Jan, 2004

Re: What Are Your Java Pain Points, Really?

Posted: Feb 15, 2007 7:30 PM

> As for mixing...what would that look like? On one hand you
> could write a Java program that uses no types, but on the
> other you could write one that is strongly typed? I'm not
> sure if the ideas mix well, if you are interested in
> executing methods regardless of type, how could there ever
> be compiler errors for mis-matched method calls and/or
> method parameters? Would there ever be? Wouldn't that
> defeat the purpose of having a strongly-typed option?

Well, there's probably more than one way to do it, but you might want to take a look at Objective C to get a better feel for how this might work. Essentially, a new datatype would be added (in Objective C, it's called 'id'). Static typing would work as before. The compiler would allow messages to dynamically typed objects to be resolved at runtime.

Developers would then be free to use static typing wherever they chose to (in order to allow the compiler to report errors), and use dynamic typing wherever it was expedient. That wouldn't defeat the value of strong typing; it would simply allow an alternative for those relatively rare cases where dynamic typing was a better fit.

Hopefully the language would add improved reflection facilities to support run-time checking in lieu of compile-time checks to make it easier to avoid calling a method on an object that doesn't implement it. Objective C provides an additional facility called 'forwarding' that allows the runtime to handle the equivalent of NoSuchMethodExceptions by invoking a forwardInvocation() method on the instance, passing in the method invocation, and thus allowing the instance to attempt to resolve the message another way.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: What Are Your Java Pain Points, Really?

Posted: Feb 16, 2007 6:10 AM

> Not kidding myself. WebObjects is a framework, not a
> language.

How do you make use of it? Do you write straight Java code or something else?

> > I really don't see how using XML or something
> > similar to coordinate Java Objects in an dynamic way is
> > any different than using a dynamic language like Jython
> to
> > coordinate Java Objects in a dynamic way.
>
> You totally lost me here. Does this have something to do
> with WebObjects?

Perhaps I am misunderstanding. I have no experience with WebObjects so I am using this reference:

http://en.wikipedia.org/wiki/WebObjects

I that article, there is this quote:

"The WebObjects Framework (WOF) is at the highest level of the system. It is responsible for the application's user interface and state management. It uses a template-based approach to take that object graph and turn it into HTML, or other tag-based information display standards, such as XML or SMIL..."

This sounds a lot like Spring to me. If this is not what you are talking about, maybe you could humor me and explain.

Mitchell Stewart

Posts: 7
Nickname: mstewart
Registered: Jan, 2006

Re: What Are Your Java Pain Points, Really?

Posted: Feb 16, 2007 6:57 AM

> Well, there's probably more than one way to do it, but you
> might want to take a look at Objective C to get a better
> feel for how this might work. Essentially, a new datatype
> would be added (in Objective C, it's called 'id'). Static
> typing would work as before. The compiler would allow
> messages to dynamically typed objects to be resolved at
> runtime.

I'm understanding your position now, because the choice is in the developer's hands in terms of which one they want to use. I have no experience in Objective C, so I'll have to take a look to see how they implement the mix, but this basic explanation I think shows that they could co-exist without stepping on each other.

> Hopefully the language would add improved reflection
> facilities to support run-time checking in lieu of
> compile-time checks to make it easier to avoid calling a
> method on an object that doesn't implement it.

I also agree with this as well, I would like to see a more "convenient" set of reflection libraries. This might even be a quicker path to a more dynamic Java...without a "true" dynamic runtime being available. But to your point, it wouldn't be the "real thing".

Gregg Wonderly

Posts: 317
Nickname: greggwon
Registered: Apr, 2003

Re: What Are Your Java Pain Points, Really?

Posted: Feb 16, 2007 6:58 AM

> > I'd guess that, in general, my programs would run slower
> > with dynamic binding because there would be more time
> > spent deciding what method to call. With overloaded
> > methods, it's necessary to check all the types of all the
> > arguments and that includes classloader comparisons and
> > several other steps which go beyond a simple "method by
> > name is implemented" check.
>
> 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.

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.

> 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 it.

> but I agree that classloaders do complicate the picture.

Classloaders provide for mobile code, which is a premier feature of Java. If you are not using this to dynamically update and manage your software systems, then you might not see the power. I find that other uses of Classloaders in J2EE systems and other places where they restrict what you do to be frustrating. The Jini PreferredClassLoader lets you control your "platform" directly so that you always resolve classes to the preferred classloader (app or codebase).

> > Maybe you can share why interfaces don't work for you?
>
> That's neat if you're the only one writing the code. Most
> of the projects I've worked on are more complicated than
> that, often involving integrating code from other project
> teams and third parties that may not have access to my
> interface.

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.

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.

> > I hear a lot of people talk about how many keystrokes or
> > how much text. If keystrokes and text bulk were not the
> > issue, what would the real issues be that would make
> > dynamic typing really work better?
>
> OO Design, or the lack thereof. 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?

Unfortunately the internet caused a huge swell in the need of software engineers. Unfortunately, most IT departments seem to equate software developers with software engineers.

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.

> > I'm not having any problems using Java to solve a large
> > number of problems.
>
> The question in my mind is not whether or not individual
> developers feel they're able to use the language; it's
> whether Java is helping or hurting when it comes to
> software development in general.

Well, I don't think it's Java that is the problem directly. I think Java makes it easy for developers to use tools that they have no ability to use correctly and/or effectively. The end result is that Java gets the blame.

Java APIs allow several ways to do things, and there are numerous ways to do things "wrong". Only through proper training and with some experience can we all have the ability to "get it right". I still refactor and rewrite software in production systems which is not working effectively. It's what you have to do to make large scale systems successful. Even some small systems have problems related to certain usage patterns which will need very specific optimizations.

I like Java because I can, in general, easily and trivially upgrade and redesign production systems to solve problems that I didn't forsee in the initial design/evaluation. I don't use J2EE/App servers. I use Jini and rely on mobile code as one of the ways that I solve problems related to distributed systems.

Nuwan Goonasekera

Posts: 32
Nickname: nuwang
Registered: Apr, 2006

Re: What Are Your Java Pain Points, Really?

Posted: Feb 16, 2007 7:46 AM

> 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.

Can u explain a bit more how you use interface versioning? Let's say you add a new method to an existing interface, You leave the old interface intact and create a new one. How do you name it for example? How do you phase out dependencies on the old interface? Do you utilize a factory method to provide the correct version? Would appreciate your experience on this.

> Unfortunately the internet caused a huge swell in the need
> of software engineers. Unfortunately, most IT departments
> seem to equate software developers with software
> engineers.
>
> 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.

Do you see external code/design audits improving this situation? Sadly, I don't know about customer demand for this and development houses that enforce it, but would like to know where it's effective.

Mark Thornton

Posts: 275
Nickname: mthornton
Registered: Oct, 2005

Re: What Are Your Java Pain Points, Really?

Posted: Feb 16, 2007 8:13 AM

> Can u explain a bit more how you use interface versioning?
> Let's say you add a new method to an existing interface,
> You leave the old interface intact and create a new one.
> How do you name it for example? How do you phase out

You only need a new name if you change or delete existing methods. For example, you can still use old JDBC drivers even though they don't implement all the extra methods in the latest version if the interfaces. Of course you get an exception if you use one of the unimplemented methods. Similarly old JDBC client code continues to work because those obviously don't use the new methods.

One caveat is that overloading is resolved at compile time, so if you add a new method with the same name as an existing method, newly compiled code may call a different method to existing class files. This can be a bit surprising.

Nuwan Goonasekera

Posts: 32
Nickname: nuwang
Registered: Apr, 2006

Re: What Are Your Java Pain Points, Really?

Posted: Feb 16, 2007 11:19 AM

> You only need a new name if you change or delete existing
> methods. For example, you can still use old JDBC drivers
> even though they don't implement all the extra methods in
> the latest version if the interfaces. Of course you get an
> exception if you use one of the unimplemented methods.
> Similarly old JDBC client code continues to work because
> those obviously don't use the new methods.

Yes. This is true at runtime, because in Java, the current interface version loaded determines what operations are available. Methods not actually implemented will simply raise a NoSuchMethodError. However, this will cause problems for interface consumers who actually wish to support older and newer versions of an interface simultaneously since it's not easy to predict which version of the interface has been implemented. Catching NoSuchMethodError and retrying would be expensive.
In addition, other languages may not exhibit the same behaviour (I believe C# does not, but I'm really not sure).

In addition, compilation of a code base could break in its entirety if a dependent interface was changed in anyway. In a framework for example, all users of the framework would be affected if a trivial interface change is made and not everyone is really ready to support that change.

I assumed that this is the kind of situation that Greg mentioned? How is this kind of situation best dealt with? The common approach appears to be to subclass the existing interface and create a new interface with the additional behavior, but this makes things complicated for everyone in the long run...

Nuwan Goonasekera

Posts: 32
Nickname: nuwang
Registered: Apr, 2006

Re: What Are Your Java Pain Points, Really?

Posted: Feb 16, 2007 11:38 AM

> One caveat is that overloading is resolved at compile
> time, so if you add a new method with the same name as an
> existing method, newly compiled code may call a different
> method to existing class files. This can be a bit
> surprising.

I don't want to imagine debugging a problem like this :) I guess this is because of the lack of versioning support for dependencies, something that .NET seems to have addressed after observing the effects.

Jonathan Lehr

Posts: 18
Nickname: jlehr
Registered: Jan, 2004

Re: What Are Your Java Pain Points, Really?

Posted: Feb 16, 2007 12:06 PM

> How do you make use of it? Do you write straight Java
> code or something else?

WebObjects is a component-based web application framework that incorporates a sophisticated ORM, HTML templating capabilities, and more -- think of it as Struts + Spring + Hibernate (or more accurately, Tapestry + HiveMind + Cayenne). It allows developers to use HTML templates marked up with simple custom HTML tags as an alternative to JSPs. (In fact, WebObjects predates JSP technology by a good bit).

XML metadata is used to define bindings from the markup to Java object properties and methods, and also to store an Object-Relational model (typically maintained via a GUI tool). There also used to be tool support for the UI bindings, but I haven't looked at WO in a while, so I'm not sure that's still there.

At any rate, the XML metadata doesn't script UI behavior, it just provides a way to externalize settings so that they can be maintained outside the Java code, so they're analagous to properties files rather than constituting a language, which is what I think you were originally questioning.

Todd Blanchard

Posts: 316
Nickname: tblanchard
Registered: May, 2003

Re: What Are Your Java Pain Points, Really?

Posted: Feb 16, 2007 12:26 PM

> 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.

You mean there is no *runtime* performance penalty for using overloading in Java. There is, IMO, an enormous cognitive and developer productivity penalty as it makes people lazy about naming, requires excessive back tracking to determine actual types when reading code, etc...

> 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.
...
> 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.

You mean like the developers of the core libraries? The most egregious example I can come up with is in Map's

Object put(Object key, Object value)

the worst method name in the entire java library, it totally obfuscates what it is doing when viewed in the wild:

stuff.put(thing1,thing2)

a far better name that would be descriptive would be

stuff.atKeyPut(think1,thing2)

which is, as you say, more typing, but infinitely more comprehensible. The people who complain about typing aren't complaining about typing, they are complaining about zero value typing like:

MyThing thing3 = (MyThing) map.get(thing1).

The cast is zero value add and totally pointless.

The compiler knows the type of thing3. It knows that get() returns Object. It knows that I'm going to add that cast to shut it up after it prints its error (there is no other reasonable thing to do). Adding the cast introduces a runtime type check that will return a runtime error if map returns something that isn't a MyThing.

So, YTF does it not shortcut all this noise and just insert the runtime check automatically and leave me the hell alone?

This is the thing that I despise about Java. No foresight at all. It has lots of lame rules where, if you do a little behavior analysis and think things through, you can see the result of having the rule - so just implement the result.

Gregg Wonderly

Posts: 317
Nickname: greggwon
Registered: Apr, 2003

Re: What Are Your Java Pain Points, Really?

Posted: Feb 16, 2007 12:26 PM

> Yes. This is true at runtime, because in Java, the current
> interface version loaded determines what operations are
> available. Methods not actually implemented will simply
> raise a NoSuchMethodError. However, this will cause
> problems for interface consumers who actually wish to
> support older and newer versions of an interface
> simultaneously since it's not easy to predict which
> version of the interface has been implemented. Catching
> NoSuchMethodError and retrying would be expensive.
> In addition, other languages may not exhibit the same
> behaviour (I believe C# does not, but I'm really not
> sure).

Yes, I don't enjoy this particular aspect of JDBC development when I need to fix an old version of the postgresql driver for example which I am using on JDK1.5 and now it won't compile and I have to go download an old JDK to build it.

> In addition, compilation of a code base could break in its
> entirety if a dependent interface was changed in anyway.
> In a framework for example, all users of the framework
> would be affected if a trivial interface change is made
> and not everyone is really ready to support that change.

This is a real pain for sure.

> I assumed that this is the kind of situation that Greg
> mentioned? How is this kind of situation best dealt with?
> The common approach appears to be to subclass the existing
> interface and create a new interface with the additional
> behavior, but this makes things complicated for everyone
> in the long run...

What I do, is copy all methods from the old interface into the new interface, and then add the new methods which I need. Then, I subclass the old interface, and now I have a new interface with full definition of all methods. This allows me to remove the "extends" clause at some point when I want the old interface name to disappear.

Many times, I put the new interface into a new package and reuse the old name. Sometimes this doesn't make sense, and I have to be more creative in my naming choices.

Jonathan Lehr

Posts: 18
Nickname: jlehr
Registered: Jan, 2004

Re: What Are Your Java Pain Points, Really?

Posted: Feb 16, 2007 12:33 PM

> I also agree with this as well, I would like to see a more
> "convenient" set of reflection libraries. This might even
> be a quicker path to a more dynamic Java...without a
> "true" dynamic runtime being available. But to your point,
> it wouldn't be the "real thing".

Yep, I'm with you on that -- improving reflection could potentially make a huge difference in and of itself, and it really ought to be done. However, rather than simply improving the existing libraries, I'd much prefer to see most of that functionality migrated directly to the Object and Class classes themselves.

I think the Java spec leads could draw much inspiration from WebObjects's KeyValueCoding design for ideas about API design, as well as such notions as delegation of core methods, method caching using string-based selectors, etc. How convenient would it be to simply be able to do something like the following?


public void doSomething(Object someObj)
{
    Object value = someObj.valueForKeyPath("person.address.street");
    if (value != null) {
        // Obviously, we could be doing something more meaningful here...
        System.out.println("Street adress: " + value);
   }
}

Or something like this?


public void doSomethingElse(Object someObj)
{
    if (someObj.respondsTo("addPerson(us.semblance.model.Person)") {
        someObj.addPerson(new Person());
    }
}

Gregg Wonderly

Posts: 317
Nickname: greggwon
Registered: Apr, 2003

Re: What Are Your Java Pain Points, Really?

Posted: Feb 16, 2007 1:04 PM

> > 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.
>
> You mean there is no *runtime* performance penalty for
> using overloading in Java. There is, IMO, an enormous
> cognitive and developer productivity penalty as it makes
> people lazy about naming, requires excessive back tracking
> to determine actual types when reading code, etc...

These days, IDEs provide tools that help you do such code analysis. In a cold world where overloading is overused, it can be very difficult to track down which method is being called.

> stuff.put(thing1,thing2)
>
> a far better name that would be descriptive would be
>
> stuff.atKeyPut(think1,thing2)

I'd have no problem with such a new method being created. Maybe you can suggest it and see what might actually happen. It is strange how hindsight is 20/20, and backward compatibility trumps correctness.

> which is, as you say, more typing, but infinitely more
> comprehensible. The people who complain about typing
> aren't complaining about typing, they are complaining
> about zero value typing like:
>
> MyThing thing3 = (MyThing) map.get(thing1).
>
> The cast is zero value add and totally pointless.

Casting is a necessary evil.

public class Bar extends Base implements Renderable {
 
  public String render() {
    return val1+": "+val2+", xx="+xx;
  }
  public String toString() {
    return val1;
  }
}
 
public interface Displayer {
    public void show( Base b );
    public void show( Renderable );
}

In the above situation, how do you tell which Displayer.show() to call for instances of Bar?

This is a very common pattern that shows up in GUI applications. You use toString() early on for showing components in a view, and then decide that you need more power, so you create an interface with a String valued method to get the representation and tack that onto new classes, leaving the old toString() use in place.

In some cases, you might need to call the Base version and in others the Renderable version. Casting makes that possible.

The simple fact that typing is that explicit means that assignment represents a narrowing operation. Casting lets you agree with the compiler how narrow you want to go.

> So, YTF does it not shortcut all this noise and just
> insert the runtime check automatically and leave me the
> hell alone?

For the most obtuse and complicated cases it has not near the knowledge that you do about your intent and needs. The type checking, casting and basic structure of the Java type system provides a lot more power. As I said in my earlier post. There are way to many people (and I'm not pointing any fingers) who just don't have enough knowledge or experience to use this power effectively or correctly.

In your case, you are perhaps not interested in using some of these features, and so the controls that make them possible get in your way.

> This is the thing that I despise about Java. No foresight
> at all. It has lots of lame rules where, if you do a
> little behavior analysis and think things through, you can
> see the result of having the rule - so just implement the
> result.

In general, Java language rules provide the ability to solve many different classes of problems which don't occur in other untyped or dynamically typed languages. The "issues" themselves are born out of the controls and constructs neccesary to present other features/capabilities.

As an example illustration that is just guessing, consider that method overloading was really just a fallout from the fact that it would be required for operator overloading to be implemented. Type resolution could be done at compile time, or runtime. The initial platform for Java was a small device that was relatively lightly powered compute wise. This would mean that it would be better to do type resolution on the compile phase instead at runtime.

So, we get compile time type resolution as a fallout of all the assorted circumstances. I think it's really not very interesting to belittle people involved in the initial development of Java. All that I've talked to (and I've talked to most of them personally), really have strong feelings about many of the choices (in hind sight) that were made. Fault is easy to find. I feel, for myself, that it's really time to step up and be part of the solution. I've tried to provide new APIs wrapping old functionality to solve many of the pain points that I encountered early on.

Here are some example projects related to the core Java APIs.


http://packer.dev.java.net
http://swingutil.dev.java.net
http://javadns.dev.java.net
http://sqlfactory.dev.java.net

The APIs can be fixed or worked around. You can always do something like the following to "fix" your issue with Map.

public interface BetterMap<K,T> extends Map<K,T> {
    public void atKeyPut( K key, T obj );
}
 
public class MyMap<K,T> 
        extends HashMap<K,T>
        implements BetterMap<K,T> {
 
    public void atKeyPut( K key, T obj ) {
        put( key, obj ); 
    }
}

This is simple change to existing source that will expose a new namespace which can make it easier to read code. But, then you have introduced another type that people will have to chase down, and then some will likely ask why you couldn't just get by with "put" instead :-)

API things can be easy to "fix". It's language issues which we can likely "never" fix because of compatibility. Missing features can sometimes be added. Wrong features can never be removed...

So we really need to solve API problems with APIs, not language changes.

Jonathan Lehr

Posts: 18
Nickname: jlehr
Registered: Jan, 2004

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
> it.

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
> engineers.
>
> 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.

Todd Blanchard

Posts: 316
Nickname: tblanchard
Registered: May, 2003

Re: What Are Your Java Pain Points, Really?

Posted: Feb 16, 2007 3:27 PM

> These days, IDEs provide tools that help you do such code
> analysis.

I do remote code maintenance - I have vi on an xterm. That is what I can count on. "Better tools" doesn't cut it.

> > stuff.put(thing1,thing2)
> >
> > a far better name that would be descriptive would be
> >
> > stuff.atKeyPut(think1,thing2)
>
> I'd have no problem with such a new method being created.
> Maybe you can suggest it and see what might actually
> y happen. It is strange how hindsight is 20/20

Lots of folks had this "hindsight" the year java was released. Bloch actively defended it when attacked for it (by a colleague of mine who is a Smalltalk expert) at the unveiling at JavaOne many years ago. Apparently, nobody at Sun cares.

> Casting is a necessary evil.

No its not.

I find it really interesting that your defense of casting involves method overloading. Seems that bad features tend to encourage additional bad featiures. This would be a non-issue if you were to use a more descriptive name.

> public interface Displayer {
> public void show( Base b );
> public void show( Renderable );
> }

> In the above situation, how do you tell which
> Displayer.show() to call for instances of Bar?

You pick better names like 'render" for showing renderables and showBase for base. Again, you're using one rotten feature to justify the use of another.

> This is a very common pattern that shows up in GUI
> applications.

Not my GUI applications it doesn't.

> In some cases, you might need to call the Base version and
> in others the Renderable version. Casting makes that
> possible.

At the point that you cast - you are naming the method you want explicitly. There is zero advantage in the methods having the same name at this time. It is two facets of the same activity.

> The simple fact that typing is that explicit means that
> assignment represents a narrowing operation. Casting lets
> you agree with the compiler how narrow you want to go.

I already told it how narrow I want to go in the variable declaration or the method interface description. I don't care to tell it again.

> For the most obtuse and complicated cases it has not near
> the knowledge that you do about your intent and needs.

You're going to have to come up with an example that doesn't involve method disambiguation caused by overloading to convince me.

> In general, Java language rules provide the ability to
> solve many different classes of problems which don't occur
> in other untyped or dynamically typed languages.

Read that again. "Java provides the power to solve the problems caused by Java?" Now read that in your best John Stewart voice.

Funny stuff.

These shortcomings were clearly evident and well understood in the C++ type system. Repeating the errors in Java is just plain unforgiveable.

Flat View: This topic has 264 replies on 18 pages [ « | 7 8 9 10 11 12 13 14 15 | » ]

Previous Topic

Next Topic