Java compiler stupidity - Constructors

itemprop="text">

Why Java
compiler (javac) sometimes is stupid, sure i know that Java compiler is just a program,
but sometimes is designed as stupid (sometimes not), also i'm a fan of Java
:)

class Child extends Base
            {
 Child() {
 int i = 5; // any statement here.

            super(i);

 }
}

class
            Base{
 Base(int i) {

            }
}

here
compiler, claims that the first statements should be a call to the constructor of the
inherited class, but if we wrap this first statement inside a static method, it works
fine!!!!!!

class Child
            extends Base {
 Child() {
 super(foo()); // works
            fine!!!!
 }

 static int foo(){
 return
            5;

            }
}

This
works fine!!!!!!!, another killer example
:

 Child() {

            try{
 super(5);
 }catch(Exception e){}

            }

try catch
is language feature!!!

i know that the compiler
oblige us to call the super type constructor, because it should initialise the inherited
object before the self object (Generaly Java inheritence is released by object
chaining), but i think the compiler should be a little smart, it should let us
manipulate the code while we're not touching the object before calling its super
constructor, so that MUST work :

            Child() {
 int i = 5; // this MUST BE acceptable since we didn't
            touch
 // any current object or inherited field or we didn't
 //
            call any method on it.
 super(i);


            }

but this shouldn't
work :

class Child extends Base
            {
 private int i;
 Child() {
 i = 6; // this shouldn't
            work (its clear why).
 super();


            }
}

I just
wanted to understand why this is not implemented especially when i see Java can catch
unreachable code (a smart feature)???, so for more than 20 years, Java doesn't provide
such a BASIC feature, because usually this one sometimes makes code more ugly, sometimes
we have to make stupid static methods to avoid this, other time, we just call the super
constructor (for javac shut up) then we reinitialize the inherited
fields!!!!!!!!

Althought, i don't think, this is
a problem of the JVM and bytecode, i think this is can acheive only in javac
:)

I really love Java, but this one makes me so
angry, i forget to suggest this for the next release (Java 9), i hope it will be
included in Java 10, we wait 3 years more, better than not having it at all
:'(

Answer

I think this may be primarily
opinion based.

The way I see it, keeping things
simple is sometimes the smarter way to
design.

To have the compiler accept some code
that the compiler currently doesn't accept, that would (at a minimum) require
more complexity. The compiler would have the additional burden of
determining which constructs could be allowed, and which constructs wouldn't. The
compiler is plenty complex enough. Why add more unnecessary complexity. Especially if
the additional complexity doesn't solve, or help us solve, a particular
problem.

A requirement that the constructor in
the superclass runs before any code in the constructor of the subclass keeps things
simpler.

Declaring a static
method, as shown in an OP example, doesn't violate the rule about running the
constructor in the superclass. A static method is never instantiated. It's part of the
class definition, it's not part of an instance of a
class.

I think making the compiler
smarter (to handle Java code proposed by OP) would not be a smart
decision at all.

Q: What real
problem does the proposed change to the compiler solve?

Q: And what problems would it potentially
create?

Sometimes the choice to
avoid additional complexity (and potentially creating more
problems) is the smarter choice.