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 ... 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 21, 2007 1:27 PM
Reply to this message Reply
Advertisement
> > 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.

Actually, properly done - it creates depenedencies between interfaces, and classes. But you do need to do a little more thinking about your abstractions.

Casting creates dependencies between *objects* and it is error prone. You have the dependencies anyhow - you've just moved them to the application code at large instead of focusing them in framework classes.

Notice that the dynamically typed version of this pattern is still absolutely safe - while the statically typed casting is not.

One more 'reliability' myth up in smoke.

The problem with your casting and your generics and your typing and all of that stuff is that it makes it rather too easy to only kind-of do objects. It is a crutch that lets you work around weak design.

Todd Blanchard

Posts: 316
Nickname: tblanchard
Registered: May, 2003

Re: What Are Your Java Pain Points, Really? Posted: Feb 21, 2007 1:41 PM
Reply to this message Reply
> It's the Visitor pattern if we want to put a name on it.

Yes, but I prefer double dispatch. It is rather astonishing to me how many people think visitor is simply about graph traversal rather than type narrowing.

> Personally I think double-dispatch is useful but only in
> infrequent circumstances

I grant that it is rather less convenient in Java because classes are not open for extension the way they are in dynamic languages where you can just attach more methods to existing classes without having to get their source code and recompile them.

Which really, if I were to have one thing in Java I would add, it would be method categories ala ObjectiveC wherein I can declare in my own code something like:
category MyStringExtensions extends String
{
   public boolean isValidUrl() { return startsWith("http:"); }
}

which allows me to attach a new (admittedly lame) method to String. To please the security freaks, method categories must be able to be written in terms of the class's public interface, cannot access ivars, and cannot shadow/hide/override existing methods. This would be a huge step up in flexibility and would allow all casting to be replaced with safe polymorphic methods to do narrowing (among other things).

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: What Are Your Java Pain Points, Really? Posted: Feb 21, 2007 1:45 PM
Reply to this message Reply
> Notice that the dynamically typed version of this pattern
> is still absolutely safe - while the statically typed
> casting is not.

I'm not sure I've seen the dynamically typed version in this thread. I've seen two statically typed examples, where one uses the Visitor pattern. In both examples the method caller determines which version of the method is called. In the Visitor example, you could use casts instead of the method names to determine which method is called and there would be no real difference in the generated bytecodes.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: What Are Your Java Pain Points, Really? Posted: Feb 21, 2007 1:57 PM
Reply to this message Reply
> which allows me to attach a new (admittedly lame) method
> to String. To please the security freaks, method
> categories must be able to be written in terms of the
> class's public interface, cannot access ivars, and cannot
> shadow/hide/override existing methods.

I'm a little confused because you above you say that this make double-dispatch more useful but if I can't override methods, how would I take advantage of double-dispatch?

> This would be a
> huge step up in flexibility and would allow all casting to
> be replaced with safe polymorphic methods to do narrowing
> (among other things).

I just have one question about this. Doesn't make it harder to debug code and understand how it is working? With Java it seems that I lose some flexibility but I always know where to look for the code when something goes wrong. With dynamically added methods, wouldn't I need to search through the code looking for added methods?

Lately, I've used the following a lot with Python. By using the __getattr__ method, you can create auto-wrapper Objects and add methods to the wrapper, allowing others calls to fall through to the wrapped Object. Mostly I've used this to wrap Java Objects.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: What Are Your Java Pain Points, Really? Posted: Feb 21, 2007 2:43 PM
Reply to this message Reply
> > which allows me to attach a new (admittedly lame)
> method
> > to String. To please the security freaks, method
> > categories must be able to be written in terms of the
> > class's public interface, cannot access ivars, and
> cannot
> > shadow/hide/override existing methods.
>
> I'm a little confused because you above you say that this
> make double-dispatch more useful but if I can't override
> methods, how would I take advantage of double-dispatch?

Sorry, overload vs. override. But if I can cause someone else's code to call my method isn't that a security/stability issue? For example if code is calling 'setPassword' on an Object and I figure out a way to overload the method such that my is called instead.

Gregg Wonderly

Posts: 317
Nickname: greggwon
Registered: Apr, 2003

