Community
Participate
Working Groups
When you delete a source file in "new" language, the Java file that was compiled from it, if any, is not deleted along with it. This results in the accumulation of compiled Java files that have no corresponding files in the original source language. This doesn't actually break anything, and it isn't a problem for demo-scale use of SAFARI IDEs, so I've listed this bug as an "enhancement." But this situation could be quite annoying for real IDE users who are translating their languages into Java, so I've left the priority relatively high.
We don't really have any mechanism for tracking what files get generated by a given source file. We also have this problem with AST classes and the LPG generator. Perhaps we should add some API to SAFARI to help track this sort of thing. Client compilers would have to explicitly identify the files they generate.
I just noticed another aspect of this problem (that I should have anticipated). The SMAP builder runs on the existing Java files and generates ResourceException error messages when the original source files don't exist. Operationally this is not a problem, but it gunks up the console.
A very different take on the problem: Developers want to see precisely and only the artifacts they create in their folders. They don't want to have to wade through generated artifacts while browsing through their projects. So, arguably, generated artifacts (like Java source from LEG/X10 source) should not live alongside the original source from which they were generated. E.g., the JDT usually/optionally places class files in a separate folder from the Java source.
<gratuitous comment for change of status>
