#1000388
- Created on2011-05-01 15:34
- Reported by
- StatusAccepted
- PriorityHigh (2)
- Assigned to-
- Milestone
- Plan Level-
- Due Date-
Java code does not show errors when Scala code it depends on changes (and vice versa)
For example, let's say I have a Java project to which I've added the Scala nature. In it, I have a Java class:
and a Scala class:
It seems the changes in Scala sources do not trigger the Java builder, and the bytecode is out of sync. The presentation compiler correctly shows errors, but the build compiler is not taking action.
As you can see, they refer to each other, and therefore each should be revalidated if the other changes, but currently this doesn't happen. If I change the name of "foo" to something else it will not cause error markers to be placed on the Java code which calls it, unless I do a clean rebuild of the project. Likewise, changing the name of "bar" to something else won't cause an error marker to be placed on the Scala code which calls it. I can run the code without any indication that something is wrong until it gets to that block at runtime, and then I'll get a NoSuchMethodError.
public class J {
public static void main(String[] args) {
new S().foo("ahoy");
}
public String bar(String s) {
return s + s;
}
}and a Scala class:
class S {
def foo(s:String) { println(new J().bar(s)) }
}It seems the changes in Scala sources do not trigger the Java builder, and the bytecode is out of sync. The presentation compiler correctly shows errors, but the build compiler is not taking action.
As you can see, they refer to each other, and therefore each should be revalidated if the other changes, but currently this doesn't happen. If I change the name of "foo" to something else it will not cause error markers to be placed on the Java code which calls it, unless I do a clean rebuild of the project. Likewise, changing the name of "bar" to something else won't cause an error marker to be placed on the Scala code which calls it. I can run the code without any indication that something is wrong until it gets to that block at runtime, and then I'll get a NoSuchMethodError.
Leave a comment
I cannot reproduce this. If I change 'foo' (in the Scala file), and I change to the Java source, it correctly highlights the error (without building in between). The other way around, changing 'bar' (in the Java source) requires building (but not a clean build). Simply saving the file with Build Automatically should show the errors.
Have you enabled 'Report Problems as you type' in the Java/Editor configuration panel?
Have you enabled 'Report Problems as you type' in the Java/Editor configuration panel?
I do see that changing "foo" in the Scala source creates a transient error annotation in the Java editor, though sometimes this only happens on editor activation, so that when the editor area is split, showing both the Scala and Java files side-by-side, the Java editor doesn't revalidate until I click on it. But that's a minor issue.
The real problem is that no persistent error markers are made (nothing shows up in the problems view) even after I save the Scala file with the renamed method. And as I said, I can run the program even though it shouldn't be compiling, and it will throw a NoSuchMethodError once it gets to the problematic statement. Presumably this is because the Java builder is not running in response to the Scala class file(s) changing.
And the other way around just doesn't work at all for me. Changing the Java source neither creates transient nor persistent error markers in the Scala code, until I do a clean rebuild of the project.
I have both "Report problems as you type" and "Build Automatically" enabled.
I'm using the nightly build: 2.0.0.201105012326true-f3333d2 inside a freshly installed Eclipse Helios SR2.
The real problem is that no persistent error markers are made (nothing shows up in the problems view) even after I save the Scala file with the renamed method. And as I said, I can run the program even though it shouldn't be compiling, and it will throw a NoSuchMethodError once it gets to the problematic statement. Presumably this is because the Java builder is not running in response to the Scala class file(s) changing.
And the other way around just doesn't work at all for me. Changing the Java source neither creates transient nor persistent error markers in the Scala code, until I do a clean rebuild of the project.
I have both "Report problems as you type" and "Build Automatically" enabled.
I'm using the nightly build: 2.0.0.201105012326true-f3333d2 inside a freshly installed Eclipse Helios SR2.
Thanks for the clarifications!
As far as I can tell, the first paragraph describes how the JDT works on Java sources as well. An error introduced in an edited buffer does not add permanent makers, nor does it add any markers in the other buffers. Once you switch to a buffer, the reconciler kicks in and the error is shown. Nothing we can do there.
The rest describes a real issue, and I will update the ticket to reflect that.
As far as I can tell, the first paragraph describes how the JDT works on Java sources as well. An error introduced in an edited buffer does not add permanent makers, nor does it add any markers in the other buffers. Once you switch to a buffer, the reconciler kicks in and the error is shown. Nothing we can do there.
The rest describes a real issue, and I will update the ticket to reflect that.
on 2011-05-03 07:49 *
By Iulian Dragos
Description changed from For example, let's say I ha... to For example, let's say I ha...
on 2011-10-03 08:39 *
By Iulian Dragos
Type set to Defect
Version changed from 2.0.0-beta2 to 2.0.0-beta11-29
Eclipse version changed from Helios to Helios
on 2011-10-07 08:26 *
By Hubert Plociniczak
With two 2.10 presentation compiler complains that it cannot find J. Probably a different bug though.
on 2011-10-07 10:10 *
By Hubert Plociniczak
There seems be a bug related to this in sbt. If you define standard sbt project with those sources, compile, it is fine.
Now change foo to foo2. Compile, it detects dependency and reports error on Java source. But now if you change foo2 to foo and compile, it compiles only Java source (!) and complains that it cannot find foo symbol. I will report it for sbt.
The initial problem, of triggering Java source compilation still remains and is a bug in our builder.
Now change foo to foo2. Compile, it detects dependency and reports error on Java source. But now if you change foo2 to foo and compile, it compiles only Java source (!) and complains that it cannot find foo symbol. I will report it for sbt.
The initial problem, of triggering Java source compilation still remains and is a bug in our builder.
on 2011-10-09 05:05 *
By Hubert Plociniczak
There is something weird going on with sbt itself here.
If you try this example (or even simpler with mixed Java/Scala sources) on a clean project (no binaries, no cached dependency info etc) the result is as follows:
1) you compile correct files, everything is fine
2) you change foo to foo2 and compiler -> everything is fine according to sbt (it only compiles S.scala)
3) you run compile again (there is nothing new) and it figures out that it needs to compile java sources as well and gets an error.
everything works correctly if you work on a project that already has some stuff compiled etc so I am starting to think that we are just hitting some weird corner case of sbt.
If you try this example (or even simpler with mixed Java/Scala sources) on a clean project (no binaries, no cached dependency info etc) the result is as follows:
1) you compile correct files, everything is fine
2) you change foo to foo2 and compiler -> everything is fine according to sbt (it only compiles S.scala)
3) you run compile again (there is nothing new) and it figures out that it needs to compile java sources as well and gets an error.
everything works correctly if you work on a project that already has some stuff compiled etc so I am starting to think that we are just hitting some weird corner case of sbt.
on 2011-10-11 03:38 *
By Hubert Plociniczak
So, it was a bug in sbt (for reference https://github.com/harrah/xsbt/issues/220). I will update to the latest sbt and see if it helps. I think it should fix it.
on 2011-11-10 02:59 *
By Hubert Plociniczak
That looks exactly like the test I had to ignore for now:
https://github.com/scala-ide/scala-ide/blob/master/org.scala-ide.sdt.core.tests/src/scala/tools/eclipse/sbtbuilder/ScalaJavaDepTest.scala
Sbt seems to get it right now but Eclipse Java builder ignores it (even though sbt tells it to recompile). Iulian suggested that this might be a "refresh" issue in Eclipse.
https://github.com/scala-ide/scala-ide/blob/master/org.scala-ide.sdt.core.tests/src/scala/tools/eclipse/sbtbuilder/ScalaJavaDepTest.scala
Sbt seems to get it right now but Eclipse Java builder ignores it (even though sbt tells it to recompile). Iulian suggested that this might be a "refresh" issue in Eclipse.
on 2011-11-10 06:50 *
By Mirco Dotta
Assigned to changed from Hubert Plociniczak to login
Status changed from New to Accepted
Re-opened. Iulian is looking into it.
(In revision:0d02de6bbf45ec8067c9606cb76c49801f47362b) Re #1000388, Re #1000607. Set the call to the Eclipse Java compiler asynchronous so it can see the changes.
The way the incremental Eclipse Java compiler works, it doesn't see that because a .class has been changed it needs
to recompile some sources.
This change 'touches' the java files to recompile and call asynchronously the Eclipse Java compiler so it can see
the touched files in the delta.
Branch: issue/async-javac-from-sbt-builder-1000388
The way the incremental Eclipse Java compiler works, it doesn't see that because a .class has been changed it needs
to recompile some sources.
This change 'touches' the java files to recompile and call asynchronously the Eclipse Java compiler so it can see
the touched files in the delta.
Branch: issue/async-javac-from-sbt-builder-1000388
(In revision:f71ac73714894fed873aa7934970b3197ceef935) One step closer. Eclipse compiler to follow sbt requests.
Added code to update on the fly the delta used by the Eclipse Java compiler, so it compiles
the file requested by sbt.
It works fine for RE #1000607 on my system.
For RE #1000388, it is only part of the solution. It mostly works but sometimes sbt doesn't request the recompilation of the
dependent Java class.
Branch: issue/get-java-to-follow-sbt-1000388
Added code to update on the fly the delta used by the Eclipse Java compiler, so it compiles
the file requested by sbt.
It works fine for RE #1000607 on my system.
For RE #1000388, it is only part of the solution. It mostly works but sometimes sbt doesn't request the recompilation of the
dependent Java class.
Branch: issue/get-java-to-follow-sbt-1000388
(In revision:99160b04e3aae54088d973995cccbb4accaa4c38) Re #1000388. @Override rules are not the same in Java 1.5 and 1.6. Fixing it so it compiles fine in the command line.
Branch: issue/get-java-to-follow-sbt-1000388
Branch: issue/get-java-to-follow-sbt-1000388
on 2011-11-29 07:41 *
By frode.nerbraten
@skyluc did you see my comments regarding the ExpandableResourceDelta class?
https://github.com/scala-ide/scala-ide/commit/f71ac73714894fed873aa7934970b3197ceef935#comments
I tried to send the suggested change as a pull request here:
https://github.com/scala-ide/scala-ide/pull/49
I'm not sure if this is the right way to contribute, but I haven't gotten any response on this. The change (or something similar) is necessary if the fix for this ticket is to work on a multi-module project (like the one I'm working on). I understand that you have a lot to do, but any comment would be appreciated even just to say that I should stop pursuing this.
I also found that the java incremental compilation issue also applies when there is no scala sources involved. I managed to reduce it to a small, reproduce-able example here:
https://groups.google.com/forum/#!topic/scala-ide-user/WPhHfiMEcrI
https://github.com/scala-ide/scala-ide/commit/f71ac73714894fed873aa7934970b3197ceef935#comments
I tried to send the suggested change as a pull request here:
https://github.com/scala-ide/scala-ide/pull/49
I'm not sure if this is the right way to contribute, but I haven't gotten any response on this. The change (or something similar) is necessary if the fix for this ticket is to work on a multi-module project (like the one I'm working on). I understand that you have a lot to do, but any comment would be appreciated even just to say that I should stop pursuing this.
I also found that the java incremental compilation issue also applies when there is no scala sources involved. I managed to reduce it to a small, reproduce-able example here:
https://groups.google.com/forum/#!topic/scala-ide-user/WPhHfiMEcrI
(In revision:fbfffa2883238fcb2d3ff31d72b2c1ff75cbdc71) One step closer. Eclipse compiler to follow sbt requests.
Added code to update on the fly the delta used by the Eclipse Java compiler, so it compiles
the file requested by sbt.
It works fine for RE #1000607 on my system.
For RE #1000388, it is only part of the solution. It mostly works but sometimes sbt doesn't request the recompilation of the
dependent Java class.
Branch: issue/get-java-to-follow-sbt-1000388
Added code to update on the fly the delta used by the Eclipse Java compiler, so it compiles
the file requested by sbt.
It works fine for RE #1000607 on my system.
For RE #1000388, it is only part of the solution. It mostly works but sometimes sbt doesn't request the recompilation of the
dependent Java class.
Branch: issue/get-java-to-follow-sbt-1000388
(In revision:3d6f7d289cc62ab9bf93562fefd0b1ae0a2fcdf3) Re #1000388. @Override rules are not the same in Java 1.5 and 1.6. Fixing it so it compiles fine in the command line.
Branch: issue/get-java-to-follow-sbt-1000388
Branch: issue/get-java-to-follow-sbt-1000388
(In revision:3cbb568e77bbb36f6dd3d25330b0941eb5b10140) One step closer. Eclipse compiler to follow sbt requests.
Added code to update on the fly the delta used by the Eclipse Java compiler, so it compiles
the file requested by sbt.
It works fine for RE #1000607 on my system.
For RE #1000388, it is only part of the solution. It mostly works but sometimes sbt doesn't request the recompilation of the
dependent Java class.
(cherry picked from commit fbfffa2883238fcb2d3ff31d72b2c1ff75cbdc71)
Branch: release/scala-ide-2.0.0
Added code to update on the fly the delta used by the Eclipse Java compiler, so it compiles
the file requested by sbt.
It works fine for RE #1000607 on my system.
For RE #1000388, it is only part of the solution. It mostly works but sometimes sbt doesn't request the recompilation of the
dependent Java class.
(cherry picked from commit fbfffa2883238fcb2d3ff31d72b2c1ff75cbdc71)
Branch: release/scala-ide-2.0.0
(In revision:9030c029c8b605fa6dcfcba3395e74b0598d2557) Re #1000388. @Override rules are not the same in Java 1.5 and 1.6. Fixing it so it compiles fine in the command line.
(cherry picked from commit 3d6f7d289cc62ab9bf93562fefd0b1ae0a2fcdf3)
Branch: release/scala-ide-2.0.0
(cherry picked from commit 3d6f7d289cc62ab9bf93562fefd0b1ae0a2fcdf3)
Branch: release/scala-ide-2.0.0
(In revision:904bfa72b950958f9daba2c1ef7d886681a8bf8c) One step closer. Eclipse compiler to follow sbt requests.
Added code to update on the fly the delta used by the Eclipse Java compiler, so it compiles
the file requested by sbt.
It works fine for RE #1000607 on my system.
For RE #1000388, it is only part of the solution. It mostly works but sometimes sbt doesn't request the recompilation of the
dependent Java class.
(cherry picked from commit fbfffa2883238fcb2d3ff31d72b2c1ff75cbdc71)
Branch: master
Added code to update on the fly the delta used by the Eclipse Java compiler, so it compiles
the file requested by sbt.
It works fine for RE #1000607 on my system.
For RE #1000388, it is only part of the solution. It mostly works but sometimes sbt doesn't request the recompilation of the
dependent Java class.
(cherry picked from commit fbfffa2883238fcb2d3ff31d72b2c1ff75cbdc71)
Branch: master
(In revision:7a05f0a2fde8a8b4b81133efbe9b1c1ad27a435c) Re #1000388. @Override rules are not the same in Java 1.5 and 1.6. Fixing it so it compiles fine in the command line.
(cherry picked from commit 3d6f7d289cc62ab9bf93562fefd0b1ae0a2fcdf3)
Branch: master
(cherry picked from commit 3d6f7d289cc62ab9bf93562fefd0b1ae0a2fcdf3)
Branch: master
(In revision:904bfa72b950958f9daba2c1ef7d886681a8bf8c) One step closer. Eclipse compiler to follow sbt requests.
Added code to update on the fly the delta used by the Eclipse Java compiler, so it compiles
the file requested by sbt.
It works fine for RE #1000607 on my system.
For RE #1000388, it is only part of the solution. It mostly works but sometimes sbt doesn't request the recompilation of the
dependent Java class.
(cherry picked from commit fbfffa2883238fcb2d3ff31d72b2c1ff75cbdc71)
Branch: issue/code-analysis-1000629
Added code to update on the fly the delta used by the Eclipse Java compiler, so it compiles
the file requested by sbt.
It works fine for RE #1000607 on my system.
For RE #1000388, it is only part of the solution. It mostly works but sometimes sbt doesn't request the recompilation of the
dependent Java class.
(cherry picked from commit fbfffa2883238fcb2d3ff31d72b2c1ff75cbdc71)
Branch: issue/code-analysis-1000629
(In revision:7a05f0a2fde8a8b4b81133efbe9b1c1ad27a435c) Re #1000388. @Override rules are not the same in Java 1.5 and 1.6. Fixing it so it compiles fine in the command line.
(cherry picked from commit 3d6f7d289cc62ab9bf93562fefd0b1ae0a2fcdf3)
Branch: issue/code-analysis-1000629
(cherry picked from commit 3d6f7d289cc62ab9bf93562fefd0b1ae0a2fcdf3)
Branch: issue/code-analysis-1000629
(In revision:904bfa72b950958f9daba2c1ef7d886681a8bf8c) One step closer. Eclipse compiler to follow sbt requests.
Added code to update on the fly the delta used by the Eclipse Java compiler, so it compiles
the file requested by sbt.
It works fine for RE #1000607 on my system.
For RE #1000388, it is only part of the solution. It mostly works but sometimes sbt doesn't request the recompilation of the
dependent Java class.
(cherry picked from commit fbfffa2883238fcb2d3ff31d72b2c1ff75cbdc71)
Branch: platform/indigo-3.7
Added code to update on the fly the delta used by the Eclipse Java compiler, so it compiles
the file requested by sbt.
It works fine for RE #1000607 on my system.
For RE #1000388, it is only part of the solution. It mostly works but sometimes sbt doesn't request the recompilation of the
dependent Java class.
(cherry picked from commit fbfffa2883238fcb2d3ff31d72b2c1ff75cbdc71)
Branch: platform/indigo-3.7
(In revision:7a05f0a2fde8a8b4b81133efbe9b1c1ad27a435c) Re #1000388. @Override rules are not the same in Java 1.5 and 1.6. Fixing it so it compiles fine in the command line.
(cherry picked from commit 3d6f7d289cc62ab9bf93562fefd0b1ae0a2fcdf3)
Branch: platform/indigo-3.7
(cherry picked from commit 3d6f7d289cc62ab9bf93562fefd0b1ae0a2fcdf3)
Branch: platform/indigo-3.7
