The Artima Developer Community
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

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 264 replies on 18 pages [ « | 1 ... 8 9 10 11 12 13 14 15 16 ... 18  | » ]
Gregor Zeitlinger

Posts: 108
Nickname: gregor
Registered: Aug, 2005

Re: What Are Your Java Pain Points, Really? Posted: Feb 17, 2007 2:51 PM
Reply to this message Reply
Advertisement
> I completely disagree with this. I find it much more
> complex to work with languages that try to address too
> many problems than to use focused, well-integrated tools.
I completely disagree with that.

> I wouldn't want Java to be attempt to be a database
> e querying language. I'd much rather use SQL in addition
> to Java.
So you think that Linq is not a great addition to C#?

I should add that I also don't buy the slogan "use the right tool for the job". In an ideal world, there would be one language that meets all of your programming requirements. You wouldn't have to learn new syntax/libraries when you program server/hardware/web/embedded, whatever. You may need different specialized libraries for some tasks, but that should be all.

Gregor Zeitlinger

Posts: 108
Nickname: gregor
Registered: Aug, 2005

Re: What Are Your Java Pain Points, Really? Posted: Feb 17, 2007 3:19 PM
Reply to this message Reply
> 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...
IMO, the opposite is true (regarding method naming). add_int(var),add_float(var) is harder to read than add(int) and add(float) (assuming you have a decent IDE).
When I have to come up with different names for essentially the same think, then I would probably lower my standard and become lazy.

Gregor Zeitlinger

Posts: 108
Nickname: gregor
Registered: Aug, 2005

Re: What Are Your Java Pain Points, Really? Posted: Feb 17, 2007 4:04 PM
Reply to this message Reply
> You're going to have to come up with an example that
> doesn't involve method disambiguation caused by
> overloading to convince me.
I think there are two distinct issues with casting

1) unnecessary verbosity
A a = (A) b;
could be written without the cast - the compiler could insert that cast for you - and I agree that this would be a good thing.

2) necessary verbosity (in a statically typed language)
call((B)a) vs. call((C)a)

Gregg Wonderly

Posts: 317
Nickname: greggwon
Registered: Apr, 2003

Re: What Are Your Java Pain Points, Really? Posted: Feb 17, 2007 9:21 PM
Reply to this message Reply
> > > 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.

Josh doesn't work for Sun any longer, so his voice is less loud in this community. He can be quite overbearing because he really is confident in his capabilities. You have to give him technical arguments, not emotional ones to get any form of agreement though.

> > Casting is a necessary evil.
>
> No its not.

It is in a statically typed language and in particular in for narrowing and in method overloading implementations as my example demonstrated. Sure, you don't need it for narrowing assignments. But widening does require casting.

I can tell that you are not a fan of method overloading. That's a pretty subjective topic with many pros and cons. The point is that Java has method overloading. It has static typing. This means that casting is a requirement to keep from posing unnecessary restrictions on what the programmer can actually do in their software.

Sure, there are alternatives. Classes could be designed with factory methods which cast various things. It could be that narrowing could be automatic on assignment, but it might now actually be the designed behavior, so I still find it better to need to do it explicitly in many cases.

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

The point is that Java has static typing and allows method overloading, plain and simple. Because of that, there are some things that are only possible through casting. One of those, is this specific narrowing. Base is not a Renderable, so when a Base subclass implements Renderable, the narrowing must be explicitly specified to make sure that the right method is called. The parenthesis are the only extra characters in

showRenderable( obj )

vs

show( (Renderable)obj );

> > public interface Displayer {
> > public void show( Base b );
> > public void show( Renderable r );
> > }
>
> > 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.

It's your view (and perhaps others) that method overloading is a "rotten" feature. I think it improves readability. I do try and use useful variable names. But, I'm really not sure that you see that this narrowing makes the called method unambiguous.
  dsp.show( vw )

vs
dsp.show( (Renderable)vw )

really makes it clear which one we are calling. It's only the widening binding that really creates the problem.
public void handlePaint( Renderable rend ) {
   dsp.show(rend);
}

should not create problems for understanding which show is called. The most narrow binding (closest type) is used.

> > This is a very common pattern that shows up in GUI
> > applications.
>
> Not my GUI applications it doesn't.

The use of varied rendering doesn't show up?

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

