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 ... 9 10 11 12 13 14 15 16 17 ... 18 | » ]

Todd Blanchard

Posts: 316
Nickname: tblanchard
Registered: May, 2003

Re: What Are Your Java Pain Points, Really?

Posted: Feb 19, 2007 6:41 PM

Reply

Advertisement

> > Also, object reference type conversion is inherently
> > different from primitive type conversion.
>
> Because primitive type conversion can be lossy and object
> conversion not so?

They do different things. Primitive casting actually performs a format conversion on the data. It is necessary. There's no getting around it. I have absolutely no problem with primitive casting to make certain all the data is in compatible formats at the desired level of precision.

> However, isn't converting an "Object"
> type to a more specific type also a potentially awkward
> situation?

Thing thing3 = (Thing) map.get(thing2);

might well be rewritten as:

Object tmp = map.get(thing2);
Thing thing3;
if (tmp instanceof Thing) {thing3=tmp]
else { throw new ClassCastException}

and you always do exactly this. Get the value, check the type, throw if it is not what you expect. There is nothing type safe about this pattern either.

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

I think if you are casting at all, you have a design problem. Casts are inherently unsafe - you can get them wrong. If you do, the result is the same as if you didn't cast - there is type mismatch at point of assignment - an exception is raised. Why make me type it out?

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: What Are Your Java Pain Points, Really?

Posted: Feb 19, 2007 7:41 PM

Reply

> I think if you are casting at all, you have a design
> problem. Casts are inherently unsafe - you can get them
> wrong. If you do, the result is the same as if you didn't
> cast - there is type mismatch at point of assignment - an
> exception is raised. Why make me type it out?

I've made basically the same argument in the past and the answer I get invariably from people who disagree is that the cast (type check) alerts the developer that the assignment could fail.

On a similar note, one thing that I had thought might be a nice middle ground between duck-typing and the the type static typing used in Java would be that an interface never needs to be implemented. A instance could be assigned to a reference of the interface type if it has all the methods specified on the interface. It doesn't need to implement it explicitly.

The strong argument against this is that an instance might have a method of the same name that is not really the same method. Personally, I think this is pretty unlikely to happen and if it does, it's not going to get very far in testing.

The weak argument is that this doesn't really make much difference. I disagree because it would make interfaces much more disposable and therefore more likely to be used and less time-consuming. I think maybe that this would help with some of the interface versioning issues that were mentioned earlier.

Peter Booth

Posts: 62
Nickname: alohashirt
Registered: Aug, 2004

Re: What Are Your Java Pain Points, Really?

Posted: Feb 19, 2007 8:10 PM

Reply

My Java pain points are all high class problems; Java is a superb general purpose programming language. Having said that, I get frustrated my how much verbose boiler plate code I see - in many cases created through ignorance rather than necessity. As someone once said, "you can write Fortran in any language." With Java I have this arrogant conviction that I can get *anything* done, if I am willing to put in the time. For all its flaws Java has changed the world for the better.

With Ruby I will have more fun, write less code, but I don't know that I can get anything done (yet.)

Nuwan Goonasekera

Posts: 32
Nickname: nuwang
Registered: Apr, 2006

Re: What Are Your Java Pain Points, Really?

Posted: Feb 19, 2007 10:05 PM

Reply

> I think if you are casting at all, you have a design
> problem. Casts are inherently unsafe - you can get them
> wrong. If you do, the result is the same as if you didn't
> cast - there is type mismatch at point of assignment - an
> exception is raised. Why make me type it out?

I agree with that.

The remaining arguments I've heard/can think of are somewhat debatable.

1. Supporting overloaded methods - I agree the utility of it is questionable and possibly confusing.

2. Consistency - Since primitive data type conversions are using it, I suppose there is an air of consistency to use it for object data types as well. I think it makes more sense for languages like C# where there is type unification.

3. Legacy reasons - Being friendly to C++ developers? Not necessarily a good reason ;)

4. Chained invocations - ((Order)map.get(key)).getTotalValue();

You also mentioned that Java had made some fundamental mistakes at the very outset. Can you clarify? Can they be corrected?

Andreas Mross

Posts: 12
Nickname: amross
Registered: Apr, 2004

Re: What Are Your Java Pain Points, Really?

