Community
Participate
Working Groups
Created attachment 275054 [details] Test case to reproduce the issue I’ve run into a problem submitting compilation tasks using compilation units that do not store classes on the filesystem. Everything works fine, except for some validation on lines 141 and 142 of EclipseCompilerImpl where the code checks to make sure that the each compilation unit corresponds to a valid file on the file system. Beyond this validation, it doesn’t seem like the file is actually used. The contents of the compilation unit are fetched using the JavaFileObject.getCharContent method. Steps To Reproduce: Please see the attached junit test that reproduces the issue Expected Results: Compilation is successful Actual Results: Compilation fails and this error is reported: "File TestClass is missing" where TestClass is the name of the class I am attempting to compile. I can reproduce this issue using the latest version of the code in git I’m willing submit a patch to fix this issue.
I want to add a "me too" to this. NetRexx packages the ecj compiler, and uses it as the default. When running into a compilation problem with minor classes, I thought of falling forward to the most recent version. Both 4.7.3a and 4.8 do not work, and also an example of how to do this, downloaded from https://blog.nobel-joergensen.com/2008/07/16/using-eclipse-compiler-to-create-dynamic-java-objects-2/ does not work. I would love to see that fixed, because including ecj in NetRexx means we can compile on platforms that only have a JRE installed. I would also vote to include a testcase for this so it is not regressed. Does anybody know in which level this still was working?
(In reply to Max Almanzor from comment #0) > Created attachment 275054 [details] > Test case to reproduce the issue > > I’ve run into a problem submitting compilation tasks using compilation units > that do not store classes on the filesystem. Everything works fine, except > for some validation on lines 141 and 142 of EclipseCompilerImpl where the > code checks to make sure that the each compilation unit corresponds to a > valid file on the file system. Beyond this validation, it doesn’t seem like > the file is actually used. The contents of the compilation unit are fetched > using the JavaFileObject.getCharContent method. This was added via http://git.eclipse.org/c/jdt/eclipse.jdt.core.git/diff/org.eclipse.jdt.compiler.tool/src/org/eclipse/jdt/internal/compiler/tool/EclipseCompilerImpl.java?id=c798229d351d6daa2232cff6c15750336659223e on behalf of bug 477291 @Jay, do you remember, why you saw a need to check file existence? > I’m willing submit a patch to fix this issue. That would be great, in particular if the fix includes a couple of tests :) If you do so, please sign the ECA [1] so we will be able to use your fix. [1] http://wiki.eclipse.org/ECA (In reply to René Jansen from comment #1) > [...] Does anybody know in which level this still was working? Since the fixes in bug 477291 were first released in 4.7.1a, things should still be the old way in 4.7.0 and also in 4.7.1.
(In reply to Stephan Herrmann from comment #2) > @Jay, do you remember, why you saw a need to check file existence? This method overrides Main#getCompilationUnits() and looks like I translated this method for the compiler API. Need to dig deeper if this particular interface needs that check or not.
New Gerrit change created: https://git.eclipse.org/r/126498
(In reply to Stephan Herrmann from comment #2) > (In reply to Max Almanzor from comment #0) > > I’m willing submit a patch to fix this issue. > > That would be great, in particular if the fix includes a couple of tests :) > > If you do so, please sign the ECA [1] so we will be able to use your fix. > [1] http://wiki.eclipse.org/ECA > > I've uploaded a patch here: https://git.eclipse.org/r/#/c/126498/
New Gerrit change created: https://git.eclipse.org/r/126797
Is there anything that this issue is waiting on? Or any way that we could help with testing and/or integration of this patch? We have recently upgraded ecj, and run into exactly this problem.
Diffusion of responsibility? Jay, despite me being marked as a reviewer in gerrit, I'd appreciate if you take over along the lines of comment 3. OK?
(In reply to Stephan Herrmann from comment #8) > Diffusion of responsibility? > > Jay, despite me being marked as a reviewer in gerrit, I'd appreciate if you > take over along the lines of comment 3. OK? Sure
Max, sorry couldn't get to review the patch sooner since was busy with Java 13 work. One question: The second patch contains lot of changes that are already in master. Can you please remove them and post just the changes that are relevant here? Or should I take the first patch?
Bulk Move to 4.14
Bulk move out of 4.14
I know that this issue has been running for a while, but this is really a killer issue for us with using the the eco compiler. For many use cases we can use the Sun compiler, however there are some important use cases for us where having the eco compiler and being run with a JRE would be very convenient. At the moment, our classes are small, and the sources for them are held in memory, as we don't always have a directory that fully control. To that end, being able to compile using in memory files, provided via JavaFileObject, would be very beneficial. Is there anything that we can do to help, please let me know.
(In reply to Paul Wagland from comment #13) > I know that this issue has been running for a while, but this is really a > killer issue for us with using the the eco compiler. For many use cases we > can use the Sun compiler, however there are some important use cases for us > where having the eco compiler and being run with a JRE would be very > convenient. At the moment, our classes are small, and the sources for them > are held in memory, as we don't always have a directory that fully control. > To that end, being able to compile using in memory files, provided via > JavaFileObject, would be very beneficial. > > Is there anything that we can do to help, please let me know. I've been watching only from the side lines, but I understand: - we have a proposed change - that change has gone stale, some changes are already in master - the author has not signed ECA as requested in comment 2 - Jay had asked the author to update the patch, but no answer yet At this point we cannot use the change, but if you can convince Max Almanzor to at least sign ECA, then we could discuss how to share the load of updating & testing the proposed change.
There's nothing much we can do despite having a fix. Moving out.
Really? NetRexx has run with 4.6.3 for about two years now. Now we had to make changes for Java 9 and later, and it turns out that ecj 4.6.3 mistakes higher JDK's for those below 1.6. I upgraded ecj to current - it did not work, exactly because of this error. Also, it now first abends when there is no DiagnosticListener attached. So I attached one, and the first thing I saw was File /hello.java not found. We generate Java source in-core. We do not have a file. Also, we are not interested in diagnostic messages, so we null this out. The generated Java is OK, or else NetRexx would have caught the error. You had a fix, you let it go stale, there was no 'signed' something or other. "There's nothing much we can do despite having a fix. Moving out" There actually is. You could fix your original error. I would appreciate it very much if this was finally fixed. Otherwise I have to go start writing out files to dasd specially for ecj, or hunting for another compiler.
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.
