This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: PR java/21436: imported type name for superclass, with multifilecompilation


> I am all but a Java language lawyer, but I don't see how in practice
> one could derive a concrete class from the testcase in jacks:

abstract class T151221am2a { abstract void m(); }
interface T151221am2b { void m() throws Exception; }
public abstract class T151221am2c
  extends T151221am2a implements T151221am2b { }


> I could stare at the JLS for a while, but how can you define
> *both* "m()" and "m() throws Exception" in a concrete subclass?

"void m() throws Exception" mean m() *might* throw an exception,
it does not mean that m() has to throw an exception.

So in that case, there is only one m() in T151221am2c, and it
doesn't throw Exception.

 class Yeah extends T151221am2c {
   public void m() { System.out.println("Yeah"); }
 }

would be a valid concrete class, which implements T151221am2b even though it cannot throw Exception. (Subclasses/Subinterfaces
could throw less exception than the base class, not more)


Cedric




Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]