Can interface extend abstract class?

Can interface extend abstract class?
I tried to make a interface extend an abstract class but i got an error stating:
interface expected here.
Can anyone help me ?

> ok, but can an interface implement an abstract class?
No. An interface provides no implementation whatsoever. An abstract class can implement an interface, but not the other way around.
http://java.sun.com/docs/books/tutorial/java/concepts/interface.html
~

Similar Messages

  • Cloneable interface extends Object Class ? T/F can anybody ?

    Can a Interface extend Class?
    If not so, then how come Cloneable Interface extends Objects Class.
    if so, how? can anybody help me out.

    Beats me how you made the jump to this example. Whats
    happening
    here is that when you initialize byte b with the
    integer literal 5, the compiler
    is smart enough to figure out that 5 is in the range
    of byte values,
    so it doesn't complain.I understand what is going on and I know it is somewhat of a stretch but it still feels the same to me.
    As you said, the compiler is smart enough to know that 5 will fit and does not complain; however, according to the JLS integer literals are ints.
    That makes the above example an exception to the casting rule similar to the casting exception between interfaces and Object. Although, the interface situation may very well be specified in the JSL - it might say that all interfaces are a descendent of Object (I can not remember - need to look).

  • JSF annotations on interface or abstract class

    Hello,
    Can we use JSF 2 annotations like @ManagedBeans or @SessionScoped for interfaces and abstract classes? I mean, will it works if I implement an interface which declares some annotation(s) and the managed bean class itself doesn't have annotations?
    Thanks a lot!
    Oleg.

    Okey, an example:
    @ManagedBean
    public abstract class MyAbstractClass {
    public class MyClass extends MyAbstractClass {
    Does it work if I access MyClass by ValueExpression #{myAbstractClass} ? Will be MyClass automatically annotated with @ManagedBean?
    Best regards.
    Oleg.

  • Interface and Abstract class difference

    An interface can be used in such a way that we don't know the class of object assigned to a reference of that interface type until runtime. Can we use the abstract class in a similar way too?
    The difference between an abstract class and interface can be listed as
    1. Interface can not have implementation of any method
    2. The usage of interface and class is one other difference
    3. What other differences we have?

    Yes an abstract class can be used in a similar way. The main issue with an abstract class is that you extend it and you can only extend one class so that can be a huge limitation that an interface does not give you.
    Here's another one that is often overlooked: use both.
    public abstract class SomeBaseClass implements Runnable {
      public abstract void someAbstractMethod();
      public void someMethodWithADefaultImplementation(){
        System.out.println("Hello!");
    }Any class that extends SomeBaseClass (and is not abstract) will need to implement the run() method of the Runnable interface.

  • Interfaces and abstract classes

    can anyone pls tell me where exactly an abstract class is used and where exactly an interface is to be used.
    i think the main difference between an abstract class and an interface is that an interface will have all the abstract methods whereas an abstract class can have one or more abstract methods--- if i am not wrong.
    anything to add? -- pls let me know on this....
    and also how they might be useful for us....

    Inheritance is the most popular feature of the OOP. By organising classes into class hierachy it gives an extra dimension to the encapsulation of abstract data types becauase it enables classes to inherit attributes/methods from other classes.
    There are two complementary roles of inheritance in OOP application.
    1. Specialisation: Extending the functionality of an existing class.
    2. Generalisation: Sharing commonality between two or more classes.
    So adding functionality by extending what exists at each level to create more specialized classes. This would create a hierarchy and would be helpful even later on in maintenance.
    Now when to have an abstarct class and when an interface. An interface just defines the basic functionality to be implemented by all the subclasses, though the way they are implemented may be different. e.g an interfaca animal can have all those functionalities common to all animals in basics but different in implementation. e.g all animals walk however some walk on two legs and some on four. All animals can see but they might have a different colour spectrum visible. So all such methods general but common can be in an interface.
    Abstract classes come into play at a more defined level e.g in an abstract class human though walk would be the same so implemented there and then but talking can be left abstract since there may be different languages involved.
    For more details refer to a good OOP book.

  • Interfaces vs abstract classes

    hi,
    i have some kind of general idea about interfaces and abstract classes.but what are the situations that are most suitable for use interfaces and abstract classes..if u have any idea pls help me
    thanx and best regards,
    Kelum

    BigDaddyLoveHandles wrote:
    Reason for using interfaces #17: dynamic proxies.
    import java.lang.reflect.*;
    interface Fooable {
    void f();
    void g(int x);
    class Foo implements Fooable {
    public void f(){ System.out.println("Foo.f()"); }
    public void g(int x){ System.out.format("Foo.g(%d)", x); }
    public class ProxyExample implements InvocationHandler {
    private Fooable target = new Foo();
    public static void main(String[] args) {
    Fooable fooable = (Fooable) Proxy.newProxyInstance(
    Fooable.class.getClassLoader(),
    new Class[] { Fooable.class },
    new ProxyExample());
    fooable.f();
    fooable.g(17);
    public Object invoke(Object proxy, Method method, Object[] args) throws Throwable {
    System.out.println("Invoking: " + method.getName());
    return method.invoke(target, args);
    <cat position_relative_to_pigeons="among">
    Although libraries like ASM or CGLIB allow you to dynamically proxy classes, too
    </cat>

  • 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

  • Hi all,Interface vs Abstract class

    Hi, All When We are going to use interface or an Abstract class,Can tell exactly
    Thanks in advance

    Interface class is used to contain methods that is to be defined by children classes. And abstract class, even though you can have all methods being abstract, but normally I would use this class for situation such as implement methods that are general enough to be used by the children classes and left others being abstract to be implemented by children classes later. I always think this relationship in a simple way:
    Abstract Class: Animal
    Interface : Leg, Tail, Hair, Feather, Head...
    Children classes: Tiger, Bird, etc.
    Thus, for class Animal class you can have methods such as:
    Abstract: canRoar, canSing, canFly, ...
    Non-abstract: isSleeping, isAlive...
    More example:
    Tiger extends Animal implements Leg, Tail, Head, Hair
    Bird extends Animal implements Leg, Feather, Head
    I could be wrong, correct me if so. Cheers.

  • Extending abstract classes such as ByteBuffer?

    How would I extend an abstract class such as ByteBuffer?
    If I call the normal extends key word:
    public class MyBuffer extends ByteBuffer
    then I need to implement virtually every method in the class.
    But If I just create a ByteBuffer such as:
    ByteBuffer buf = BtyeBuffer.Allocate(100);
    then I can just go and use all of the various methods witin the class without have to implement anything.
    But I need to add an additional method to ByteBuffer . What is the best way to do this? I realize I can encapsulate a ByteBuffer object but that does not sound like a good idea.
    Is there a better way? If so what?

    Thanks. Well that gets me started.
    I have:
    public abstract class SerialPortBuffer extends ByteBuffer {
    and I am getting:
    Implicit super constructor ByteBuffer() is undefined for default constructor. Must define an explicit constructor     
    How do I fix this? Sorry for the newbie questions.

  • Extending Abstract Classes such I ByteBuffer?

    Sorry for the cross post but I think I posted this in the wrong forum origanally.
    I need to extend ByteBuffer so I did so like this:
    public abstract class SerialPortBuffer extends ByteBuffer {
    but now I am getting:
    Implicit super constructor ByteBuffer() is undefined for default constructor. Must define an explicit constructor
    How do I fix this? Sorry for the newbie questions and the goof on the cross post.

    >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
    But I dodnot think defining a no args constructor explicitly would remove the problem, since the no args constructor is still undefined in the super class. You need to define a constructor woth some arguments
    >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
    public abstract class SerialPortBuffer extends ByteBuffer {
         * @param arg0
         * @param arg1
         * @param arg2
         * @param arg3
         SerialPortBuffer(int arg0, int arg1, int arg2, int arg3) {
              super(arg0, arg1, arg2, arg3);
              // TODO Auto-generated constructor stub
    When I try this I get.
    The constructor ByteBuffer(int, int, int, int) is not visibe
    Can anyone tell me how to extend ByteBuffer?

  • Interface and abstract class

    why we have constructor for abstract class and not for interface,

    When you call a constructor of a class which is extended by abstract class. It runs first the abstract class constructor and then child class constructor and initialize the member variables.
    while interface has no variable all final data so interface is no need to implement a constructor.
    Regards,

  • Extending Abstract Classes & Program Entry Point

    I have the following classes:
    CopServlet - which extends PercServlet
    PercServlet - abstract class which extends HttpServlet
    HttpServlet is the base class. I'm using Visual Age with a web.xml file that points to CopSerlet as the controller servlet. So my question is... When CopServlet gets called, where is my program entry point? My CopServlet class does NOT have a main method.

    When CopServlet gets loaded, its init() method is called. And when it is called via an HTTP request, either its doGet() or its doPost() method is called, depending on whether it was a GET or a POST request. That's how servlets work. The business about abstract classes is irrelevant to that.

  • Why a nested class can instantiate an abstract class?

    Hi people!
    I'm studying for a SCJP 6, and i encountered this question that i can figure it out but i don't find any official information of my guess.
    I have the following code:
    public class W7TESTOQ2 {
        public static void main(String[] args) {
           // dodo dodo1 = new dodo();
            dodo dodo2 =new dodo(){public String get(){return "filan";}};
            dodo.brain b = dodo2.new brain(){public String get(){return "stored ";}};
            System.out.print(dodo2.get()+" ");
            System.out.println(b.get());
    abstract class dodo
        public String get()
            return "poll";
        abstract class brain
            public abstract String get();
    }I know that abstract classes cannot be instantiated but i see that in this example, with a nested anonymous class it does (dodo and brain classes). My guess is that declaring the nested class it makes a subclass of the abstract class and doing so it can be instantiated. But i can't find any documentation about this.
    Does anybody know?
    Really thanks in advance.
    Regards,
    Christian Vielma

    cvielma wrote:
    Another question about this. Why can't i declare a constructor in the nested class? (it gives me return type required)You cannot declare a constructor, because in one line you're declaring a new class (the anonymous inner class) as well as constructing an instance of it.
    What you can do, however, is if the abstract class (or the superclass, in any case, it doesn't need to be abstract) defines several constructors, you can call them.
    public abstract MyClass {
        public MyClass() {
            // Default do nothing constructor
        public MyClass(String s) {
            // Another constructor
    // Elsewhere
    MyClass myclass = new MyClass("Calling the string constructor") {
    };But you can't define your own constructors in the anonymous inner class.
    Also, since the class is anonymous, what would you name the constructor? :)
    Edited by: Kayaman on 26.6.2010 22:37

  • Extending abstract classes

    I just have a simple question. I have one class which is abstract
    public abstract class Person
         private String firstName;
         private String lastName;
         private String title;
         private String dateOfBirth;
         private String homeAddress;
         private String phoneNumber;
         public static final String MR = "Mr";
         public static final String MISS = "Miss";
         public static final String MS = "Ms";
         public static final String MRS = "Mrs";
         public static final String DR = "DR";
         public static final String PROF = "Prof";
         public Person(String firstName, String lastName, String title, String dateOfBirth,
                         String homeAddress, String phoneNumber){
              this.firstName=firstName;
              this.lastName=lastName;
              this.title=title;
              this.dateOfBirth=dateOfBirth;
              this.homeAddress=homeAddress;
              this.phoneNumber=phoneNumber;
         And i have another class which extends this class
    public abstract class Borrower extends Person{
      public LibraryItem [] itemsBorrowed;
      private double currentFine;
      private int barCode;
      public LibraryItem [] getItemsBorrowed()
           return itemsBorrowed;
      public double getCurrentFine()
           return currentFine;
      public int getBarCode()
           return barCode;
      }When i try to compile these two classes, i get the error
    Cannot find symbal constructor Person(). The problem is that the tutor hates us providing default constructors, and i presume that this is what the error is asking for. Is there any way around this or does a default constructor need to be povided?
    cheers

    codingMonkey wrote:
    georgemc wrote:
    nick2price wrote:
    Ok, i get you, better call the superclass constructor as tutor hates me using no param constructorsChallenge him on that. Not only are they perfectly acceptable, they're a mandatory part of the JavaBeans spec.Personally, even though there are nothing wrong with them, I prefer to avoid no-arg constructors in a lot of cases. Usually when I feel that a class should always have certain attributes. I.e. instead of having a no-arg constructor for something like a Person class, I'd rather have a constructor that takes at least a name. It is true that the name could always be initialized in the no-arg constructor, but I would think that it makes more sense for a person to always have a name, rather than being called "null" or "N/A".If you plan on using any framework that uses the Beans spec (and while the inexperienced, self-professed "purist" might balk at that, you'll find it virtually impossible to avoid as a commercial coder) you won't be able to with those classes. Your argument about always needing a sensible starting point falls down where you have multiple disparate types that you are re-constructing. While it's quite nice to say "a Person should always have a Name", if you have, for example, a persistence framework that will generically map the results of various database queries back onto Java objects, you have to write some special case code for each class in your domain model, that says "in order to contruct this object, you first need to perform this query, then invoke this constructor with this part of the result of that query, then populate the rest of the properties using setter methods". For every class in your domain model. That's a fair amount of overhead. The no-args constructor model completely circumvents that, since everything's populated by the same generic code - beans introspection. Think about it. For every class in your model, you have to have separate chunks of code that are aware of - and hence, coupled to - a specific query, and a specific constructor of a specific class. Far from ideal.
    Even if you decide to roll your own code to manage peristence, configuration, remoting and the like, you'll still eventually settle on no-args constructors as extremely handy tools. Note that I'm all for the presence of other constructors as well, that do allow sensible creation of objects with certain values. Just that the no-args constructor is so infinitely useful for writing a huge amount of generic code
    I would think that it makes more sense for a person to always have a name, rather than being called "null" or "N/A".Me too. And there's nothing in any of my points that gainsays, or opposes that. You create a Person instance, and he's called "null" for a few clock cycles before you populate him from a database query - nothing wrong with that

  • Internal class implementing interface extending abstract interface :P

    Confused ha? Yeah me too. RIght here it goes.
    Theres an abstract interface (abstractIFace) that has for example method1() method2() and method3(). There are two other interfaces iFace1 and iFace2 that extend abstractIFace. Still with me? :P iFace1 only uses method2() whereas iFace2 uses method1(), method2() and method3(). Internal classes implementing these are then used. The reason is so that when returning an object one method can be used that will return different types of objects. But this doesnt work. It says that all the classes in the abstractIFace must be used/implemented but I only want method2() in iFace1 and all in iFace2.
    Just say what the f*ck if this is too confusing cos i think it is and i did a crap job explaining!! :P

    public interface IFace {
        void method1();
        void method2();
        void method3();
    public class Test {
        private static class Class1 implements IFace {
            public void method1() {
                System.out.println("method1");
            public void method2() {
                System.out.println("method2");
            public void method3() {
                System.out.println("method3");
        private static class Class2 implements IFace {
            public void method1() {
                throw new UnsupportedOperationException();
            public void method2() {
                System.out.println("method2");
            public void method3() {
                throw new UnsupportedOperationException();
        public static IFace createObject(boolean flag) {
            return flag ? (IFace) new Class1() : new Class2();
    }

Maybe you are looking for