small ideas to improve java

Ahmed Ahmed ah_mz_el2003 at yahoo.com
Thu Aug 11 21:05:20 UTC 2016


i have some small ideas to improve java i really don't know where is the appropriate place to share this ideas the oracle guild seems complicates to me with many to read and million of links that made me lost so i will post my ideas here hopping that some one knowing what to do adopts this ideas if beneficial

1) my first idea about the restriction that the call of super() must be the first statement in the child constructor, i think _ according to my understanding _ this can be lessened to the call of super must come before any other method invocation e.g looking for the following example 
 
class SuperClass {

 public SuperClass() {
 someMethod();//calling overridable method -> an error prone code
 }

 void someMethod() {
 //doing some thing
 }

}

class SubClass extends SuperClass {

 Object someVar;

 public SubClass(Object someVal) {
 super();//this what happen behind the scene
 this.someVar = someVal;
 }

 @Override
 void someMethod() {
 String s = someVar.toString();//referencing field variable 
 //doing some thing
 }

}
 
in the super class when we call an overridable method in the constructor we are risking our self as if the child class override this method and in its implementation it refer to its field "someVar" when the child is created the super class constructor will be invoked first "super()" this will invoke the overridden version of method "someMethod" and as the child have not been initialized this will to error at the line 
 String s = someVar.toString(); due to trying to deference a null pointer 

now back to my suggestion the above example can be written like this 

class SubClass extends SuperClass {

 Object someVar;

 public SubClass(Object someVal) {
 this.someVar = someVal;//according to new role this should be accepted
 this.someVar = doSomeThing(someVal);//this should be not accepted
 super();//call of super() can be done after child field initialization
 this.someVar = doSomeThing(someVal);//this should be accepted now
 }

 @Override
 void someMethod() {
 String s = someVar.toString();//referencing field variable 
 //doing some thing
 }

}

now with the new role its possible to call any overridable in the super constructor with out making any subclass suffer the consequences of overriding the super class method as now the child can initialize its field fairly easily before going and constructing the super class 

2)about creating array of generic type 
the argument as said in doc https://docs.oracle.com/javase/tutorial/java/generics/restrictions.html#createArrays

 "If you try the same thing with a generic list, there would be a problem:

Object[] stringLists = new List<String>[]; // compiler error, but pretend it's allowed
stringLists[0] = new ArrayList<String>(); // OK
stringLists[1] = new ArrayList<Integer>(); // An ArrayStoreException should be thrown,
 // but the runtime can't detect it.

"If arrays of parameterized lists were allowed, the previous code would fail to throw the desired ArrayStoreException."
 
also here https://docs.oracle.com/javase/tutorial/extra/generics/fineprint.html 

The component type of an array object may not be a type variable or a parameterized type, unless it is an (unbounded) wildcard type.You can declare array types whose element type is a type variable or a parameterized type, but not array objects.

This is annoying, to be sure. This restriction is necessary to avoid situations like:

// Not really allowed.
List<String>[] lsa = new List<String>[10];
Object o = lsa;
Object[] oa = (Object[]) o;
List<Integer> li = new ArrayList<Integer>();
li.add(new Integer(3));
// Unsound, but passes run time store check
oa[1] = li;

// Run-time error: ClassCastException.
String s = lsa[1].get(0);

If arrays of parameterized type were allowed, the previous example would compile without any unchecked warnings, and yet fail at run-time. We've had type-safety as a primary design goal of generics. In particular, the language is designed to guarantee that if your entire application has been compiled without unchecked warnings using javac -source 1.5, it is type safe."

according to the previous two quota the creation of arrays of parameterized type is prohibited to avoid problems but i really believe this was exaggeration and the real cause of problem is assigning parameterized to a non-parameterized type as in the second example `Object o = lsa;` the solution is to make compiler complain about this warning the user that this will abolish type checking for any following use of the parameterized type e.g at the line `String s = lsa[1].get(0);` the compiler should raise warning that lsa are no longer type save and unchecked warning should be raised hope those ideas will be useful 


More information about the adoption-discuss mailing list