Interfaces / Abstract classes / ResultSets

I want to set the fetch size of each java.sql.ResultSet throughout my application, in one place. ResultSet is an interface and a ResultSet is returned by a call to PreparedStatement.execute(). So I figured I could implement ResultSet in an abstract class of my own and just override getFetchSize() or put a setFetchSize() in the constructor. Anyway, it seems I get a ClassCastException when casting the ResultSet returned from PreparedStatement.execute() to MyResultSet:
java.lang.ClassCastException: oracle.jdbc.driver.OracleResultSetImpl
I've tried having MyResultSet implement oracle.jdbc.driver.OracleResultSet too just in case. But no luck there either. If I try and implement OracleResultSetImpl I'm told it's not public and so can't be accessed from outside the package.
Can I do this somehow? Or an alternative, simple way?

I want to set the fetch size of each
java.sql.ResultSet throughout my application, in one
place. ResultSet is an interface and a ResultSet is
returned by a call to PreparedStatement.execute(). So
I figured I could implement ResultSet in an abstract
class of my own and just override getFetchSize() or
put a setFetchSize() in the constructor.Yes, you can.
Anyway, it
seems I get a ClassCastException when casting the
ResultSet returned from PreparedStatement.execute()
to MyResultSet:Well, you have to re-implement PreparedStatement as well, otherwise of course it won't even know that your class exists, let alone use it.
Serializabe z = method();
If I define method() to return a String, it doesn't mean that it'll suddenly return something else simply because I wrote it and it also implements Serializable.
java.lang.ClassCastException:
oracle.jdbc.driver.OracleResultSetImplThe object you get is simply not an instance of your class.
Simple way around: create a wrapper class around the original ResultSet that does what your implementation did.

Similar Messages

Interfaces, Abstract Classes & Polymorphism

I have a friend taking a Java course as part of a larger degree program, and she's asked for some help with an assignment. The assignment is as follows:
This assignment is to write a simple encryption/decryption application. There will be a single application
that the user can use to encrypt or decrypt a phrase passed in on the command line, with the user deciding
which encryption/decryption scheme to use.
The first scheme is to add 1 to each character that is in the phrase, the other is to subtract 1 from each
character that is in the phrase.
To encrypt, you must be able to use the follwing syntax:
java Crypto encrypt Additive "hello"
Output:
"hello" encrypts to: "ifmmmp"
To decrypt:
java ca.bcit.cst.comp2256.a###### decrypt Additive "ifmmp"
Output:
"ifmmp" decrypts to: "hello"
Use Additive or Subtractive as the arguments to choose which encryption/decryption to
use. The problem is, I'm not entirely sure how to use abstract classes and interfaces to do what is being asked. I'm pretty sure I could do the whole program in a single for-loop, but apparently her teacher doesn't want people coming up with their own solutions for the problem. I don't need any code for how to do it, per se, I'm just wondering how one would structure a program like that to include interfaces, polymorphism and abstract classes.
Anyone have any ideas?

with the user deciding which encryption/decryption scheme to use.This is the key sentence. encryption/decryption can be done using multiple schemes. The contract for any given scheme can be defined using
public String encrypt(String input);
public String decrypt(String input);There can be multiple implementations for these methods, one set for each scheme.
The contract therefore becomes the interface and each implementation is a concrete implementation of this interface.
The problem doesn't delve deep into the kind of schemes available. If it does and there is a significant overlap between 2 schemes, an abstract class that takes care of the shared logic among 2 schemes comes into picture.
Hope this helps!

Situation where you are interface & abstract class?

please let me know if any one knowns answer for the above question

But my doubt in which situation we r using interface
and abstarct classesWithout repeating the debates, you should use interfaces to define the contract for developers to use. This is usually done when nothing is known about the concrete implementation but the design is ready. This is also useful when you need to have multiple inheritance.
Abstract classes are useful when you want to force the implementation of some of the methods onto the developers, rather than everyone having their own implementations. This is preferred when there is some concrete idea of some of the methods in the class while the implementations of the remaining methods can vary with the specialization of the sub-classes.
You might want to read this:
http://www.javaworld.com/javaworld/javaqa/2001-04/03-qa-0420-abstract.html