Well the subtle side effect, is that there might be several (or hundreds) of method calls to "show(Base)" which I can't or don't want to edit to say "showRenderer(...)". In many cases, I've been able to change a view method parameter types and it still compiles without such a huge editing impact. And it many cases, I might be using Generics anyway, and those I can change the Generic from Base to Renerable and get the correct mapping of which show() to call and get reuse without having to create parallel copies of some code just to use it for Base and Renderable types.

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

But in this case, you have a class that implements an interface. There is no logical narrowing that can occur. It must be specified explicitly because the method signatures create an ambiguity that must be resolved.

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

Okay, but I think you'll have to come to grips with the fact that overloading exists in Java, plain and simple. It was a design decision that was made. Because it's there, casting is necessary for method disambiguation. Because casting has to exist there, it is, I think less surprising to require it for assignment narrowing as well.

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

Humm, you might be understanding the issues I am trying to bring out better than I perceive. Yes, Java has language features that are related to each other. Because of method overloading, disambiguation has to be possible with casting. Because Casting exists for this reason, it can be used as a "tool" to solve other types of type "matching".

All of this, stacks up into the feature set of the language. I, personally find the APIs, cross platform portability, the stability of my applications due to GC (no explicit memory management), the features of threading and the new memory model to be far and away above and negatives which those "features" might seem to create.

Because I can reason through the dependency graph of these features, perhaps I'm not stressed about any particular "feature" and it's impact on my software.

The language features which I do find myself worrying more about these days are related to autoboxing. Autoboxing creates some object replacements which can change the mutability of certain values if you are not careful.

Nuwan Goonasekera

Posts: 32
Nickname: nuwang
Registered: Apr, 2006

Re: What Are Your Java Pain Points, Really? Posted: Feb 17, 2007 10:33 PM
Reply to this message Reply
> > Casting is a necessary evil.
>
> No its not.
>
> I find it really interesting that your defense of casting
> involves method overloading

Besides its use in method overloading, another commonly cited reason for casting is to explicitly declare the programmer's intention. This can help prevent accidental errors.

For example, consider the somewhat contrived situation below.

double total = order.getOrderTotal();

You declare a double to hold the return value of getOrderTotal, forgetting that it in fact returns a float. If the compiler implicitly converted the float to a double, you'd have a particularly nasty bug on your hands.

A similar case could be made for the map example you cited. The compiler brings a potential problem to our attention, allowing us to explicitly declare our intention.

I think casting helps to play to the strengths of a strongly typed system: allowing us to be aware of as many potential problems as possible at compile time instead of deferring them till runtime.

Todd Blanchard

Posts: 316
Nickname: tblanchard
Registered: May, 2003

Re: What Are Your Java Pain Points, Really? Posted: Feb 18, 2007 6:33 PM
Reply to this message Reply
> Besides its use in method overloading, another commonly
> cited reason for casting is to explicitly declare the
> programmer's intention. This can help prevent accidental
> errors.
>
> For example, consider the somewhat contrived situation
> below.
>
> double total = order.getOrderTotal();
>

....
I believe this is perfectly OK as it is type promotion. Did you mean to go the other way - assign a double return value to a float variable?

Also, object reference type conversion is inherently different from primitive type conversion.

Nuwan Goonasekera

Posts: 32
Nickname: nuwang
Registered: Apr, 2006

Re: What Are Your Java Pain Points, Really? Posted: Feb 18, 2007 7:19 PM
Reply to this message Reply
> I believe this is perfectly OK as it is type promotion.
> Did you mean to go the other way - assign a double return
> n value to a float variable?

Sorry. My Bad. I was writing "double" but thinking "long" all along ;)

>
> Also, object reference type conversion is inherently
> different from primitive type conversion.

Because primitive type conversion can be lossy and object conversion not so? However, isn't converting an "Object" type to a more specific type also a potentially awkward situation? Isn't it better if the compiler bring our attention to the exact return type of a method, so that we can explicitly declare our intention to cast it to a more specific type?

Todd Blanchard

Posts: 316
Nickname: tblanchard
Registered: May, 2003

Re: What Are Your Java Pain Points, Really? Posted: Feb 18, 2007 7:48 PM
Reply to this message Reply
> Josh doesn't work for Sun any longer, so his voice is less
> loud in this community. He can be quite overbearing
> because he really is confident in his capabilities. You
> have to give him technical arguments, not emotional ones
> to get any form of agreement though.