Posted: Feb 20, 2007 5:06 PM

Reply

> On a similar note, one thing that I had thought might be a
> nice middle ground between duck-typing and the the type
> static typing used in Java would be that an interface
> never needs to be implemented. A instance could be
> assigned to a reference of the interface type if it has
> all the methods specified on the interface. It doesn't
> need to implement it explicitly.

Yes! I have thought for a long time that this would be a valuable change to the language.

> The weak argument is that this doesn't really make much
> difference. I disagree because it would make interfaces
> much more disposable and therefore more likely to be used
> and less time-consuming. I think maybe that this would
> help with some of the interface versioning issues that
> were mentioned earlier.

It would allow a new design style. Instead of creating an Interface first, then creating one or more Classes which implement that Interface; we could start with some random classes with common methods and create an Interface that contains those methods.
This would provide the flexibility of "dynamic" languages but retain all the advantages of Java's static typing.

Gregor Zeitlinger

Posts: 108
Nickname: gregor
Registered: Aug, 2005

Re: What Are Your Java Pain Points, Really?

Posted: Feb 21, 2007 12:03 AM

Reply

> 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.
I thought you were arguing against having two methods with the same name but different signatures.

I would have no problem with your solution - if the compiler could assert that there is at least one possible method for each method call.

Gregor Zeitlinger

Posts: 108
Nickname: gregor
Registered: Aug, 2005

Re: What Are Your Java Pain Points, Really?

Posted: Feb 21, 2007 12:13 AM

Reply

> 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.
Linq isn't released yet (except for betas), but I haven't even used C# yet.
I've looked at the examples (found via Wikipedia) and I liked the static typing of SQL and indeed the integration with XML (and object querying for that matter). When viewed from the right perspective, SQL and XML are not so much different (both are an object graph).

Todd Blanchard

Posts: 316
Nickname: tblanchard
Registered: May, 2003

Re: What Are Your Java Pain Points, Really?

Posted: Feb 21, 2007 4:30 AM

Reply

Borrowing the previous example - double dispatch - as show below is more reliable - no casting - you cannot get it wrong.


class Base { 
   void displayOn(Displayer d) { d.showBase(this); }
}

public class Bar extends Base implements Renderable {
   void displayOn(Displayer d) { d.showRenderable(this); }
}
 
public interface Displayer {
    public void show( Base b ) { b displayOn(self); }
    public void showBase( Base b) {...}
    public void showRenderable(Renderable r) {...}
}

So maybe you don't need casting after all.

Achilleas Margaritis

Posts: 674
Nickname: achilleas
Registered: Feb, 2005

Re: What Are Your Java Pain Points, Really?

Posted: Feb 21, 2007 4:34 AM

Reply

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.

Hey, include me in the set of crazy uncles in the attic!

Seriously, folks, none of you read LtU? what Java does, other languages can do in 1/10 of code.

It's a shame really that we are stuck with so inferior languages. Instead of putting our minds into translating the requirements of our customers to code, we spend our time on problems like casting, where to put methods, typing the same things over and over etc.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: What Are Your Java Pain Points, Really?

Posted: Feb 21, 2007 6:18 AM

Reply

> Linq isn't released yet (except for betas), but I haven't
> even used C# yet.
> I've looked at the examples (found via Wikipedia) and I
> liked the static typing of SQL

I've used languages that allow embedded SQL. PowerBuilder and COBOL for example. The embedded SQL inevitably becomes the biggest maintenance problem. It's something I don't care to suffer through again. Inversion of control (no, I don't mean Spring or Hibernate in particular) is a much more maintainable approach.

> and indeed the integration
> with XML (and object querying for that matter). When
> viewed from the right perspective, SQL and XML are not so
> much different (both are an object graph).

Looking at these examples: http://msdn2.microsoft.com/en-us/vcsharp/aa336746.aspx LINQ appears to be a rewrite of SQL. SQL is not a good language for querying XML.

In SQL an item from a table called address always has the same definition. An item named address in XML could have different definitions depending on it's parent elements and may not have an definition at all. I've worked with XML schemata in the past where there were 5 or 6 distinct Address types. An entity like a business partner could have 3 distinct addresses of 3 distinct types. Even if you use a schema definition (like w3c schema) you can allow 'any' elements at any point in the definition of an element.

