Community
Participate
Working Groups
It took me days after my last Eclipse update to get all our projects just compiling. Not because of wrong code or libs but because Eclipse got messed up with the projects in our working set. It jumped between misc projects - sometimes one project compiled fine ... just to mark another red. Compiling this one made the former red. It was so annoying but Eclipse finally sometimes was happy with everything. Without changing any line of code. Every now and then when starting Eclipse, it still shows some "errors" (which are not) that need to have caressing refresh / build / clean cycles to vanish. Now the next update to Eclipse 4.10: again misc projects showed red markers that some types/classes could be found. Learned from the months before I did dozens or refresh / build / clean of the projects several times. Most errors vanished but it is hard: The type java.util.Properties cannot be resolved. I played with the source, added an (unrequired) import statement (!) to get it compiled! Removed the import statement: still compiled. AFter next new start of Eclipse: the same error again ... ARGH! I have to refresh / build / clean the project 2 times to get the error vanished. So, Eclipse still have problems with compiling correct code - probably some internal asynchronous bugs, race conditions, whatever.
A lot is moving in the Java universe, including some rules about what is legal Java. To make this bug actionable we must have steps for reproducing, otherwise this will be a WORKSFORME.
I think it is clear from my description that this is a "random" bug that probably has something to to with race conditions / threads / order, etc. Unfortunately, I can't add our whole working set as an example. And it might not help as it "randomly" occurs. I hope that someone is checking the part of Eclipse that builds the open projects/working set to somehow find asynchronous problems that might occur.
(In reply to M H from comment #2) > I think it is clear from my description that this is a "random" bug that > probably has something to to with race conditions / threads / order, etc. > Unfortunately, I can't add our whole working set as an example. And it might > not help as it "randomly" occurs. I hope that someone is checking the part > of Eclipse that builds the open projects/working set to somehow find > asynchronous problems that might occur. Sorry, but that's too vague to start any kind of investigation. The compile error you showed could even be justified (in case your JRE configuration is broken). We don't necessarily need you full workspace, most problems can be reproduced also in a smaller example project. We don't even know which plugins are involved in building your project, just to begin with. If you are a software developer, you will know that you cannot fix a bug in your software if a client just tells you: "It has a concurrency bug!!". I will leave it in 'needinfo' mode for a little while before closing as WORKSFORME.
I understand the wish for a reproducable test case. We have absolutely plain Eclipse for Java developers. No plugin or any other changes. We use the current OpenJDK 11.0.1 for Eclipse and the projects (compiller compatibility Java 9 as we are on Java 9 on the production systems). I also understand that concurrency problems are hard to find. But this problem started from Java 9 on through Java 10 and now Java 11 and the last Eclipse versions. It's not our source code / projects because we can always compile the very same code with our separate ANT tasks (with same JDK). And the problem is "solved" somewhen if we just fiddle long enough with refresh / build / clean in arbitrary project orders (most projects depend on each other). But sometimes the very same error comes again. e.g. with the DOM API and the Node class: after upgrading to the former Eclipse 4.9 this stupid error occured again and it took again half an hour to get this "fixed" but doing dozens of misc refresh / build / clean cycles - with no obvious order. Again: not a single change of code and always compiling successful with our ANT tasks. This time with Eclipse 4.10 we got the first time the "unknown type java.util.Properties" bug that took again over an hour to refresh / build / clean to finally got Eclipse happy. Again: The ANT tasks worked right at the first time without any problem. And "java.util.Properties" is absolutely basic and since the beginning of Java. As this seems to be a concurrency bug in Eclipse and exists since several Eclipse versions, I want to file this bug that Eclipse developers know there is a problem. I understand that there is hardly any will to look into this with just describing text but the nature of this "random" bug that somewhen "suddenly" disappears is hard to grasp. We noticed that the last Eclipse versions always changed the format of the workspace. Perhaps this might be an indicator for this type of problem?
Same problem when dealing with OpenJDK11.0.1 and Eclipse 2018-12 (see also my original problem in https://bugs.eclipse.org/bugs/show_bug.cgi?id=543765). I'm currently also unable to provide an example because it only occurs in a bigger project with different dependencies. For our case, we have the effect that we have a .java file in project A and some maven and (jigsaw) modular dependencies, let's say A,B,C,D,E,F. Whenever I save my file, I got errors shown in the import declarations of A,B,C, then A, then D,E,F and so on. The .java file has a main(String[]) class. When I try to Run As, no dropdown occurs but the Error Log shows (maybe that helps): Unhandled event loop exception eclipse.buildId=4.10.0.I20181206-0815 java.version=11.0.1 java.vendor=Oracle Corporation BootLoader constants: OS=win32, ARCH=x86_64, WS=win32, NL=de_DE Framework arguments: -product org.eclipse.epp.package.jee.product Command-line arguments: -os win32 -ws win32 -arch x86_64 -product org.eclipse.epp.package.jee.product java.lang.NullPointerException at org.eclipse.jdt.internal.compiler.lookup.ModuleBinding.lambda$8(ModuleBinding.java:384) at java.base/java.util.stream.ReduceOps$4ReducingSink.accept(ReduceOps.java:220) at java.base/java.util.Spliterators$ArraySpliterator.forEachRemaining(Spliterators.java:948) at java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:484) at java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:474) at java.base/java.util.stream.ReduceOps$ReduceOp.evaluateSequential(ReduceOps.java:913) at java.base/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234) at java.base/java.util.stream.ReferencePipeline.collect(ReferencePipeline.java:589) at org.eclipse.jdt.internal.compiler.lookup.ModuleBinding.lambda$6(ModuleBinding.java:381) at org.eclipse.jdt.internal.compiler.lookup.ModuleBinding.getAllRequiredModules(ModuleBinding.java:402) …
Similar stacktrace as described in my previous comment for eclipse.buildId=4.11.0.I20190123-1800. Problem still unsolved.
I'm clutching to the only actionable detail I'm provided: the stack trace in comment 5. I interpret that stack as being caused by an indirectly required module that cannot be found at compile time (a required module binding was null). If that module is required transitively, then this is a buildpath problem that must be fixed, if it is required normally, then we can safely ignore that missing module. Actually, there's a tiny chance that "random" compile errors could be caused by this NPE.
I spoke too soon. Looking into the sources I could not find any code path that could possibly add null to the required modules. With this we're back at square one: no clue what could possibly trigger the various anomalies reported here. Putting the bug back on the pile, sorry. For further investigation we do need steps for reproducing.
Created attachment 277320 [details] Eclipse metadata log file .log file after Project > clean
Just attahced my current logfile after I did the following: 1. start computer ;-) 2. start Eclipse as always 3. did NOT start coding as always, but ... 4. refreshed the working set and .. 5. did a Project > clean on the working set - BOOM! Most projects turned red, the "Problems" view showed misc "build path incomplete" ... "cannot be resolved" .... "is indirectly referenced from" ... "cannot be built until its prerequisite is built" ... Had to do misc manuell refresh/clean/builds - sometimes it only worked after doing the same for the very same projects multiple times ... and just got stuck again in 1 project with "The type java.util.Properties cannot be resolved. It is indirectly referenced from required .class files" again ... The Attachement "Eclipse metadata log file" shows the log content after doing the above topics.
... couldn't clean the damn project until I switched off Project > Build automatically, then did a manuall "refresh" + "Project > Build Project" and switched "Build automatically" back again ... :-/
@Stephan Herrmann: The false-positive compiler errors described here seem to be similar to the ones in https://bugs.eclipse.org/bugs/show_bug.cgi?id=543765. Maybe its worth to take a look at the stack trace in its comment #1?
(In reply to M H from comment #9) > Created attachment 277320 [details] > Eclipse metadata log file > > .log file after Project > clean nothing relevant here. we need precise steps for reproducing
@M H: Possibly fixed in the newest (dev) version of Eclipse, see bug #544432 comment #9?
When is this released? Today, I lost over an hour again wothout solving this stupid, stupid, stupid bug! I didn't change anything about Java versions or compiler versions and "suddenly" I can't compile my projects anymore - Problems view:: ----------------------------- Description Resource Path Location Type The project was not built since its build path is incomplete. Cannot find the class file for java.util.Properties. Fix the build path then try building this project Description Resource Path Location Type The type java.util.Properties cannot be resolved. It is indirectly referenced from required .class files ----------------------------- Argh!!!!!! Again this brainless java.util.Properies bug! HEEEEEEEELP!!!
It somehow seems that this is a very old Eclipse bug - found something that helped: 10 years ago thread: http://dev-answers.blogspot.com/2009/06/eclipse-build-errors-javalangobject.html So, the problem probably has nothing to do with Java 11 but is perhaps triggered by changing JDK to another version. However, I got it back compiling by following the tips on this URL: I changed the projects System JRE (remove + add) and the Eclipse main JRE (change dto other an back) followed by cleaning projects. Then the errors vanished. Oh boy, this bug is so very annoying as it breaks development time with the IDE by spending so much time getting everything back compiling. :-(
See also: #67414
... to soon spoken ... after 10 minutes ... out of nowhere ... the same problems occured again. I officially hate Eclipse now. :-( Because I can't continue working with the IDE anymore because of this bug!
(In reply to M H from comment #15) > When is this released? Please try 4.11 RC2 build : https://download.eclipse.org/eclipse/downloads/drops4/S-4.11RC2-201903070500/ May be your problem is solved there. If not, please consider to provide a simple project to reproduce.
(In reply to M H from comment #16) > It somehow seems that this is a very old Eclipse bug - found something that > helped: 10 years ago thread: > > http://dev-answers.blogspot.com/2009/06/eclipse-build-errors-javalangobject. > html > > So, the problem probably has nothing to do with Java 11 but is perhaps > triggered by changing JDK to another version. Perhaps, it is, but perhaps Java 11 indeed triggers it. We simply don't know, and no-one in the JDT team can possibly make any investigations without a reproducing example. So, if this annoys you, please take the time, to reduce it in one of two possible ways: (1) Create a fresh workspace and a fresh project and start copying (first configuration, then a few Java classes) from the broken to the new project until you see the same problem. Relevant configuration could be in set of installed plugins, eclipse.ini, workspace preferences or project properties. (2) Delete files from the affected project until it is small enough to upload without disclosing proprietary code. If deleting particular files makes the error go away, revert that last step and continue with other files.
I fear creating a new workspace as it contains years of work and configurations. We have ".classpath" and ".project" checked into the source control, but it probably does not contain all my configurations. Another hint: i did a "Close Projects" on my working set. Then I reopened it again ... the red circles showed up again a few seconds but then vanished. It hold for 15 minutes now, so I hope this is a workaround to "fix" the really annoying compiler bugs.
(In reply to M H from comment #21) > I fear creating a new workspace as it contains years of work and > configurations. This implies the possibility that some configuration state has "eroded" over time, or put differently: the bug _could_ be impossible to reproduce in a clean workspace, or: nobody else might ever see this particular problem. > We have ".classpath" and ".project" checked into the source > control, but it probably does not contain all my configurations. If this is a big project, and in case there are several developers involved, I highly recommend taking a look at Oomph, which allows you to automate installing your desired flavour of Eclipse and configuring the workspace exactly to your needs & liking. Once a project has its setup defined with Oomph, reproducibility of workspace configuration is given, creating a new environment will be a matter of few clicks and a few minutes of waiting. If there are any co-workers: do they face the same problems? > Another hint: i did a "Close Projects" on my working set. Then I reopened it > again ... the red circles showed up again a few seconds but then vanished. > It hold for 15 minutes now, so I hope this is a workaround to "fix" the > really annoying compiler bugs. This kind of hint really doesn't help much, sorry. As long as you are the only person seeing the problem there's nothing we can do and the bug will eventually be closed WORKSFORME. If you want s.t. fixed, you need to help us helping you. The other path to follow: *please* install a 4.11 release candidate (2019-03), test if the problem still occurs and report back here.
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.
We've been running into this problem more frequently lately in our workspace. It almost always manifests in the form of "phantom" compiler errors that look like this: The type [X] cannot be resolved. It is indirectly referenced from required .class files Where [X] is always a built-in class from the JRE (java.util.stream.Collector and javax.swing.tree.TreeCellEditor are two recent examples). I realize that this is very difficult to track down, and unfortunately I don't have much concrete info, but here are some data points: - The errors always seem to come from projects that are building with Java 11 - Our workspace contains a mix of projects; some build using Java 1.8, others build using Java 11 - All projects are set to a compliance level of 1.8 (we can't move to compliance level 11 due to https://bugs.eclipse.org/bugs/show_bug.cgi?id=562122) - The problem almost always appears after a VCS operation (mercurial) modifies files in the workspace - The problem became much more frequent when we started using buildship (not sure if we ever actually saw this before switching to buildship or not) - The only consistent fix I've been able to find is closing *all* of the the projects in the workspace at once, and then re-opening them. Closing only the projects that are reporting the error or other subsets of projects never seems to help (is there perhaps some cache somewhere that gets cleared out only when all JDT projects are closed...?) - Developers that have "refresh using native hooks or polling" enabled in the workspace settings seem to encounter this more often
One question, just so we understand your situation: (In reply to Andy Lee from comment #24) > - The errors always seem to come from projects that are building with Java > 11 > - Our workspace contains a mix of projects; some build using Java 1.8, > others build using Java 11 > - All projects are set to a compliance level of 1.8 What do you mean by "build using Java 11" but configured for "compliance 1.8"? Do you have a JRE 11 on the build path? There's one particular risk in such configuration, because the file ct.sym (which is responsible for compiling for a different target than your current JRE) was silently changed between versions (thus this compatibility feature became the exact opposite: a compatibility killer). I don't recall at which exact versions the undocumented format of ct.sym stabilized, perhaps 12? This implies: it would be worth testing against other (newer) JREs, *or* a JRE exactly matching your compliance settings.
Yeah I think you have it right: The "Compiler compliance level" in the "Java Compiler" section is "1.8" In the "Java Build Path" section, under the "Libraries" tab, we have "JRE System Library [JavaSE-11]" I can try switching to a different JRE next time this occurs, although I think I've seen some reports that messing with JRE settings causes these errors to disappear regardless. Also, if it was really a ct.sym issue, I'd expect the problem to be more consistent rather than appearing seemingly at random.