Re: What Are Your Java Pain Points, Really? Posted: Feb 21, 2007 3:16 PM
Reply to this message Reply
> But if I can cause someone
> else's code to call my method isn't that a
> security/stability issue? For example if code is calling
> 'setPassword' on an Object and I figure out a way to
> overload the method such that my is called instead.

I think this is one of the primary features of Java that I enjoy the most. I can really have secure mobile code because of the design of the language, the platform, and the security features all together.

Todd Blanchard

Posts: 316
Nickname: tblanchard
Registered: May, 2003

Re: What Are Your Java Pain Points, Really? Posted: Feb 21, 2007 4:52 PM
Reply to this message Reply
> I'm not sure I've seen the dynamically typed version in
> this thread.

I didn't show it. It works the same though. Assume you don't need to type variables in Java.
[/java]
class Number
{
abstract op+(n);
}

class Integer extends Number
{
op+(n) { return n.addInt(this); }
addInt(n) { "int + int" }
addFloat(n) { "int + float" }
}

class Float extends Number
{
op+(n) { return n.addFloat(this); }
addInt(n) { "float + int" }
addFloat(n) { "float + float" }
}

10 + 7
->Integer(10).op+(7)
-->Integer(7).addInt(10)

2.5 + 3
->Float(2.5).op+(3)
-->Integer(3).addFloat(2.5)

[/code]

> In the Visitor example, you could use casts
> instead of the method names to determine which method is
> called and there would be no real difference in the
> generated bytecodes.

Not true. Visitor uses pure polymorphism to do its thing. Casting peeks at the type and then branches. The reason is that the type of 'this' is the true type of the receiver.

Number op+(n) { typeof this = Number }
Integer op+(n) { typeof this = Integer }
In the dymanic version - without overloading - you call a method with a different name. With overloading, you can call a method with the same name but a different argument type - disambiguating based on the type of 'this'.

It amounts to the same thing - but there is no cast operation in Visitor - that is the point.

Todd Blanchard

Posts: 316
Nickname: tblanchard
Registered: May, 2003

Re: What Are Your Java Pain Points, Really? Posted: Feb 21, 2007 4:59 PM
Reply to this message Reply
> But if I can cause someone
> else's code to call my method isn't that a
> security/stability issue? For example if code is calling
> 'setPassword' on an Object and I figure out a way to
> overload the method such that my is called instead.

No - reread what I said. In Java, it would be great to be able to attach new methods to existing classes as long as the method implementations are

1) Written in terms of the object's public interface.
2) Do not override or shadow any existing methods in the original class

If I can do that, I can add the necessary methods to implement Visitor on any set of objects by adapting the protocol. I cannot intercept existing calls. There is no security problem.

FWIW, this mechanism is available in ObjectiveC on the Mac. It is used *EVERYWHERE*. It is not a problem. Categories can be loaded dynamically from shared libraries with a single call. This makes plugins really easy to do. It also makes adapting various modules really easy.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: What Are Your Java Pain Points, Really? Posted: Feb 21, 2007 5:26 PM
Reply to this message Reply
> Not true. Visitor uses pure polymorphism to do its thing.
> Casting peeks at the type and then branches. The reason
> n is that the type of 'this' is the true type of the
> receiver.
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) {...}
}


In Java this is almost completely equivalent:

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


This is easily demonstrable. While this comes closer to double-dispatch it's not the same because the Base and Renderable classes have to be complicit in the implementation. In true double-dispatch, the Displayer class could introduce new implementations that could change which method is called without any change to the Base or Renderable classes. For example if I extend Base:

class SubClass extends Base {}

This will always call the Base version of show (whether you use casting or method names) with the visitor pattern even if we add a method:

public void _show(SubClass b) {...}


to Displayer. With true double-dispatch, the new method will be called if the Base instance is an instance of SubClass.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: What Are Your Java Pain Points, Really? Posted: Feb 21, 2007 5:29 PM
Reply to this message Reply
> > But if I can cause someone
> > else's code to call my method isn't that a
> > security/stability issue? For example if code is
> calling
> > 'setPassword' on an Object and I figure out a way to
> > overload the method such that my is called instead.
>
> No - reread what I said. In Java, it would be great to be
> able to attach new methods to existing classes as long as
> the method implementations are
>
> 1) Written in terms of the object's public interface.
> 2) Do not override or shadow any existing methods in the
> original class
>
> If I can do that, I can add the necessary methods to
> implement Visitor on any set of objects by adapting the
> protocol. I cannot intercept existing calls. There is no
> security problem.