Interface & abstract class

1>whats the basic difference between an interface and an abstract class?
when should one be using an interface or an abstract class?
2>whats the difference between method overriding and method overlaoding?
does both of them has any relation with the instance of te class implementing them?

http://www.google.com/search?q=java+interface+%22abstract+class%22
http://www.google.com/search?q=java+method+overloading+overriding

Ordered & unordered arraylist with interface & abstract class

you can remove this
Edited by: Taco_John on Mar 9, 2008 7:38 PM

http://www.google.com/search?q=java+interface+%22abstract+class%22
http://www.google.com/search?q=java+method+overloading+overriding

Dealing with abstract classes and interfaces with XMLBeans

I'm quite new to XMLBeans and would like some help. I've got things working when
you are only saving concreate classes as XML, but when it comes to clesses containing
interfaces I am running into problems.
I basically have a collection of XY objects (see below) that I want to save as
XML.
I want to convert the following java classes to an xml schema:
public class XY{
X x;
Y y;
public interface X{
void setA(int a);
int getA();
public interface Y{
void setB(int b);
int getB();
public class X1 implements X{
void setA(int a);
int getA();
//other data to save
public class X2 implements X{
void setA(int a);
int getA();
//other data to save
public class Y1 implements Y{
void setB(int b);
int getB();
//other data to save
public class Y2 implements Y{
void setB(int b);
int getB();
//other data to save
What would be the best way to convert these to XML Schema? I've looked through
all the XMLBeans documentation, but it doesn't say anything about dealing with
interfaces/abstract classes. Is there anywhere else to look?
Thanks in advance,
Andrew

Anurag,
What I really wanted was a work-around to using substiutionGroups as substitution
groups are not supported in this release.
I want to convert the following schema:
<xsd:complexType name="PublicationType">
<xsd:sequence>
<xsd:element name="Title" type="xsd:string"/>
<xsd:element name="Author" type="xsd:string" minOccurs="0" maxOccurs="unbounded"/>
<xsd:element name="Date" type="xsd:gYear"/>
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="BookType">
<xsd:complexContent>
<xsd:extension base="PublicationType" >
<xsd:sequence>
<xsd:element name="ISBN" type="xsd:string"/>
<xsd:element name="Publisher" type="xsd:string"/>
</xsd:sequence>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:complexType name="MagazineType">
<xsd:complexContent>
<xsd:restriction base="PublicationType">
<xsd:sequence>
<xsd:element name="Title" type="xsd:string"/>
<xsd:element name="Date" type="xsd:gYear"/>
</xsd:sequence>
</xsd:restriction>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="Publication" type="PublicationType"/>
<xsd:element name="Book" substitutionGroup="Publication" type="BookType"/>
<xsd:element name="Magazine" substitutionGroup="Publication" type="MagazineType"/>
<xsd:element name="BookStore">
<xsd:complexType>
<xsd:sequence>
<xsd:element ref="Publication" maxOccurs="unbounded"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
to produce an XML file like:
<?xml version="1.0"?>
<BookStore ¡Ä>
<Book>
<Title>Illusions: The Adventures of a Reluctant Messiah</Title>
<Author>Richard Bach</Author>
<Date>1977</Date>
<ISBN>0-440-34319-4</ISBN>
<Publisher>Dell Publishing Co.</Publisher>
</Book>
<Magazine>
<Title>Natural Health</Title>
<Date>1999</Date>
</Magazine>
<Book>
<Title>The First and Last Freedom</Title>
<Author>J. Krishnamurti</Author>
<Date>1954</Date>
<ISBN>0-06-064831-7</ISBN>
<Publisher>Harper & Row</Publisher>
</Book>
</BookStore>
What is the best way to do this without using substitution types?
Thanks,
Andrew
"Anurag" <[email protected]> wrote:
Andrew,
Could you please paste/attach a sample of the code you are using to convert
Java bean classes to XMLBeans?
In the current release the goal of XMLBeans technology was to convert
from
XML Schemas or XML files to XMLBeans. The focus was not towards conversion
of Java beans to XMLBeans.
Regards,
Anurag
"Andrew" <[email protected]> wrote in message news:[email protected]...
I'm quite new to XMLBeans and would like some help. I've got thingsworking when
you are only saving concreate classes as XML, but when it comes toclesses
containing
interfaces I am running into problems.
I basically have a collection of XY objects (see below) that I wantto
save as
XML.
I want to convert the following java classes to an xml schema:
public class XY{
X x;
Y y;
public interface X{
void setA(int a);
int getA();
public interface Y{
void setB(int b);
int getB();
public class X1 implements X{
void setA(int a);
int getA();
//other data to save
public class X2 implements X{
void setA(int a);
int getA();
//other data to save
public class Y1 implements Y{
void setB(int b);
int getB();
//other data to save
public class Y2 implements Y{
void setB(int b);
int getB();
//other data to save
What would be the best way to convert these to XML Schema? I've lookedthrough
all the XMLBeans documentation, but it doesn't say anything about dealingwith
interfaces/abstract classes. Is there anywhere else to look?
Thanks in advance,
Andrew

Abstract Classes versus Interfaces

Somebody at work has just made an interesting observation and its bugging me, comments please.
When I started Java I just used classes (and abstract classes), and didnt bother with Interfaces I understood them to be a way of getting round the lack of MultipleInheritance and it wasnt a problem that concerned me.
But as time went on I found that sometimes I did want classes that had little in common to provide some additional feature (such as logging), and interfaces were great for this.
..so I was happy ..
During all this time if I want a HashSet I would write code like this
HashSet dataSet = new HashSet();but then I read that HashSet was an implementation detail and we should be using Interfaces as follows:
Set dataSet = new HashSet();So whereas before I might have had a class hierachy with an Abstract class at the top , I started slotting in Interfaces above that and viewing the Abstract class as just a convenience to implementing the Interface.
So which is the right method , originally I saw subclassing object as an 'is a ' relationship and implementing an interface as a 'implements' relationship. But more recently it seems to be turned on its head and implementing an interface is an 'is a' relationship (but supports multiple inheritance)
Also it seems to be the trouble with this second approach is that anyone can implement an interface, for example I could implement Set,Map and List with one class, the class hierachy is not so helpful .

Thanks, but the question was alot wider than that,
the HashSet example was just one part of it.I think it is representative of all the situations that you talk about, which are whether an instantiator should handle the instantiated object by its interface or by its implementation.
I suppose the question is
"How do you code model "is a " relationship in java
through extending a class or creating an interface
and implementing it"
MySubClass extends MySuperClass implements MyInterface {}MySubClass is a MySuperClass and a MyInterface. The way that I view it, the "is a" relationship applies to all type inheritance, even for the multiple type inheritance that you can have with interfaces. The "is a" relationship doesn't doesn't have to be a 1:1 mapping. There's no point in thinking about it differently since that's how the language behaves.
an alternative question is
"is it correct to mix/match both methods I described
above"I thought I gave an answer. You said that my answer is not "broad enough." How so? My answer was that handling an object that you instantiate by its interface can reduce the amount of changes you have to make if you change the implementation. You will have to make one change (the line of code that instantiates the object) instead of many. Also, handling it by its interface makes it easier to switch from object A instantiating object B to object A being passed a reference to B and to object A getting its dependencies injected by XML configuration.
It seems weird to handle an object by its interface if you already know it's implementation, but it's commonly seen and this is why I think it must be used. As I said, it's a small benefit of abstraction.
The times when you may not want to do this is when the instantiator has to call methods from different interfaces of the object. You can handle it by its interface by casting between the different interfaces you have to work with, or you can just handle it by its implementation, gaining access to all of the object's interfaces.
Note that everything I explained concerns the type by which the instantiator handles an instantiated object. If a class does not instantiate a certain object, then it almost always should receive it by its interface, unless it's some really common implementation that's never going to change.
I use interface, abstract class, and base class interchangeably. It's up to you to decide which to use for type inheritance. It's good practice to favor interfaces.

JWSD RPC: abstract class or interface aren't working

I have an abstract class called Record, and some classes that extend Record. These class have been added in the additionalTypes part of the configuration file (a copy of the config.xml is shown below)
<?xml version="1.0" encoding="UTF-8"?>
<configuration
xmlns="http://java.sun.com/xml/ns/jax-rpc/ri/config">
<service name="sscService"
packageName="ssc"
targetNamespace="http://www.eurice.de/infocitizen/ssc"
typeNamespace="http://www.eurice.de/infocitizen/type/ssc">
<interface name="ssc.server.SupplierPort"
servantName="BasicSupplier"/>
<typeMappingRegistry>
<additionalTypes>
<class name="ssc.ConnectionSpec"/>
<class name="ssc.InteractionSpec"/>
<class name="ssc.MappedRecord"/>
<class name="ssc.IndexedRecord"/>
<class name="ssc.server.ResultSet"/>
<class name="ssc.server.SOAPNull"/>
<class name="ssc.ResultSetMetaData"/>
<class name="ssc.Entry"/>
<class name="ssc.SupplierMetadata"/>
<class name="ssc.EISMetadata"/>
<class name="ssc.cl.BirthCertificate"/>
</additionalTypes>
</typeMappingRegistry>
</service>
</configuration>
However the xrpcc tool issues the following error message:
E:\Projects\ssc\.\xrpccServer\ssc\Record_SOAPSerializer.java:33: class ssc.Recor
d is an abstract class. It can't be instantiated.
Record instance = new Record();
Can you help me?

OK, I took your record class as is:
public abstract class Record {
private java.lang.String recordId;
private java.lang.String name;
private java.lang.String shortDescription;
public java.lang.String getName() {
return name;
public void setName(java.lang.String name1){
name=name1;
public java.lang.String getShortDescription() {
return shortDescription;
public void setShortDescription(java.lang.String shortDescription1){
shortDescription=shortDescription1;
public java.lang.String getRecordId() {
return recordId;
public void setRecordId(java.lang.String id1){
recordId=id1;
Added a subclass:
public class MyRecord extends Record {
private int age;
public MyRecord() {}
public void setAge(int age) {
this.age = age;
public int getAge() {
return age;
Used the record in a service endpoint interface:
public interface Interface extends Remote {
public Record echo_Record(Record record) throws RemoteException;
Put MyRecord as an additionalType in the config.xml file:
<?xml version="1.0" encoding="UTF-8"?>
<configuration
xmlns="http://java.sun.com/xml/ns/jax-rpc/ri/config">
<service name="Interface_Service"
targetNamespace="http://echoservice.org/wsdl"
typeNamespace="http://echoservice.org/types"
packageName="stub_tie_generator_test">
<interface name="stub_tie_generator_test.Interface"
servantName="stub_tie_generator_test.InterfaceImpl"/>
<typeMappingRegistry>
<additionalTypes>
<class name="stub_tie_generator_test.MyRecord"/>
</additionalTypes>
</typeMappingRegistry>
</service>
</configuration>
And invoked the method with:
Record rec = new MyRecord();
((MyRecord)rec).setAge(33);
rec.setShortDescription("short");
rec.setName("name");
rec.setRecordId("id");
Record returnedRec = stub.echo_Record(rec);
assertTrue(((MyRecord)rec).getAge() == ((MyRecord)returnedRec).getAge());
assertTrue(rec.getShortDescription().equals(returnedRec.getShortDescription()));
assertTrue(rec.getRecordId().equals(returnedRec.getRecordId()));
assertTrue(rec.getName().equals(returnedRec.getName()));
and everything works. I am not sure what the problem you are having is.
May I suggest you try my simplified example and see if it works for you.

What is the diff b/w Abstract class and an interface ?

Hey
I am always confused as with this issue : diff b/w Abstract class and an interface ?
Which is more powerful in what situation.
Regards
Vinay

Hi, Don't worry I am teach you
Abstract class and Interface
An abstract class can have instance methods that implement a default behavior. An Interface can only declare constants and instance methods, but cannot implement default behavior and all methods are implicitly abstract. An interface has all public members and no implementation. An abstract class is a class which may have the usual flavors of class members (private, protected, etc.), but has some abstract methods.
Edited by SASIKUMARA
SIT INNOVATIONS- Chennai
Message was edited by:
sasikumara
Message was edited by:
sasikumara

When we will go for an abstract class and when we will go for an interface?

it's always some what confusing to choose an abstract class and an interface,can anybody post a suitable answer for this.

jwenting wrote:
with experience and the insight it brings, you will know which to use when.
Without it, it can't be explained.
More often than not there's no X OR Y anyway.It's fortunate that there are posters here who possess the insight and experience necessary to explain this. The principal differences between an abstract class and an interface are,
1. An abstract class can carry implementation, whereas an interface cannot.
2. An abstract class is singly inherited, wheras an interface is multiply inherited.
So use an abstract class when the implementation it can carry outweights the fact that it cannot be multiply inherited That's the gist of it.
The inheritance relationship where this happens is when the supertype is a general concept of which all potential subtypes are special cases. This is called a specialization (or sometimes a generalization) relationship. For example Apple and Banana are Fruit. Or Car and Bike are Vechicle. The Fruit and Vechicle supertypes are general concepts of which their subtypes are special cases. In this case make Fruit and Vechicle abstract classes because the subtypes will benefit from a shared implementation.
If you don't have a clearcut specialization/generalization relationship make the supertype an interface. An example could be the Comparable supertype. The potential subtypes aren't supposed to be specializations of the Comparable concept, they're suppose to become Comparable (and make this property an integral part of their being). This is not a specialization/generalization relationship. Instead the supertype is intended to add character to the subtypes. The subtypes are unlikely to benefit from an inherited implementation. So make Comparable an interface.

Abstract class Vs interface

Hi,
I have to buid a report in ECM with complete details of the engineering as well as production. This include workflow as well as various fucntionality depends upon the criterion and user's event.
I am implementating in OOPS and I Want to know that when I should use the Abstract class and when interface ?
Because as per me both serve the same purpose. Kindly send me the exact difference so that i can efficiently use the same.
Thanks
Prince

When inheriting A Interface We have to inherit all the methods of the Interface there's no other option whereas with abstract classes we can inherit the members that we are in need of.
Just the interface has to have body of the method and the method is to be used by the classes inheriting it. Whereas in the case of Abstract Class it can have declarations (Other than the abstract method) and it can be further extended in the classes inheriting the Abstract Class.
Interface contains all abstract methods,all methods compulsory implemented by particular class, interface does not contain Constructor
abstract classes are designed with implemantion gaps for sub-class to fill in.
interfaces are sintacticlly similar to classes but they lack insance variables & methods.
abstract classes can also have both abstract methods & non-abstract methods. where as in interface methods are abstract only, & variables are implicitly static&final
regards
Preetesh

Extend abstract class & implement interface, different return type methods

abstract class X
public abstract String method();
interface Y
public void method();
class Z extends X implements Y
// Compiler error, If I don't implement both methods
// If I implement only one method, compiler error is thrown for not
// implementing another method
// If I implement both the methods,duplicate method error is thrown by
//compiler
The same problem can occur if both methods throw different checked exceptions,or if access modifiers are different..etc
I'm preparing for SCJP, So just had this weired thought. Please let me know
if there is a way to solve this.

Nothing you can do about it except for changing the design.
Kaj

Abstract classes & interfaces

In the API we have an interface namely:Set
which is implemented by an abstract class AbstractSet.
Class HashSet extends AbstractSet implements Set.
Now What is need for HashSet class to implement a Set interface when it is already extending from AbstractSet class that inturn implements Set interface.

This is probably an case of the folks at Sun refactoring their code and just missing one cleanup detail. The initial implementation of HashSet probably did not have a subclass. Then when they started to implement TreeSet, they realized that there was common functionality that they could reuse.
As the previous writer mentioned and you observed, there is no advantage or reason for HashSet to implement Set, it's probably just a harmless oversight.

When to use abstract classes instead of interfaces with extension methods in C#?

"Abstract class" and "interface" are similar concepts, with interface being the more abstract of the two. One differentiating factor is that abstract classes provide method implementations for derived classes when needed. In C#, however,
this differentiating factor has been reduced by the recent introduction of extension methods, which enable implementations to be provided for interface methods. Another differentiating factor is that a class can inherit only one abstract class (i.e., there
is no multiple inheritance), but it can implement multiple interfaces. This makes interfaces less restrictive and more flexible. So, in C#, when should we use abstract classes
instead of interfaces with extension methods?
A notable example of the interface + extension method model is LINQ, where query functionality is provided for any type that implements IEnumerable via
a multitude of extension methods.

Hi
Well I believe Interfaces have more uses in software design. You could decouple your component implementing against interfaces so that
you have more flexibility on changing your code with less risk. Like Inversion of Control patterns where you can use interfaces and then when you decide you can change the concrete implementation that you want to use. Or other uses for interfaces is you could
use Interceptors using interfaces (Unity
Interceptor) to do different things where not all of these is feasible or at least as straightforward using abstract classes.
Regards
Aram

OC4J 9.0.4 migrate to 10.1.3.1 JSP fails using abstract class for ResultSet

Consider the following JSP code snipet:
<%
com.class.SQLDataSource detail = ((com.class.SQLDataSource)request.getAttribute("AcctList"));
%>
<%while detail.next()) {detail.getRow();%>
<tr ...>
<td ...><%= detail.getString("ACCT") %></td>
</tr>
<%}%>
blah, blah, blah
class snipet looks like this:
public abstarct class SQLDataSource extends serializable {
private ResultSet resultSet = null;
private PreparesStatement stmt = null;
public boolean next() throws SQLException {
boolean result = getResultSet().next();
return (result);
public String getString(String columnName) throws SQLExcpetion {
return getResultSet().getString(columnName);
public void execute() throws SQLException {
-- checks stmt
-- if null generates resultSet from "AcctList.sql" query
-- if not null, re-executes as-is stmt for a query only
protected ResultSet getResultSet() throws SQLException {
execute(); // see above
return resultSet;
The problem:
<%= detail.getString("ACCT") %> generates a NullPointerException
Yet, if I add debug statements in the SQLDataSouce class, they conclusively show that resultSet has 1902 rows and I can diplay the contents on these rows (on the console, of course, the JSP still generates a NullPointerException).
If I "hardcode" the creation of a ResultSet in the JSP, the pages displays properly (not the desired method).
PLEASE TAKE NOTE: This JSP/Class combination works PERFECTLY in OC4J 9.0.4 using JDeveloper 9.0.5.2. When I deploy the **EXACT SAME** JSP/Class combination in JDeveloper/OC4J 10.1.3.1, I receive the NullPointerException.
So what this feels like to me (and my VERY limited J2EE experinece) is that the abstract class SQLDataSource has somehow lost/closed/dropped/corrupted resultSet when "returning" to the JSP for display of the contents of resultSet. This is, of course, a laymans explanation of the experienced effect of running this code.
It makes me wonder if under 10.1.3.1 "something more" must be done so that the (abstract) SQLDataSource class can operate in the same way it did under 9.0.4.
Last note: this NullPointerException happens whether I deploy to standalone OC4J 10.1.3.1 or if I execute my application withing JDevloper's Embedded OC4J instance.
Any Assistance on this MOST aggrivating problem would be greatly appreciated.
Others have yet to solve it in similar posts of mine. Hopefully this more definitive description will help YOU be my personal HERO.
Ed.

repost to pique interest

Interfaces / Abstract classes / ResultSets

Similar Messages

Maybe you are looking for