views:

217

answers:

2

There are classes:

InterfaceInterval<C extends Comparable<C>, I extends InterfaceInterval<C, I>> extends Comparable<InterfaceInterval<C, ?>>
AbstractInterval<C extends Comparable<C>, I extends AbstractInterval<C, I>> implements InterfaceInterval<C, I>, Serializable, Cloneable
AbstractTimeInterval<I extends AbstractTimeInterval<I>> extends AbstractInterval<Date, I>
SortedIntervalsList<C extends Comparable<C>, I extends AbstractInterval<C, ?>> extends ArrayList<I>
Timeline extends SortedIntervalsList<Date, AbstractTimeInterval<?>>

and now adding this line:

Timeline t = (Timeline) super.clone();

to clone() method in Timeline class I get:

mvn -e clean compile
The system is out of resources.
Consult the following stack trace for details.
java.lang.StackOverflowError
    at com.sun.tools.javac.code.Type$WildcardType.isSuperBound(Type.java:435)
    at com.sun.tools.javac.code.Types$1.visitWildcardType(Types.java:102)
    at com.sun.tools.javac.code.Types$1.visitWildcardType(Types.java:98)
    at com.sun.tools.javac.code.Type$WildcardType.accept(Type.java:416)
    at com.sun.tools.javac.code.Types$MapVisitor.visit(Types.java:3232)
    at com.sun.tools.javac.code.Types.upperBound(Types.java:95)
    at com.sun.tools.javac.code.Types.adaptRecursive(Types.java:2986)
    at com.sun.tools.javac.code.Types.adapt(Types.java:3016)
    at com.sun.tools.javac.code.Types.adaptRecursive(Types.java:2977)
    at com.sun.tools.javac.code.Types.adaptRecursive(Types.java:2986)
    at com.sun.tools.javac.code.Types.adapt(Types.java:3016)
    ...
    at org.apache.maven.plugin.AbstractCompilerMojo.execute(AbstractCompilerMojo.java:516)
    at org.apache.maven.plugin.CompilerMojo.execute(CompilerMojo.java:114)
    at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:451)
    at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:558)
    ... 16 more

BUT, when I comment that line:

//Timeline t = (Timeline) super.clone();

and:

mvn compile
...
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESSFUL
[INFO] ------------------------------------------------------------------------
...

then uncomment that line again:

Timeline t = (Timeline) super.clone();

and:

mvn compile
...
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESSFUL
[INFO] ------------------------------------------------------------------------
...

So it works fine with little help ;). On Eclipse it works also :/. What should I do? Is it a java compiler bug or something?

The full console log.

+2  A: 

It's almost never a good idea to assume a bug in the compiler or JVM. You'll resolve your issues a lot faster if you assume that the problem lies with you and your code - first, last, and always. By all means, do search the bug database or Google to see if anyone else has experienced your issue. (That's the first thing I do when I get an exception.) But you'll find that the JVM has been around longer and had more users exposing bugs than your code has, so the chances are greater that the problem lies in your code or a mistaken assumption about how things "should" work.

The problem is obvious: You've got a situation where clone of one class that calls another, which calls the first, which calls the other again, adding calls to the call stack until it overflows. Removing the call to super.clone() breaks the cycle.

Maybe a good place to start is: Why does your class Timeline override the clone method? What is it giving you that a decent copy constructor doesn't? Perhaps it's really a design issue.

duffymo
Err, I don't think so. If you look at the stack trace (especially the full log), you'll notice he's having this problem inside the compiler/maven while he's trying to compile and now while it's running. My ill-informed guess is his code trips some pathological case in the compiler and maven consumes enough resources that the compiler can't recover (hence why it "works" in eclipse). The fact that a second run works successfully would seem to support that guess.
Logan Capaldo
+1  A: 

I would aggree with duffymo - the compiler tries to resolve a cycle which just won't work until one or the other class got compiled already (this might cause the second time to succeed).

Taking a closer look, this one looks really bad (note all the Is):

AbstractTimeInterval<I extends AbstractTimeInterval<I>> extends AbstractInterval<Date, I>

Ok, I think I know what you tried there and why, but try to draw a inheritance-diagram for that one. I think you need to restructure that. Get rid of that class (you have to find another place for the methods in AbstractTimeInterval) and change

Timeline extends SortedIntervalsList<Date, AbstractTimeInterval<?>>

to

Timeline extends SortedIntervalsList<Date, AbstractInterval<Date,?>>
Marcel J.