importing generic class

[FredericHeem]

My code is using a 2.5-SNAPSHOT of the original code, after upgrading to the 2.5 or your fork, the generated code differs when importing generics:

2.5-SNAPSHOT => OK import com.stateforge.statemachine.context.AbstractContext;

2.5 or UnquietCode/JCodeModel 2.7 => KO import com.stateforge.statemachine.context.AbstractContext<PingPingState, PingContext>;

Here is the interesting diff:

diff -ru CodeModel/codemodel/src/main/java/com/sun/codemodel/JFormatter.java ../../JCodeModel/codemodel/src/main/java/com/sun/codemodel/JFormatter.java
--- CodeModel/codemodel/src/main/java/com/sun/codemodel/JFormatter.java 2015-02-02 00:21:56.000000000 +0000
+++ ../../JCodeModel/codemodel/src/main/java/com/sun/codemodel/JFormatter.java  2015-03-23 23:30:23.000000000 +0000

@@ -442,12 +443,7 @@
                     clazz = clazz.erasure();
                 }

-                String fullName = clazz.fullName();
-                int indexOfLt = fullName.indexOf('<');
-                if(indexOfLt > 1){
-                   fullName = fullName.substring(0, indexOfLt);
-                }
-                p("import").p(fullName).p(';').nl();
+                p("import").p(clazz.fullName()).p(';').nl();
             }

Any opinion on that issue ? Would you accept a PR with the change and release a new version or should I continue using my local version ?

[UnquietCode]

Hi there. What is the impact to your generated code? If something is broken we should definitely try to fix it.

[FredericHeem]

The impact is simple: it doesn't compile, so it's a showstopper for my use case

[mattbishop]

Can you post the generator code? Better yet an isolated test class?

[UnquietCode]

Yes, as @mattbishop has stated it would be helpful if you had a brief code snippet or failing test generating code files which are unable to be compiled.

[FredericHeem]

Here is a link to the generator code:

• https://github.com/stateforge/StateBuilder/blob/master/Compiler/java/src/main/java/com/stateforge/statebuilder/java/CoderContext.java
• https://github.com/stateforge/StateBuilder/blob/master/Compiler/java/src/main/java/com/stateforge/statebuilder/java/CoderState.java

[mattbishop]

...and the lines in these files that are generating bad code? I don't know where to look in this code. The more information you can provide, the better for you.

[FredericHeem]

A pull request with the fix is available https://github.com/UnquietCode/JCodeModel/pull/6

[UnquietCode]

@FredericHeem Looking at the pull request it seems like there is some confusion about how generic classes are declared in the code model library. First, using direct class is generally bad because it breaks down internal tracking of classes. Second, you are including generics in the class name which is what is blowing up your compilation. The fix in your pull request is therefore not a fix, and breaks other parts of the library.

Try something like this instead:

JDefinedClass parentClass = codeModel._class("AbstractState");
JTypeVar tv1 = parentClass.generify("T1");
JTypeVar tv2 = parentClass.generify("T2");

JDefinedClass childClass = codeModel._class("Child")
    ._extends(parentClass.narrow(String.class, Integer.class))
;

[FredericHeem]

Thanks for the tips, it's almost there, the issue right now with this change is that a new class * AbstractState* is created although the class is provided by a library.

[UnquietCode]

Ah. In that case you can still use directClass to declare a class which is not directly part of the code model. Just add the generics afterwards using the narrow and generify methods as above.

[FredericHeem]

Excellent, it finally works fine, thanks for the tip, there is now no need for a PR.