#1000607
- Created on2011-09-16 08:41
- Reported by
- StatusFixed
- PriorityHigh (2)
- Assigned to
- Milestone
- Plan Level-
- Due Date-
Java incremental compiler seems not to be triggered when modifying Scala source
// A.scala
trait A {
def foo(s: String): Unit //= {}
}
abstract class B extends A
//C.java
public class C extends B {
}You will see that one error is reported because class `C` is missing the implementation of A.foo(String).
Now, go in trait `A` and remove the comments from `foo`'s declaration (so that the method will have an empty body).
The Java reconciler is triggered and the squiggling under type `B` is correctly removed. However, both the problem view and the editor still report the error: `C` is missing the implementation of A.foo(String).
By performing a full clean the error goes away.
The issue can be reproduced consistently with both builders (Refined Build Manager and SBT-based one).
Could it be that the Java incremental compiler is not triggered?
Mind that you need to use the latest IDE nighlty (i.e., build date >= 16/09/2011).
Leave a comment
on 2011-09-16 08:44 *
By Mirco Dotta
Description changed from
// A.scala
trai... to
// A.scala
trai...
on 2011-09-20 16:30 *
By Iulian Dragos
This happens with even the simplest example: Have two sources, one in Java and another in Scala. Have the Java source all a method defined in Scala, then rename that method and save the Scala source. The error won't be reported on the Java source, which is not recompiled.
on 2011-09-28 10:17 *
By Hubert Plociniczak
I am looking into it
on 2011-10-07 14:34 *
By Hubert Plociniczak
To me neither build manager nor presentation compiler report error for C about missing foo implementation (even on clean build). I don' t know why. So this seems like even more problematic.
on 2011-10-07 15:21 *
By Iulian Dragos
Hubert, that is the correct behavior. Class C (in Java) inherits the Scala class that gets the trait member implementations through mixin composition. The builder shouldn't show any error, and the presentation compiler has been fixed by Mirco's fantastic weaving skills. The problem is now that the builder does not kick in for java sources when the scala source is changed.
on 2011-10-07 15:45 *
By Hubert Plociniczak
Yes, if only it worked that way. I looked into how it works (and yes, I managed to realize that it relates to #1000594 and magic in weaving). And in the original case (when foo is abstract) it doesn't report errors! This is not correct. You know why? Debugger just told me that.....
our recent friend called "Selective dealiasing" strikes back.
In other words in ScalaMethodVerifierProvider in
val res = pairedParams forall { case (jdtTpe, scalacTpe) => jdtTpe == scalacTpe }
it figures out now that String != java.lang.String.
So I cannot even fix this bug, because I am hitting a new one. Not sure if we should generally refactor your normalizeCompletion method that you used for fixing tests or revert Paul's commit because I imagine we will hit more bugs like that later when people switch to 2.10.
our recent friend called "Selective dealiasing" strikes back.
In other words in ScalaMethodVerifierProvider in
val res = pairedParams forall { case (jdtTpe, scalacTpe) => jdtTpe == scalacTpe }
it figures out now that String != java.lang.String.
So I cannot even fix this bug, because I am hitting a new one. Not sure if we should generally refactor your normalizeCompletion method that you used for fixing tests or revert Paul's commit because I imagine we will hit more bugs like that later when people switch to 2.10.
on 2011-10-07 15:48 *
By Hubert Plociniczak
Btw I know it works for 2.9 but Paul's selective dealiasing hasn't been ported to it so you are not experiencing it for 2.9. But I am running this on 2.10.
on 2011-10-07 15:56 *
By Iulian Dragos
I see, that's annoying. That should be a different ticket, this one is a little bit simpler :)
on 2011-10-07 16:22 *
By Hubert Plociniczak
Yes, but without fixing it I cannot see the underlying problem in sbt. Anyway #1000652.
on 2011-10-07 17:55 *
By Iulian Dragos
THat's not correct. See my earlier comment:
This happens with even the simplest example: Have two sources, one in Java and another in Scala. Have the Java source all a method defined in Scala, then rename that method and save the Scala source. The error won't be reported on the Java source, which is not recompiled.
Feel free to open another ticket if this is too confusing :)
This happens with even the simplest example: Have two sources, one in Java and another in Scala. Have the Java source all a method defined in Scala, then rename that method and save the Scala source. The error won't be reported on the Java source, which is not recompiled.
Feel free to open another ticket if this is too confusing :)
on 2011-10-07 18:04 *
By Hubert Plociniczak
Yes I know, this is #1000388.
This one was fixed by our release of sbt 0.11.3. Test is now in ScalaJavaDep.scala
on 2011-11-10 14:18 *
By Mirco Dotta
This is still not fixed for me using the RC1...
on 2011-11-10 14:50 *
By Mirco Dotta
Assigned to changed from Hubert Plociniczak to login
Status changed from Fixed 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: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:9b8ed822d9dca851c969121cb33c3fbc81293d82) Added test for Re #1000607
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:8d277b7ede2136d713ff81067a7cfd539a777c4e) Added test for Re #1000607
(cherry picked from commit 9b8ed822d9dca851c969121cb33c3fbc81293d82)
Branch: release/scala-ide-2.0.0
(cherry picked from commit 9b8ed822d9dca851c969121cb33c3fbc81293d82)
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:02336198a3cc32f70699847b4c4f48210a432115) Added test for Re #1000607
(cherry picked from commit 9b8ed822d9dca851c969121cb33c3fbc81293d82)
Conflicts:
org.scala-ide.sdt.core.tests/src/scala/tools/eclipse/sbtbuilder/ScalaJavaDepTest.scala
Branch: master
(cherry picked from commit 9b8ed822d9dca851c969121cb33c3fbc81293d82)
Conflicts:
org.scala-ide.sdt.core.tests/src/scala/tools/eclipse/sbtbuilder/ScalaJavaDepTest.scala
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:02336198a3cc32f70699847b4c4f48210a432115) Added test for Re #1000607
(cherry picked from commit 9b8ed822d9dca851c969121cb33c3fbc81293d82)
Conflicts:
org.scala-ide.sdt.core.tests/src/scala/tools/eclipse/sbtbuilder/ScalaJavaDepTest.scala
Branch: issue/code-analysis-1000629
(cherry picked from commit 9b8ed822d9dca851c969121cb33c3fbc81293d82)
Conflicts:
org.scala-ide.sdt.core.tests/src/scala/tools/eclipse/sbtbuilder/ScalaJavaDepTest.scala
Branch: issue/code-analysis-1000629
on 2011-12-09 11:21 *
By Mirco Dotta
Assigned to changed from login to skyluc
Status changed from Accepted to Fixed
Fixed by Luc. Great!
(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:02336198a3cc32f70699847b4c4f48210a432115) Added test for Re #1000607
(cherry picked from commit 9b8ed822d9dca851c969121cb33c3fbc81293d82)
Conflicts:
org.scala-ide.sdt.core.tests/src/scala/tools/eclipse/sbtbuilder/ScalaJavaDepTest.scala
Branch: platform/indigo-3.7
(cherry picked from commit 9b8ed822d9dca851c969121cb33c3fbc81293d82)
Conflicts:
org.scala-ide.sdt.core.tests/src/scala/tools/eclipse/sbtbuilder/ScalaJavaDepTest.scala
Branch: platform/indigo-3.7
on 2013-01-18 12:45 *
By huitseeker
Version changed from 2.0.0-nightly-210 to 2.0.2-final-29
Eclipse version changed from Helios to Helios - Eclipse 3.6
Assigned to changed from skyluc to huitseeker