It is hard to make a technical argument based on readability/understandability.

> I can tell that you are not a fan of method overloading.

I've spent a lot of time looking at different languages and trying to do root cause analysis to sort of retrace the design process. I have found that there is a LOT of interaction behind "features" and an unhealthy proportion of features that are just there to smooth over the unintended consequences of early design decisions that, in retrospect, maybe weren't such a hot idea. Its like starting a chess game with a bad opening - the end result is preordained in the first few moves.

So while I seem to be mostly a (possibly unreasonable) grouchy sort with a strong set of prejudices against Java and C++, my opinions are based on real experiences and trying to understand what it was about those languages that resulted in my impact with the wall and ultimately abandonment of these languages.

In this case, I think I can argue that method overloading is a gimmick that lacks substantial benefit, but costs us the inconvenience of casting object references.

> The point is that Java has static typing and allows method
> overloading, plain and simple. Because of that, there are
> some things that are only possible through casting.

Right, this reinforces my point

> It's your view (and perhaps others) that method
> overloading is a "rotten" feature. I think it improves
> readability.

I find that it impairs it and that surprising interactions can emerge over the life of the system with type hierarchy refactorings.

I find it produces fragile code as more types are added to the system and it becomes less and less obvious exactly which overload is getting called. Ambiguities creep in.

A better solution to this problem would be to use double dispatch to do the narrowing polymorphically in an error free way. After all, you could get the cast wrong and the compiler will let you proceed. Double dispatching will allow you to avoid casting and still work in a type safe manner.

> The use of varied rendering doesn't show up?

Casting for method disambiguation doesn't show up.

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

Double dispatch does the same without circumventing your type system.

> Okay, but I think you'll have to come to grips with the
> fact that overloading exists in Java, plain and simple.

Yes, it is there. I would consider casting to get a specific overloaded method called to be really bad practice though. And then there's my initial example that nobody has addressed.

Thing thing3 = map.get(thing2);

This results in a narrowing that the compiler will complain about. However there are only two possible ways to handle this error.

1) I wrote the code wrong.
2) I said what I mean, will just end up adding the cast to shut up the compiler.

99% of the time, 2 is the case. Furthermore, most of the time that case 1 does occur, I still end up adding the cast and end up finding the error at runtime during testing.

So it seems reasonable to me that the Java compiler should simply notice narrowings of object reference types and insert the runtime type check it will do as a result of the cast anyhow - thus saving me a bunch of time and extra typing.

> Humm, you might be understanding the issues I am trying to
> bring out better than I perceive.

I have very deep experience with Java. I generally feel like the crazy uncle in the attic here. The more I used Java, the more disgusted I became with the amount of pointless boilerplate, irrationally nannying compiler, and poorly designed api. I find it is pretty much a cargo cult amalgam of a bunch of stuff that has gone before. I know, I sound like the crazy uncle in the attic, but compare it with something like NextStep - which came well before - and one becomes impatient with designers who are working from an apparently tiny experience base.

It could have been so much better.

> Because I can reason through the dependency graph of these
> features, perhaps I'm not stressed about any particular
> "feature" and it's impact on my software.

I'm concerned with the initial decisions that necessitated so many of the later inconsistencies.

> The language features which I do find myself worrying more
> about these days are related to autoboxing.

Right, and the primordial feature that caused this particular mess was the unfortunate decision to have primitives rather than objects everywhere.

With the benefit of experience, most of Java's opening moves begin to appear naive.

Todd Blanchard

Posts: 316
Nickname: tblanchard
Registered: May, 2003

Re: What Are Your Java Pain Points, Really? Posted: Feb 18, 2007 7:50 PM
Reply to this message Reply
> 2) necessary verbosity (in a statically typed language)
> call((B)a) vs. call((C)a)

I maintain that this is bad pratice and that double dispatch (aka visitor) is more reliable.

Gregg Wonderly

Posts: 317
Nickname: greggwon
Registered: Apr, 2003

Re: What Are Your Java Pain Points, Really? Posted: Feb 18, 2007 8:07 PM
Reply to this message Reply
> So while I seem to be mostly a (possibly unreasonable)
> grouchy sort with a strong set of prejudices against Java
> and C++, my opinions are based on real experiences and
> trying to understand what it was about those languages
> that resulted in my impact with the wall and ultimately
> abandonment of these languages.