I'm just not following. If I can't change the behavior of existing method calls, how does double-dispatch help me in this context?

Todd Blanchard

Posts: 316
Nickname: tblanchard
Registered: May, 2003

Re: What Are Your Java Pain Points, Really? Posted: Feb 21, 2007 5:54 PM
Reply to this message Reply
> In Java this is almost completely equivalent:
>
>
> class Base {
>     void displayOn(Displayer d) { d._show((Base) this); }
> }
> 


That *was* java - and I totally don't get the point of the cast here. 'this' is of type Base already. Even if you derive from Base, unless you override displayOn, it is going to call show(Base).

Gregg Wonderly

Posts: 317
Nickname: greggwon
Registered: Apr, 2003

Re: What Are Your Java Pain Points, Really? Posted: Feb 21, 2007 6:08 PM
Reply to this message Reply
> > In Java this is almost completely equivalent:
> >
> >
> > class Base {
> >     void displayOn(Displayer d) { d._show((Base) this);
> }
> > }
> > 

>
> That *was* java - and I totally don't get the point of the
> cast here. 'this' is of type Base already. Even if you
> derive from Base, unless you override displayOn, it is
> going to call show(Base).

This is an explict widening which prohibits a subclass from changing this part of your implementation even though you want to allow _show() to be overriden.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: What Are Your Java Pain Points, Really? Posted: Feb 21, 2007 6:25 PM
Reply to this message Reply
> That *was* java

Yes, that's prerequisite to my point.

Gregor Zeitlinger

Posts: 108
Nickname: gregor
Registered: Aug, 2005

Re: What Are Your Java Pain Points, Really? Posted: Feb 21, 2007 11:27 PM
Reply to this message 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.
I have also found embedded SQL to be a maintenance problem.
I think the reason being that it cannot be refactored (probably because it is not statically typed). This problem is solved in Linq.

> 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.
I guess you mean that you change the SQL schema without changing the code.
I think this is only true for trivial schema changes - and that refactoring can do the same for you.
OTOH, Linq can do things that Hibernate cannot do as easily - otherwise you wouldn't need HQL (embedded SQL).
I have to admit that I don't have experience with Hibernate or Linq, though...

> > 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.
Linq is actually the common part. XLinq is the XML version of Linq. I just found this overview of XLinq (also found if you google for XLinq):
msdn.microsoft.com/VBasic/Future/XLinq%20Overview.doc

In essence, the XLinq objects have methods like descendants, parent, etc. that don't make sense in DLink (database version of Linq)

> 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.
True. To solve this you need the same conditionals as in SAX or XQuery.

In Linq, this would look like (from the document above):

If the contact has no phone numbers, the phoneNumbers wrapping element will exist, but there will be no phone child elements. The following example demonstrates how to resolve this situation:

new XElement("contacts",
from c in contacts.Elements("contact")
select new XElement("contact",
c.Element("name"),
c.Elements("phone").Any() ?
new XElement("phoneNumbers", c.Elements("phone")) :
null
)
);


> 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.
I just found out that transformation are also supported:
(from the document found above)


new XElement("Customers",
from c in contacts.Elements("contact")
select new XElement("Customer",
new XElement("Name", (string) c.Element("name")),
new XElement("PhoneNumbers",
from ph in c.Elements("phone")
select new XElement("phone", (string) ph,
ph.Attribute("type")
)
)
)
);

Achilleas Margaritis

Posts: 674
Nickname: achilleas
Registered: Feb, 2005

Re: What Are Your Java Pain Points, Really? Posted: Feb 22, 2007 2:26 AM
Reply to this message 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...

Agreed, but I can not suddenly start preaching the advantages of functional programming languages over Java to a possibly more experienced than me crowd.

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

In J2EE as well as in desktop apps.

Flat View: This topic has 264 replies on 18 pages [ « | 10  11  12  13  14  15  16  17  18 | » ]
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