DBAccess interface

[Nit Kad]

I sm going to start on my assignment for SCJD exam. I downloaded the jar from Sun which included one interface which is supposed to be implemented by another class called as Data.java .

My question is that can we make changes in the interface provided by Sun. The reason I am asking because the DBAccess interface is perfect for RMI except that it doesn't have RemoteException thrown in any of its methods which is a required exceptions if an interface is supposed to be used for RMI.

Please advice whether the interface can be modified to add the RemoteException or not?

Thanks
Nit

[Matt Sheehan.]

I'm pretty sure that you cannot make any changes to the interface except reformatting the documentation.

Matt

[Paul Bourdeaux]

I wouldn't recommend making changes to the interface provided, but I don't think there is anything stopping you from extending the interface...

[M Jay]

You do not need to alter the interface, but you could probably add remote exception to the method when implementing it in your Data.java file. So basically leave the interface as it is, and then when you write the class that implaments it you could make the methods throw any additional exceptions you see neccessary.

[Jiwoong Lee]

I think the interface which is provided by SUN shows essential method U should implement. So you don't change any prototype, any parameter, any return type. But U can extend this interface if U need something else like another method or exception ...

--------------------

SCJP 1.4
OCP 9i
SCJD(IN PROCESS)
[ October 14, 2004: Message edited by: Jiwoong Lee ]

[James Clinton]

I would recommend looking into the Adapter Pattern to solve your problems.

[Nicholas Cheung]

If you make any changes on the signatures of the methods in the interface provided by SUN, you will result in automatic fail.

So, dont even think of this action.

Nick

[Mike Vess]

So basically leave the interface as it is, and then when you write the class that implaments it you could make the methods throw any additional exceptions you see neccessary.

This is not true. Will give a compiler error. You can not throw an exception in the implementing class that is not thrown in the interface. It is only possible to throw the exact exception or subclasses of it in the implementing class or choose to not throw any exception at all.

[GD Deepz]

That is right Mike, I got the same problem. In addition, the remote class tha implements DBAccess require the methods to throw RemoteException otherwise the stubs will not be generated AND we can't modify the signatures of DBAccess. Need help

[Paul Bourdeaux]

Extend the DCAccess interface to include the RemoteException.

  
package suncertify.db;
public interface DBAccess
{
    // Reads a record from the file. Returns an array where each
    // element is a record value.
    public String [] readRecord(long recNo)
    throws RecordNotFoundException;
        .
        .
        . 

package suncertify.db;
public interface RemoteDBAccess extends DBAccess
{
    // Reads a record from the file. Returns an array where each
    // element is a record value.
    public String [] readRecord(long recNo)
    throws RecordNotFoundException, RemoteException;
        .
        .
        . 

[ October 15, 2004: Message edited by: Paul Bourdeaux ]

[Matt Sheehan.]

Extend the DCAccess interface to include the RemoteException.

I think this will lead to a compiler error.
"overridden method does not throw java.rmi.RemoteException"

Matt

[James Clinton]

you are going down the wrong path extending the db class to throw RemoteException in my opinion.

You should instead be creating some controller class that is remote which implements a sperate interface (which throw RemoteException) declaring xyz business methods.

These methods can then interact with you data class at a local level.

Again refer to the adapter pattern. Once you have that worked out, then you can link this to a DataAccessObject pattern to query your data.

HTH

[Paul Bourdeaux]

I think this will lead to a compiler error.

It shouldn't as long as you extend the interface, not implement it. But that is moot anyway. After more consideration, I am inclined to agree with James and use the adapter patter.

[GD Deepz]

Got it figured (B&S), don't extend DBAccess, Have the RMI remote class implement another interface which consists of methods that throw RemoteExcpetion. You then use the Adapter pattern between the RMI remote class and the Data class. The Adapter implements DBAccess (supplied by Sun) and Data class HAS to also implements DBAccess; requirement by Sun.

It works for me eventhough you have 2 classes implementing DBAccess, the design is a little off but Sun forces me to use Data implements DBAccess

[James Clinton]

It works for me eventhough you have 2 classes implementing DBAccess

I would use a new interface (facade). Use DBAccess for the Data. And for the controller use a new one called XXXBusinessServices.

If you don't, then if you change the DBAcess interface you will have issues like (1) you now have to change the controller class and (2) this could effect you client layer depending on your implementation.

Also, I don't forsee it work that way because the DBAcess shouldn't throw RemoteExceptions BUT the XXXBuinessServices should.

Makes sense?

[peter wooster]

Originally posted by Nit Kad:
I sm going to start on my assignment for SCJD exam. I downloaded the jar from Sun which included one interface which is supposed to be implemented by another class called as Data.java .

My question is that can we make changes in the interface provided by Sun. The reason I am asking because the DBAccess interface is perfect for RMI except that it doesn't have RemoteException thrown in any of its methods which is a required exceptions if an interface is supposed to be used for RMI.

Please advice whether the interface can be modified to add the RemoteException or not?

Thanks
Nit

1) do a search in this forum for "exception", you will see months of debate on this issue. The "runtime exception chaining IOExceptions" approach gets the most votes.

2) DO NOT modify the signatures in that interface, that is used by automated tests that Sun runs when marking your project, errors will result in an automatic failure. The notes say "you must provide this interface"

3) look at the Adapter pattern in GoF, its the right solution to this problem, if you are doing the rich client. If you are doing the thin client, you need some kind of Facade.