Any non-trivial work with XML is going to require transformations. Queries are not sufficient for this. Is LINQ syntax even Turing complete?

Gregg Wonderly

Posts: 317
Nickname: greggwon
Registered: Apr, 2003

Re: What Are Your Java Pain Points, Really?

Posted: Feb 21, 2007 6:43 AM

Reply

> > 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?
>
> I think if you are casting at all, you have a design
> problem. Casts are inherently unsafe - you can get them
> wrong. If you do, the result is the same as if you didn't
> cast - there is type mismatch at point of assignment - an
> exception is raised. Why make me type it out?

Narrowing with interfaces can lead to a class cast exception. Narrowing with a class is checkable and the compiler will tell you that one class can't possible be another.

Generics with Collection classes helps make the contained types visible during compilation which reduces bugs. I've found two "wrong container used" bugs by injecting Generics into old code.

There are simple container patterns which can be used to eliminate casting issues using a factory model. Many people have used these from the beginning.

public class MyMap {
    private Map map = ...;
    public MyVal get( MyKey key ) {
        return (MyVal)map.get(key);
    }
    ...
}

If you have a multi valued map, you can create multiple "get" methods which either use overloading, or have specific names like getMyVal() and getYourVal().

When you are used to a dynamic language without types or without overloading, then adding the 'type' to the get() method is pretty common to help with seeing what is expected to happen. It doesn't keep people from calling the wrote version by mistake as static typing can generally do better at.

Gregg Wonderly

Posts: 317
Nickname: greggwon
Registered: Apr, 2003

Re: What Are Your Java Pain Points, Really?

Posted: Feb 21, 2007 6:49 AM

Reply

> 4. Chained invocations -
> ((Order)map.get(key)).getTotalValue();

I don't understand what you are referring to here. Can you clarify why you put this in the list you provided?

Gregg Wonderly

Posts: 317
Nickname: greggwon
Registered: Apr, 2003

Re: What Are Your Java Pain Points, Really?

Posted: Feb 21, 2007 6:57 AM

Reply

> Borrowing the previous example - double dispatch - as show
> below is more reliable - no casting - you cannot get it
> wrong.
>
>

> class Base { 
>    void displayOn(Displayer d) { d.showBase(this); }
> }
> 
> public class Bar extends Base implements Renderable {
>    void displayOn(Displayer d) { d.showRenderable(this); }
> }
>  
> public interface Displayer {
>     public void show( Base b ) { b.displayOn(self); }
>     public void showBase( Base b) {...}
>     public void showRenderable(Renderable r) {...}
> }
>

>
> So maybe you don't need casting after all.

The problem is that this creates unnnecessary dependencies between objects. Every object has to have knowledge of how other objects use it. This is too much coupling for many applications.

Gregg Wonderly

Posts: 317
Nickname: greggwon
Registered: Apr, 2003

Re: What Are Your Java Pain Points, Really?

Posted: Feb 21, 2007 7:06 AM

Reply

> Seriously, folks, none of you read LtU? what Java does,
> other languages can do in 1/10 of code.

I think that it's unfortunate that you are summing up the features of various languages just on the amount of text involved in the expressions that the language uses.

There is truely so much more to it...

> It's a shame really that we are stuck with so inferior
> languages. Instead of putting our minds into translating
> the requirements of our customers to code, we spend our
> time on problems like casting, where to put methods,
> typing the same things over and over etc.

In the J2EE world, this is probably the most predominate mode of development. Is that the place where you've spent the most time writing "java" code?

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: What Are Your Java Pain Points, Really?

Posted: Feb 21, 2007 7:37 AM

Reply

> The problem is that this creates unnecessary dependencies
> between objects. Every object has to have knowledge of
> how other objects use it. This is too much coupling for
> many applications.

It's the Visitor pattern if we want to put a name on it.

Personally I think double-dispatch is useful but only in infrequent circumstances but those circumstances can be a huge deal. The most common is parsing. Scala has a nice syntax for dealing with this.

Anyway you slice it, however (double-dispatch, Visitor, scala case classes) this type of approach creates strong two-way coupling between the classes, I agree.

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

Previous Topic

Next Topic

Sponsored Links

Copyright © 1996-2019 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use