Perhaps either through habit or ignorance of a bad style, I've not ran into a wall while using Java for issues related to overloading and casting. I appreciate the narrowing cast because it allows me to see what is type is required.

In using Generics, I've had to look around more for type information because there is less casting in places that I've been used to it. So many expressions now look unfamilar and/or incomplete.

Mark Thornton

Posts: 275
Nickname: mthornton
Registered: Oct, 2005

Re: What Are Your Java Pain Points, Really? Posted: Feb 19, 2007 1:01 AM
Reply to this message Reply
> Right, and the primordial feature that caused this
> particular mess was the unfortunate decision to have
> primitives rather than objects everywhere.

Yes, had they done otherwise, we might have ended up with better language used by far fewer people.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: What Are Your Java Pain Points, Really? Posted: Feb 19, 2007 10:43 AM
Reply to this message Reply
> > I wouldn't want Java to be attempt to be a database
> > e querying language. I'd much rather use SQL in
> addition
> > to Java.
> So you think that Linq is not a great addition to C#?

I haven't used c# or Linq but from looking at the goals, it reminds me of a lot of legacy nightmares I've had to deal with. It's a tar-pit. You can never get away. I also have to question a syntax that attempts to query both XML and relational data. The semantics of the two are very different.

> I should add that I also don't buy the slogan "use the
> right tool for the job".
> In an ideal world, there would be
> one language that meets all of your programming
> requirements. You wouldn't have to learn new
> syntax/libraries when you program
> server/hardware/web/embedded, whatever.

I'm of the mind that no such tool exists and that it's impossible to create one language that works well for all problems without the syntax getting too large.

Everyone I've worked with for the last 8 years has known SQL. So I agree that we should not have to learn a new data access syntax to use a new programming tool. Moreover I can use the same SQL from any number of tools we currently have. I'd not only have to learn a new syntax and rewrite a lot of existing queries, it would be useless in our other tools.

I don't embed queries in my code. I write code that deals with data and worry about getting it to the code elsewhere. This works much better that the various embedded query methods I have worked with.

> You may need
> different specialized libraries for some tasks, but that
> should be all.

My experience is that languages that try to be all things are the worst to work with. They do lots of things but nothing well. They eventually become so expansive in scope that they no longer function as a single language. They become an environment. This is the precise failing of the Java community, IMO. Instead of working with other languages and tools, everything has had to be solved the 'java way'.

Gregg Wonderly

Posts: 317
Nickname: greggwon
Registered: Apr, 2003

Re: What Are Your Java Pain Points, Really? Posted: Feb 19, 2007 12:41 PM
Reply to this message Reply
> > Right, and the primordial feature that caused this
> > particular mess was the unfortunate decision to have
> > primitives rather than objects everywhere.
>
> Yes, had they done otherwise, we might have ended up with
> better language used by far fewer people.

Languages which do allow multiple ways to do the same thing allow people who think differently to find a way to do what they need to do.

Languages with very elegant implementation of very few features which have to be exploited with much thinking limit the user base for sure.

Todd Blanchard

Posts: 316
Nickname: tblanchard
Registered: May, 2003

Re: What Are Your Java Pain Points, Really? Posted: Feb 19, 2007 2:01 PM
Reply to this message Reply
> > Right, and the primordial feature that caused this
> > particular mess was the unfortunate decision to have
> > primitives rather than objects everywhere.
>
> Yes, had they done otherwise, we might have ended up with
> better language used by far fewer people.

Or perhaps the average programmer might be just a little more productive as he can spend that gray matter on domain specific problems.

Mark Thornton

Posts: 275
Nickname: mthornton
Registered: Oct, 2005

Re: What Are Your Java Pain Points, Really? Posted: Feb 19, 2007 2:58 PM
Reply to this message Reply
> Or perhaps the average programmer might be just a little
> more productive as he can spend that gray matter on domain
> specific problems.

No a small number of programmers with genuine efficiency requirements would correctly have used something else instead.

A much larger number of programmers with bogus efficiency concerns would have done likewise.

Flat View: This topic has 264 replies on 18 pages [ « | 8  9  10  11  12  13  14  15  16 | » ]
Topic: What Are Your Java Pain Points, Really? Previous Topic   Next Topic Topic: The Future of Online Dialog


Sponsored Links



Google
  Web Artima.com   

Copyright © 1996-2017 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use - Advertise with Us