Implemetation of abstract classes (WindowAdapter 4 example)

Hi,
Since I migrate form JDev9i beta version to JDev9i v 9.0.2.829 I unable to recompile all the java source wich implement abstract classes.
an example :
source code :
frame.setLocation((screenSize.width - frameSize.width) / 2, (screenSize.height - frameSize.height) / 2);
frame.addWindowListener(new WindowAdapter()
public void windowClosing(WindowEvent e)
System.exit(0);
give me this error when i try to compile:
Error(30,5): class DiscoReader$1 not found in class DiscoReader.DiscoReader
where DiscoReader is the name of my package and the name of this class in this package.
Did someone experiment this problem ? and of course, did someone know how to solve it ?
thanks
Olivier Ardouin
mailto:[email protected]

I believe this problem is already fixed in 9.0.3, shortly available on OTN.
Thanks for reporting it,
Michel

Similar Messages

Abstract classes in jave.i0

I have read that you cannot create and instance of an abstract class. If that is correct how is it possiable that I can code this ?
File Myfile = new File('c:/abc.txt);
What am I missing can anyone help ?

Ohh, wait, got it.
java.io.File An abstract representation of file and directory pathnames.
It is not an abstract class, if you look at an abstract class AbstractList for example, it will say "abstract class AbstractList" in the API.
File however takes a concept common (but not necessary identical) to all operating Systems (like Windows, Linux and MacOS X), but "abstracts" it, so you the developer are not exposed to the differences between OSes.

".. is an abstract class. It can't be instantiated"

Does anyone have an idea of how I can get rid of the above error message? Here is a bit of my code:
import java.io.*;
import java.util.Vector;
class Project3 {
private BiTree company = new BiTree();
public static void main(String[] args) throws IOException {
Project3 run = new Project3();
run.Command();
public void Command() throws IOException {}
public interface comparable {
//not sure if need this in this class, or at all
public int compare(Object object1,Object object2);
public void add() {
Employee newOne = new Employee();
System.out.println("Enter name");
BufferedReader stdin = new BufferedReader (new InputStreamReader (System.in));;
String name = stdin.readLine();
System.out.println("Enter title");
BufferedReader stdin = new BufferedReader (new InputStreamReader (System.in));;
String title = stdin.readLine();
System.out.println("Enter payrate");
BufferedReader stdin = new BufferedReader (new InputStreamReader (System.in));;
payrate = Double.parseDouble.stdin.readLine();
newOne.setTitle(title);
newOne.setName(name);
newOne.setPayrate(payrate);
company.insert(newOne);
}

It is not possible to create instances of an abstract class.
I hope this example helps,
abstract class Vehicle
public static void main(String arg[])
Vehicle a;
a = new Automobile(); // ok, since Automobile is a kind of Vehicle
// The class Automobile, a special case of Vehicle
class Automobile extends Vehicle

Difference between abstract class and the normal class

Hi...........
can anyone tell me use of abstract class instead of normal class
The main doubt for me is...
1.why we are defining the abstract method in a abstract class and then implementing that in to the normal class.instead of that we can straight way create and implement the method in normal class right...../

Class vs. interface
Some say you should define all classes in terms of interfaces, but I think recommendation seems a bit extreme. I use interfaces when I see that something in my design will change frequently.
For example, the Strategy pattern lets you swap new algorithms and processes into your program without altering the objects that use them. A media player might know how to play CDs, MP3s, and wav files. Of course, you don't want to hardcode those playback algorithms into the player; that will make it difficult to add a new format like AVI. Furthermore, your code will be littered with useless case statements. And to add insult to injury, you will need to update those case statements each time you add a new algorithm. All in all, this is not a very object-oriented way to program.
With the Strategy pattern, you can simply encapsulate the algorithm behind an object. If you do that, you can provide new media plug-ins at any time. Let's call the plug-in class MediaStrategy. That object would have one method: playStream(Stream s). So to add a new algorithm, we simply extend our algorithm class. Now, when the program encounters the new media type, it simply delegates the playing of the stream to our media strategy. Of course, you'll need some plumbing to properly instantiate the algorithm strategies you will need.
This is an excellent place to use an interface. We've used the Strategy pattern, which clearly indicates a place in the design that will change. Thus, you should define the strategy as an interface. You should generally favor interfaces over inheritance when you want an object to have a certain type; in this case, MediaStrategy. Relying on inheritance for type identity is dangerous; it locks you into a particular inheritance hierarchy. Java doesn't allow multiple inheritance, so you can't extend something that gives you a useful implementation or more type identity.
Interface vs. abstract class
Choosing interfaces and abstract classes is not an either/or proposition. If you need to change your design, make it an interface. However, you may have abstract classes that provide some default behavior. Abstract classes are excellent candidates inside of application frameworks.
Abstract classes let you define some behaviors; they force your subclasses to provide others. For example, if you have an application framework, an abstract class may provide default services such as event and message handling. Those services allow your application to plug in to your application framework. However, there is some application-specific functionality that only your application can perform. Such functionality might include startup and shutdown tasks, which are often application-dependent. So instead of trying to define that behavior itself, the abstract base class can declare abstract shutdown and startup methods. The base class knows that it needs those methods, but an abstract class lets your class admit that it doesn't know how to perform those actions; it only knows that it must initiate the actions. When it is time to start up, the abstract class can call the startup method. When the base class calls this method, Java calls the method defined by the child class.

Can i call non -abstract method in abstract class into a derived class?

Hi all,
Is it possible in java to call a non-abstract method in a abstact class from a class derived from it or this is not possible in java.
The following example will explain this Ques. in detail.
abstract class A
void amethod()
System.out.println(" I am in Base Class");
public class B extends A
void amethod()
System.out.println(" I am in Derived Class");
public static void main (String args[])
// How i code this part to call a method amathod() which will print "I am in Base Class
}

Ok, if you want to call a non-static method from a
static method, then you have to provide an object. In
this case it does not matter whether the method is in
an abstract base class or whatever. You simply cannot
(in any object oriented language, including C++ and
JAVA) call a nonstatic method without providing an
object, on which you will call the method.
To my solution with reflection: It also only works,
if you have an object. And: if you use
getDeclaredMethod, then invoke should not call B's
method, but A's. if you would use getMethod, then the
Method object returned would reflect to B's method.
The process of resolving overloaded methods is
performed during the getMethod call, not during the
invoke (at least AFAIK, please tell me, if I'm wrong).You are wrong....
class A {
    public void dummy() {
         System.out.println("Dymmy in A");
class B extends A {
     public void dummy() {
          System.out.println("Dymmy in B");
     public static void main(String[] args) throws Exception {
          A tmp = new B();
          Class clazz = A.class;
          Method method = clazz.getDeclaredMethod("dummy", null);
          method.invoke(tmp, null);
}Prints:
Dymmy in B
/Kaj

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.

Non-abstract methods in a Abstract class

Abstract Class can contain Non-abstract methods.
and Abstract Classes are not instantiable as well
So,
What is the purpose of Non-abstract methods in a Abstract class.
since we can't create objects and use it
so these non-abstract methods are only available to subclasses.
(if the subclass is not marked as abstract)
is that the advantage that has.(availability in subclass)
??

For example, the AbstractCollection class (in
java.util) provides an implementation for many of the
methods defined in the Collection interface.
Subclasses only have to implement a few more methods
to fulfill the Collection contract. Subclasses may
also choose to override the AbstractCollection
functionality if - for example - they know how to
provide an optimized implementation based on
characteristics of the actual subclass.Another example is the abstract class MouseAdapter that implements MouseListener, MouseWheelListener, MouseMotionListener, and that you can use instead of these interfaces when you want to react to one or two types of events only.
Quoting the javadocs: "If you implement the MouseListener, MouseMotionListener interface, you have to define all of the methods in it. This abstract class defines null methods for them all, so you can only have to define methods for events you care about."

Abstract class extends other class?

What happens when a abstract class extends other class?
How can we use the abstract class late in other class?
Why do we need an abstract class that extends other class?
for example:-
public abstract class ABC extends EFG {
public class EFG{
private String name="";
private int rollno="";
private void setName(int name)
this.name=name;
private String getName()
return this.name;
}

shafiur wrote:
What happens when a abstract class extends other class?Nothing special. You have defined an abstract class.
How can we use the abstract class late in other class?Define "Late". What "other class"?
Why do we need an abstract class that extends other class?Because it can be useful to define one.

Why use an Abstract Class ?

I am new to Java and for some reason I can't get my head around why to use an abstract class. I understand that an abstract class is something like:
public abstract class Food{ // abstract class
public void eat(){
// stub
public class Apple extends Food{
public void eat(){
// Eat an apple code
}So basically the idea above is that you can eat an "apple" but you can't eat "food" because you can't instantiate an abstract class.
I understand what an abstract class is and how to write one. What I don't understand is why you would use it? It looks to me like I could have just created a normal class called "Food" and just not instantiated it. What are the benefits of using an abstract class?

807479 wrote:
I am new to Java and for some reason I can't get my head around why to use an abstract class.One of the first books I ever read about Object-Oriented design contained the following quote from [url http://en.wikipedia.org/wiki/Lucius_Cary,_2nd_Viscount_Falkland]Lord Falkland:
"When it is not necessary to make a decision, it is necessary +not+ to make a decision."
It took me quite a while to understand, but it's all about flexibility: As soon as you cast something in stone, you lose the ability to change it later on if something better/more appropriate comes along. Interfaces and abstract classes are all about delaying that decision.
As jverd said, interfaces allow you to specify what is required without defining the how; and as ErasP said, abstract classes are usually incomplete: ie, they define some of the 'how', but not all of it.
What is most important about abstract classes though is that they cannot exist on their own: They must be extended by a concrete class that completes the 'how' before they can be instantiated and, as such, they declare the intent of the designer.
One of the most important uses of abstract classes is as "skeleton implementations" of interfaces, and there are a lot of examples of these in the Java Collections hierarchy. My favourite is probably AbstractList, which contains a skeleton implementation of a List. Because it exists, I can create a class that wraps an array as a List with very little code, viz:public final class ArrayAsList<T>()
   extends AbstractList<T>
   private final T[] values;
   public ArrayAsList(T... values) {
      this.values = values;
   @Override
   public T get(int index) {
      return values[index];
   @Override
   public T set(int index, T element) {
      T value = get(index);
      values[index] = element;
      return value;
   @Override
   public int size() {
      return values.length;
};and somewhere else, I can use it:   List<String> letters =
      new ArrayAsList<String>("a", "b", "c");or perhaps, more practically:   List<String> words = new ArrayAsList<String>(
      bigTextString.split(" +") );Now that may not seem like a big deal to you, but given all that Lists can do, it's actually a very powerful bit of code. The above example is from "Effective Java" (p.95).
HIH
Winston

Abstract classes and static methods

I have an abstract report class AbstractReportClass which I am extending in multiple report classes (one for each report, say ReportA, ReportB, ...). Each report class has its own static column definitions, title, etc., which I have to access through a static method getDataMeta() in a web application. Each report has the same exact code in getDataMeta, and no report may exist without these fields. My intuition tells me that AbstractReportClass should contain the code for getDataMeta, but I know that you can't mix abstract and static keywords.
Am I missing a simple solution to unify the getDataMeta code in the abstract base class? or do I really need to have a static function getDataMeta with the same code in each of the base classes?
My apologies if this has been discussed many times before.
Thanks,
-Andrew

I'm not trying to be "right"; rather I just asked a question about whether I can do something that seems intuitive. Perhaps you might write code in a different way than I would or perhaps I wasn't clear about every little detail about my code? Do you regularly belittle people who ask questions here?
I have a loadFromDB() member function in AbstractReport for which all sub classes have an overloaded version. All reports I'm displaying have 4 common fields (a database id and a name and a monetary value, for example), but then each other report has additional fields it loads from the database. Inside ReportX classes' loadFromDB(), I call the superclass loadFromDB() function and augment values to get a completely loaded object. In fact, the loadedData member object resides in AbstractReport.
I can't use a report unless it has these common features. Every report is an AbstractReport. There is common functionality built on top of common objects. Isn't this the point of inheritance? I'm essentially saying that abstract class Shape has a getArea function and then I'm defining multiple types of Shapes (e.g. Rectangle and Circle) to work with...

Why abstract classes

Pals,
Abstract classes help us in abstracting common code. The same can be achieved by using a plain java class with static methods and extending them. What extra does this abstract keyword provides

Thanks fro the reply , but still im confused ,
partial implementations can also be done using the
Plain class (say class A)and having a non static
method in it (say methA(). Another class can can
extend this class A and use / override this(methA())
partial implementation of class A. I googled but
couldnt find an explaining answerIn the JDK that you downloaded is src.zip. Unzip it. Look at the source code for some of the abstract classes and the concrete classes that extend them.
For example, in List implementations, how you implement the add method is very much dependent on how the list is implemented. It's very different for a LinkedList vs. an ArrayList. It's highly dependent on the data structure that holds the list's elments. There's no reasonable way to implement it in the base class, so it's abstract.
The addAll method, on the other hand, can be implemented completely in terms of other methods and is not dependent on the implementation details. You simply iterate over the collection that's passed in as an arg, and for each of its elements, you call this list's add() method. So addAll can be implemented in the base class--all subclasses can use the same implementation.

Abstract Class Polymorphism?

I want to be able to add any of my sub classes to a collection (hash set) , without duplicating the code. The superclass for all these subclasses is an abstract class.
Is there a possible way of achieving this?
At the moment I have methods for each individual class; before making the parent class abstract, I could use the same method for all, but was advised as I did not want an instance of that parent class, the abstract class was best.
Hope this is not too vague or abstract... :)

I think if you use the wildcard symbol it'll allow you to add a covariant to the collection, for example
public static void addSub(List<? super NameofSuperClass> varName)
When you can to retrieve the data, if you want any methods not in the super class you would still be to cast it.
Is this what you meant? - Peter sorry if it wasn't helpful

Abstract class initialisation

Hi,
I have the following problem. What do you suggest?
I have an interface A, abstract class B, B's subclasses C and D, and mainClass
interface A
abstract class B implements A {
    B b;
    public B(String desc)
     if (desc.equals("C")) b=new C();
     else if (desc.equals("D")) b=new D();
class C extends {
public C() {}
class D extends {
public D() {}
class mainClass{
B b=new B("C"); // but B can not be initiated
}B is an abstract class and can not be initiated, I can not define B as normal class, because in B, I define some abstract methods
and want all its subclasses to define them.
What do you suggest me for enhancement?

Hi duffymo,
Your answer quite intersting, can you provide some concrete example!
Do you mean like this:
interface A
class B implements A{
B b;
public B(String desc) {
b=Class.newInstance(desc);
class C extends B
class main {
B=new B(desc);
It seems quite okey, but the problem is that I want subclasses (C and D) to impelement some certain methods. Thus I though B as abstract class
It's called a Factory class or virtual constructor -
that's how you create different runtime types. It's a
GOF Pattern - read about it.
I wouldn't build all that stuff into the abstract B
constructor. That'll force you to modify the B class
every time you add a new subtype - that's not a good
idea. Move that code out into a separate class named
AFactory and give it a static method that does that
creation stuff for you. I know - "That just moves the
changes out of B and into the AFactory" - yes, but I
think that's where they belong.
The java.lang.Class class has a factory method built
into it already - newInstance(). You can use that to
instantiate different subclasses:
A newInstance = Class.newInstance("C");
A anotherInstance = Class.newInstance("D");That's the way I'd do it. - MOD

Abstract class or inteface

Pls give me some practical example of choosing among abstract class and interface.

An interface is a definition of what a class should look like from the outside: use it for defining a type of class that will have multiple implementations. For instance in the 'Observer ' pattern any class implementing the observer interface can be attached to the subject. In this way when implementing the subject there is no need to know how the observers will be implemented.
An abstract class is typically used to implement some code that is common amongst all derived classes. Coming back to the observer pattern. A abstract class BaseSubject could have some code for storing observers that have to be attached. In this way the code get's recycled and double code is prevented.
It is very common to combine an interface with some abstract implementation. For instance when an interface has methods for attaching observers and a run method that should do 'something'. The abstract base class for all implementation could implement the attach/detach observer stuff and publish a protected method notifyObservers. An the actual classes extending this class need only fill in the run method.
Hope this helps!

Abstract class confusion

I am writing a J2ME application, and I want to write a Record management system (RMS) that I can use in other J2ME programs. I have a Record class that RMS classes need to know about. The idea is that the Record class is abstract, and the implementation is defined by a subclass - depending on what the application needs to store. Any Record must provide the following:
1) A constructor which takes a single byte[] parameter, which is the data read in from the RecordStore by the RMS. The implementation depends on what information is stored in this type of Record - it might be a String, series of ints, etc...
2) A method getStorageFormat() which returns a btye[] representing the data to be stored in the RecordStore. Again, this is dependent on the application.
I think that I have to use an abstract class here, so I have written an abstract class called Record - here's what it looks like:
public abstract class Record {
     public Record(byte[] bytes) { }; //Should this be an empty constructor?
     public abstract byte[] getStorageFormat();
}My problem is that I can't define a subclass of Record that works! Here's an example:
public class MyRecord extends Record {
       String data1, data2, data3; //Some data that is stored in this record
       public MyRecord(byte[] bytes) {
              String data = new String(bytes);
              // do some processing to extract the data...
       public byte[] getStorageFormat() {
              String sep = ","; //A seperator
              String tmp = data1 + sep + data2 + sep + data3; //put all the data together with
              return tmp.getBytes();
}}I get an error in Eclipse with the MyRecord constructor that says:" The implicit super constructor Record() is undefined. Must explicity invoke another constructor". I tried super() but I get the same error. Can anyone please tell me what I am doing wrong? It seems to me that I am misunderstanding something about how abstract classes work.

Because you defined a ctor that takes args, the implicit one that takes no args--super()--is no longer implicitly supplied. You have to either put a no-arg ctor into the parent class, or call the one that you already have.
public Record(byte[] bytes) { }; //Should this be an empty constructor?
public abstract byte[] getStorageFormat();
}No. You don't want a ctor that takes args and does nothing. If you're taking that arg, then you should use it to initialize the state of the object.
Here are the rules for constructors--"ctors" because I'm lazy. Also, because I'm lazy, "super(...)" and "this(...)" mean any super or this call, regardless of how many args it takes, including those that take no args.
1) Every class has at least one ctor.
1.1) If you do not define an explicit constructor for your class, the compiler provides a implicit constructor that takes no args and simply calls super().
1.2) If you do define one or more explicit constructors, regardless of whether they take args, then the compiler no longer provides the implicit no-arg ctor. In this case, you must explicitly define a
public MyClass() {...}
if you want one.
1.3) Constructors are not inherited.
2) The first statement in the body of any ctor is either a call to a superclass ctor
super(...)
or a call to another ctor of this class
this(...)
2.1) If you do not explicitly put a call to super(...) or this(...) as the first statement in a ctor that you define, then the compiler implicitly inserts a call to super's no-arg ctor
super()
as the first call. The implicitly called ctor is always super's no-arg ctor, regardless of whether the currently running ctor takes args.
2.2) There is always exactly one call to either super(...) or this(...) in each constructor, and it is always the first call. You can't put in more than one, and if you put one in, the compiler's implicitly provided one is removed.

Implemetation of abstract classes (WindowAdapter 4 example)

Similar Messages

Maybe you are looking for