🚀 go-pugleaf

Thinking about it you have indeed found a bug but in the compiler not the
VM. It shouldn't allow calling of an abstract method in the same class from
the contructor. This is for the same reason that you cannot use an instance
variable a call to the super class contructor which the compiler does in
fact stop you doing.

The compiler shouldn't let you do what you are doing as it's bound to cause
problems!


John Baker <jbaker@SoftComms.com> wrote in message news:3be65bc0_1@dnews...
> Interesting example but I think java is still is working the specified way
> as the super class must be completely contructed before constructing the
> subclass so your field will get overwritten every time.
>
> I wouldn't really recommend this kind of initialization strategy and I
> suspect you are going for some kind custom module type scenario.
>
> More often that not it is better to use an interface as the basis of some
> module and have an adapter class (default implementation for simplicity
like
> MouseAdapter etc) that you extend from. This leaves you the option later
to
> not extend from the base class if necessary (this often happens when a
> program evolves and requirements change). An example if you like..
>
> // The basic skeletal definition of a module
> public interface MyModule
> {
>     public void init();
>     public void open();
>     public void close();
>     public void destroy();
> }
>
> // A convenient adapter class to extend to avoid rewriting every method
> public class MyModuleDefaultImpl implements MyModule
> {
>     public void init() { /* noop - override if req */ }
>     public void open() { /* noop - override if req */ }
>     public void close() { /* noop - override if req */ }
>     public void destroy() { /* noop - override if req */ }
> }
>
> // This
> public class MyModuleImplA extends MyModuleDefaultImpl
> {
>     public void init() { /* override to do something useful */ }
> }
>
> public class HostApp
> {
>     public static void main(String[] args)
>    {
>       try
>       {
>         // Use a dynamically loaded and instantiated module at runtime
>         // Notice we only ever refer to the interface not the actual
> implementation at runtime
>         MyModule m =
(MyModule)Class.forName("MyModuleImplA").newInstance();
>         m.init();
>         m.open(); // etc....
>       }
>       catch (Exception x)
>       {
>          x.printStackTrace();
>       }
>    }
> }
>
>
> Hanan Hermon <hananh@radcom.co.il> wrote in message
news:3be65516_2@dnews...
> > Hi,
> >
> > Below there are to small classes with a main method.
> > When I run it I expected the output to be "Init", but surprisingly it
was
> > "Def".
> >
> > I found out that when we set default values in the class descriptions it
> > is being set after we return from the ancestor constructor.
> >
> > I expected that the default values will be set before the constructor
> > starts.
> >
> > Is this a bug or that is the way it should work ?
> >
> > I'm using JBuilder 4 on Windows-NT.
> >
> > Here ate the classes descriptions:
> >
> > abstract class Base
> > {
> >   abstract public void init();
> >
> >   Base()
> >   {
> >     init();
> >   }
> > }
> >
> >
> > public class Sub extends Base
> > {
> >   private String mTemp = "Def";
> >
> >   public void init()
> >   {
> >     mTemp = "Init";
> >   }
> >
> >   static public void main(String[] args)
> >   {
> >     Sub   tmp = new Sub();
> >
> >     System.out.println(tmp.mTemp); // Expected output is "Init" ?!
> >
> >   }
> > }
> >
> >
>
>