Community
Participate
Working Groups
I have an interface with the following method: List<String> retrieve(String arg1, UUID uuid1, UUID uuid1) The interface is annotated with @NonNullByDefault. The interface is implemented by two classes: one is located in (maven style) source folder src/main/java, and one is located in source folder src/test/java. Both classes are annotated with @NonNullByDefault. When compiling the entire project (through "Clean"), the implementing class in the src/main/java folder gives no errors, but the one in src/test/java gives the following error on the implementation of the method: "Illegal redefinition of parameter uuid1, inherited method from <interface> does not constrain this parameter". This error appears for both UUID parameters, but not for the String parameter. The error is incorrect, because the interface does constrain the parameter, because the interface is annotated with @NonNullByDefault. I've noticed the following: - The other implementation of the interface (in the src/main/java folder) does not give these errors - When I move the class to the src/main/java folder, the errors disappear. - The errors only appear for the java.util.UUID parameter, and not for the String parameter, or any other type I've tried. - The errors disappear when the class is compiled with the incremental compiler (make a small change in the source file, and save/compile it again). The errors appear again when the project is compiled as a whole. I've tried to isolate the problem in a separate project by copying the relevant classes, but I couldn't reproduce it, sadly enough. I'm afraid it is hard to reproduce.
Just to be sure: all your @NNBD are at the type level, no annotated package-info.java, right? (I'm asking because a package level annotation on a package split between two source folders might be a good recipe to create confusion ...). More questions: compliance is 1.7- or 1.8? Annotations v1.1.x or v2.0.0? Are classes also compiled to separated output folders (target/classes & target/testclasses)? That difference between UUID and all other types looks really weird. > I've tried to isolate the problem in a separate project by copying the > relevant classes, but I couldn't reproduce it, sadly enough. I'm afraid it is > hard to reproduce. Might be easier to reduce by copying the entire project, check if still reproducing and than deleting stuff piece-meal?
(In reply to Stephan Herrmann from comment #1) > Just to be sure: all your @NNBD are at the type level, no annotated > package-info.java, right? Correct > More questions: compliance is 1.7- or 1.8? Annotations v1.1.x or v2.0.0? 1.8 and v2.0.0 > > Are classes also compiled to separated output folders (target/classes & > target/testclasses)? Yes, separate output folders > Might be easier to reduce by copying the entire project, check if still > reproducing and than deleting stuff piece-meal? I'll give that a try.
I've made a copy of the project (the error is still present), and started deleting classes that are not related, followed by a clean of the entire project. Then something very strange happens, that has to do with the order of the classes/packages as they appear in the package explorer, which is simply alphabetically. If I delete a package or class that comes after (below) the class containing the error, the error remains. But if I delete a class or package before/above it, the error disappears! So if the class containing the error is a.b.Error, deleting a class in package a.a makes the error disappear, but deleting a class in package a.c does not! This means I can't come up with a project with only a few classes to reproduce it. I hope this is useful info to you. To me it's a mystery ;)
(In reply to Tom van den Berge from comment #3) > I've made a copy of the project (the error is still present), and started > deleting classes that are not related, followed by a clean of the entire > project. Then something very strange happens, that has to do with the order > of the classes/packages as they appear in the package explorer, which is > simply alphabetically. > > If I delete a package or class that comes after (below) the class containing > the error, the error remains. But if I delete a class or package > before/above it, the error disappears! > > So if the class containing the error is a.b.Error, deleting a class in > package a.a makes the error disappear, but deleting a class in package a.c > does not! > > This means I can't come up with a project with only a few classes to > reproduce it. I hope this is useful info to you. To me it's a mystery ;) Thanks a lot for your efforts. Yes, so far this sounds very mysterious, but once we have a project to debug against, chances are good we can resolve that mystery :) (In fact we had a few bugs relating to annotations that depend on order of events during compilation - this one seems to belong to the same bucket)
Is there a way to make progress on this bug? It keeps nagging me every day. The 'good' news is that it is not limited to the UUID class, as stated before. In fact, the classes containing the UUIDs that used to suffer from this bug are not showing the problem anymore. But I currently have 3 other classes in a single project that are suffering from it. The types that the compiler complains about are quite diverse, so it seems that it has nothing to do with the types themselves. Anytime the project is fully rebuilt, the compiler gives errors on these classes, which I then touch one by one in the editor to make the incremental compiler recompile them, which makes the errors disappear. Is there anything I can do to help solving this bug?
(In reply to Tom van den Berge from comment #5) > Is there anything I can do to help solving this bug? Provide a reproducing project :) I don't yet have a good clue on how to work on this, but I'm putting this on the radar, to be sure we don't forget it.
Sounds a bit like bug 485465
(In reply to Till Brychcy from comment #7) > Sounds a bit like bug 485465 Judging by the mystery factor? Maybe...
Too much on my plate for 4.6. Bulk deferral to 4.7
Ran out of time for 4.7. Bulk move to 4.8.
bulk move out of 4.8
.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
