Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
HomeAnnouncementsWhite Papers
Discussion GroupsFirst AidDatabasesJavaBeansGUIJava 3DVirtual MachineCORBASecurityToolsGeneral
Java DirectoryOpen Source ProjectsSample Book ChaptersUser GroupsWeb Resources
Related Topics
Databases.NETMore Topics ...

Java Forum / General / November 2006

Tip: Looking for answers? Try searching our database.

ClassCast Exception

Thread view: 
ba.hons - 22 Nov 2006 14:50 GMT
Hello,

i wonder if anyone can help or advise me on why am getting a ClassCast
Exception

I have a class called A (for instance) which implements another class
(B)

I have also created a new class called C which implements A

Now i have a method that i can not control which returns an instance of
A, but i need to convert this instance when it is returned to my new
type C which just has an extra method.

I cant just add the extra method to class A as i cant modify this code.

i tried to cast A to C like this

C test = (C)objectOfTypeA;

and then i get a classcast exception?

Anyone any ideas?

Thanks

Adam
Patricia Shanahan - 22 Nov 2006 15:24 GMT
> Hello,
>
[quoted text clipped - 23 lines]
>
> Adam

The A returned by the other method is NOT a C, and Java won't let you
pretend it is one. However, you could write a C subclass, D, whose
constructor takes an A as parameter.

D would remember the A it was passed, and implement all the common B
methods by calling the corresponding method in that A. It would have to
find its own way of implementing the added method, based on A's methods,
but if that cannot be done your problem is impossible anyway.

You could then write:

C test = new D(objectOfTypeA);

That said, it is not at all clear that this is really the best approach.
You may get more useful answers if you describe the problem at the next
level up. Why do you want this particular class extension structure?
What problem is it solving?

Patricia
ba.hons - 22 Nov 2006 15:33 GMT
Thanks for the help i will explain it slighlty more high level.

I have superclass called Wrapper that wraps up methods of a C++ dll
I need to create a new c++ dll with a couple of extra methods but i
cant add them to the original dll. So i thought the best approach would
be to create a new Wrapper class like so

public class NewWrapper extends Wrapper{

    public NewWrapper(String prof, String pw, String ini) {
        super(prof,pw,ini);
        profile = prof;
        password = pw;
        inifile = ini;

    }
    protected native void setValues(String newvalue) throws
RuntimeException;
}

Now to create a Wrapper object i have to use a method from a jar file
that i cant change like so

Wrapper test = NotMyClass.getwrapper();

So i have been trying to do the following

Wrapper testObject1=new Wrapper("","","");

testObject1 = NotMyClass.getwrapper();

NewWrapper testObject2=(NewWrapper)testObject1;

So basically creating a subclass object from a superclass by casting?

but as i said i keep getting ClassCast exception?

> > Hello,
> >
[quoted text clipped - 43 lines]
>
> Patricia
Ingo R. Homann - 22 Nov 2006 16:03 GMT
Hi,

> public class NewWrapper extends Wrapper{
>
[quoted text clipped - 20 lines]
>
> So basically creating a subclass object from a superclass by casting?

Your misunderstanding is that a cast does NOT create anything. It just
changes the "view" to an Object. The Object itself remains untouched -
only the type of the reference (pointer) to the Object is changed.

Or you could say: Not the Object is casted, only the Reference is casted.

However, Patricia showd you a good way to solve your problem.

Ciao,
Ingo
Lew - 27 Nov 2006 14:52 GMT
> Thanks for the help i will explain it slighlty more high level.
>
[quoted text clipped - 4 lines]
>
> public class NewWrapper extends Wrapper{

It's tricky to impose a relationship between extrinsic components.

This inheritance structure binds you to a similar inheritance of the external
entity "new DLL" from the "original DLL".  You are committing your Java design
to mirror the C++ inheritance, only even minimally manageable if you control
the relationship between the DLLs.  If the DLL inheritance relationship is
extrinsic to the Java project and not guaranteed to apply, then potentially
you have introduced brittleness.

This does not mean literally "inheritance" by one DLL's components of
another's.  I don't know of a meaningful way to say that one DLL "inherits
from" another.  It is sufficiently safe for your Java inheritance model if the
interface contracts for the DLLs will always fit the equivalent logical
inheritance model between them.

Does the new DLL really need to duplicate methods from the original, instead
of merely adding new methods and calling the original as appropriate? Do you
control the specifications of the original DLL?  What if it comes out in a new
version?

An alternative approach is for NewWrapper to wrap Wrapper rather than to
inherit it. This insulates the Java code a mite from changes to the extrinsic
components, at a cost of some initial effort. Keep asking, "Is it 'is-a' or
'has-a' here?"

- Lew


Free Magazines

Get these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...

Oracle MagazineNetwork ComputingComputer WorldBio-IT WorldeWeekInformation WeekInfosecurity
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2008 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.