Community
Participate
Working Groups
Build Identifier: I20110613-1736 I have a project where I need to have two different implementations for the same exact same class (i.e., same qualified name). The corresponding class files are generated in different output folders, and I have “run actions” that use either one or the other via a custom class-path. Example “.project” snippet: <classpath> <classpathentry kind="src" path="src/package/supersource"/ output="src/package/supersource" > <classpathentry kind="src" path="src" excluding="com/dragg/supersource/" /> <classpathentry kind="output" path="output" /> </classpath> Unfortunately, Eclipse insists on reporting the situation as an error: “The type <DuplicatedType> is already defined” (attached to the second one encountered in the classpath order). The only reference to the type name is a “ImplementedInterface instance = new DuplicatedType()” constructor call. IMO, this *particular* case is not an error; since the two classes have different output folder, nothing prevents Eclipse from actually compiling everything, and indeed, everything seems to work—both classes are checked for other errors and warnings—except that only the first one in classpath order is actually generated. I believe Eclipse should generate the two .class files (in their separate output folders) and at worst trigger a warning. Now, I understand why Eclipse would complain: it needs to check that call to the constructor I mentioned above, and it has two different alternatives, because it uses everything as the classpath when compiling. Given this particular project setup, the ideal behavior would be to try both, but I don’t think that’s tractable in the general case. But it would be nice if it were at least possible to specify in the .classpath file “when compiling this folder, exclude *this other* folder from the classpath”. (Explanation for the curious: I’m using GWT, which compiles Java to JavaScript. But some libraries are only available in JavaScript and some are only available in Java. I have quite a bit of code that needs to run the same both as pure Java and as JavaScript, which uses a (small) helper class with different Java implementations for the two cases. GWT allows you to declare a “super-source” folder, and the classes defined there are used to replace classes with the same name when compiling to JavaScript. I could probably work around this by splitting the “duplicate” classes into separate projects and playing a bit with exports, but it would be quite complex, and the class doesn’t make sense outside the project.) Reproducible: Always Steps to Reproduce: 1. Add two source folders to your project, with different output folders. 2. Define the same class (i.e., same qualified name) in both source folders. 3. Try to build your project.
Jay, can you please follow up? Thanks!
Interesting problem! I must admit we don't have the infrastructure to provide what you want. It's not just about compiling the files into the corresponding output folders. There are other situations where we would want to resolve a reference to the right class. I don't know if it would be alright for other components to know the classpath, exclusion pattern etc.
(In reply to comment #2) > Interesting problem! I must admit we don't have the infrastructure to provide > what you want. It's not just about compiling the files into the corresponding > output folders. There are other situations where we would want to resolve a > reference to the right class. I don't know if it would be alright for other > components to know the classpath, exclusion pattern etc. Satyam, what do you think?
Bug 224708 is in similar lines as this one.
A fundamental property of JDT projects is that there's exactly one classpath per project and hence a type can only be defined once per project. Changing that basic assumption would be a huge paradigm shift. At run time, you also have to decide which class is on the classpath. I don't think we should support scenarios at compile time that are not supported at run time. As you've already realized, you should set up separate projects for the different scenarios, maybe with linked source folders if you need to compile all scenarios in the same workspace.
agree with comment 4
I agree with the comments mentioned above, with one caveat. There is a case where a JDT project could have multiple source folders for different purposes and would normally (e.g. Gradle, Maven, Ant, etc...) generate separate JAR files that would then be assembled/deployed for different reasons. This implies that when the output folders are different, the contents should be considered separate and self-contained. I would expect that in most cases this scenario would be used like 'test code' flag, but not in all aspects. I would suggest that when there is a separate output folder, that the classpath within the project would follow a sequence of some sort (even random for a first attempt) where the "main" classpath is first and then the separate folders are added as if they were separate JARs. Obviously, it would be almost impossible to reference from Main->Separate(s) where there could be duplicates, but from Separate->Main would be reasonable and possible. I've only seen this case where there are different levels of testers (Unit, Integration, etc...) all testing the base code in different ways; but the option of having multiple implementations for different cases that the usage is controlled by the assembly also makes sense. It would be almost impossible to test the options completely via the GUI, but since it's a rare enough case it shouldn't matter that developers would have to handle the actual execution externally from the code generation/compile. Just a thought.
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.
