Introduction:

A certain developer wanted to specify Generic Type in his abstract Java class, like the Java Map interface and AbstractMap class, in the manner described in Code Sample A, below.

Setup:

– We have 2 environments desktop and remote hosts
– Applications are built on the desktop in JDEV (11gR1) using OJC by default (or using Javac if specified)
– Applications are built on the remote-hosts also using JDEV (in Headless Mode), but somehow the builder does not pick OJC – it picks Javac
Looks like we are missing a tag "" in our Project’s .jpr file’s "oracle.jdeveloper.compiler.OjcConfiguration" element. Not having the tag somehow tells the local JDEV to use OJC but the Headless Remote one to use Javac.

Problem:

The developer(s) then changed their mind about genericising the SuperClass and did not use the template properly (They left the in the naming but did not use it anywhere in the class definition)… so what did this do?

– Java compiler did not complain until we were on the jdk1.6.0_11 version on the headless deploy environment, then when we upgraded to jdk1.6.0_13 – there were compile failures

– In the desktop environment we found that OJC did not complain at all. Remember OJC is just a jar, so upgrading the local jdk to 1.6.0_13 or 1.6.0_14 did not go much good (because we were not using javac, we were using java -jar ojc.jar …)

So the question is:

A. What changed in jdk1.6.0_13?
B. Why not in OJC?
C. Another weird phenomena which is easy to replicate is to assign Object[] to an Object as a key or value in a map.

For example:
In jdk1.6.0_11 this worked but fails in dk1.6.0_13. Also OJC tolerates this.
Map mMap= getStringObjectArrVal();
...
public Map getStringObjectArrVal()
{
....
}

C:\tmp>javac ObjToObjArr.java
ObjToObjArr.java:19: incompatible types
found   : java.util.Map<java.lang.String,java.lang.Object[]>
required: java.util.Map<java.lang.String,java.lang.Object>
Map<String, Object> mMap = getStringObjectArrVal();
^
1 error

Note: The following Still Works!
Object a = getObjectArray();
...
...
public Object[] getObjectArray()
{
...
....
}


Code Sample A:

public abstract class SuperClass<T>
{
protected T[] mChild;
abstract public T getChildAt(int index);
....
}

So instead of having a “String” array or “Integer” array or “MyDataType” array – this super class abstracts out the member variable’s type until a subclass is defined and implements the methods…

public class SubClassA
extends SuperClass<String>
{
public SubClassA()
{
super();
mChild = new String[]{};
}

public String getChildAt(int index)
{
….
…
…

and

public class SubClassB
extends SuperClass<Integer>
{
public SubClassA()
{
super();
mChild = new Integer[]{};
}

public Integer getChildAt(int index)
{
….
….
…

Note: I will be building up more on the above example to show some uses.