Community
Participate
Working Groups
I have a quite big workspace with several projects, some big, some small, all depend on some base projects. Compiling against Java 1.8 took a minute or so for the whole workspace. Now, after I switched to Java 9/10 and modularized some of the big base projects just a small code change may lead to a recompile, that takes several minutes. About half of the compiles even fails. Two of the projects (only one of them at a time) complain about missing/inaccessible packages. Doing a complete recompile MAY fix this, but does not always. This is really a showstopper. Is this known? Can I help with more info? Debug log?
(In reply to Marvin Fröhlich from comment #0) > Compiling against Java 1.8 took a minute or so for the whole workspace. Now, > after I switched to Java 9/10 and modularized some of the big base projects > just a small code change may lead to a recompile, that takes several > minutes. About half of the compiles even fails. When you say fails, did you mean the error below? > Two of the projects (only > one of them at a time) complain about missing/inaccessible packages. Doing a > complete recompile MAY fix this, but does not always. > Are you saying even a clean+build is not consistent? What kind of dependency do you have between projects (both modular and non-modular)? Any transitive dependencies involved?
(In reply to Jay Arthanareeswaran from comment #1) > When you say fails, did you mean the error below? Yes. > Are you saying even a clean+build is not consistent? Yes. While one clean+compile may make everything good, another could make one of these two projects good and the other one complaining about inaccessible or missing classes and vice versa. > What kind of dependency do you have between projects (both modular and > non-modular)? Any transitive dependencies involved? Both and yes. Some of the minor satellite projects would even need kind of bilateral requires, meaning: module a is base module b requires transitive a (optional) module b.2 requires transitive a module c requires a and b (optional) module c requires b.2 I cannot do this, because module c complains, that some packages are imported from both a and a, which is bullshit. Hence I have to live with some warnings in b about classes, that might not be accessible due to missing transitive. Well, this is a different problem, but it might be important here.
(In reply to Marvin Fröhlich from comment #2) > Some of the minor satellite projects would even need kind of bilateral > requires, meaning: If by bilateral you mean cyclic then this is of course illegal per JPMS. > module a is base > module b requires transitive a > (optional) module b.2 requires transitive a > module c requires a and b > (optional) module c requires b.2 > > I cannot do this, because module c complains, You list two modules of name "c", I assume you mean the former? > that some packages are > imported from both a and a, which is bullshit. hard to tell without a concrete example, but if a module requires b there is no need to also require a, which already comes for free as a transitive dependency. And: what in this picture do you call "bilateral"? > Hence I have to live with > some warnings in b about classes, that might not be accessible due to > missing transitive. missing transitive where? > Well, this is a different problem, but it might be important here. Well, if somehow you found a way to define a circular module graph, then strange compilation behavior could easily be the result of it. A reproducing example would really help a lot.
(In reply to Stephan Herrmann from comment #3) > If by bilateral you mean cyclic then this is of course illegal per JPMS. Yes, sorry. Cyclic is the better word. I understand, that cyclic projects are illegal by JPMS. Though is always was and still is legal in eclipse itself. Shouldn't this be forbidden (at least for modularized) Java 9+ projects? I have to admit, that I wasn't talking about cyclic project dependencies, but more about diamond relationships. Yes, my previous example was not 100% correct. But before I correct it, I will give you a simpler example. module a is base module b.x requires transitive a module b.y requires transitive a module c requires b.x module c requires b.y This is a very common case in our project landscape. Is this kind of diamond relationship legal by JPMS? > hard to tell without a concrete example, but if a module requires b there is > no need to also require a, which already comes for free as a transitive > dependency. Well, in our concrete project list we can handle this. But what, if I don't have this under my control? Let's imagine in the above example modules b.x and b.y are authored by someone else and he decides to require transitive module d, which I also need for my module c. Hence I require d in c. After I updated my copy of b.x or b.y I would have to remove the require for d in my module c. Isn't this a bit inconvenient, given, that the JVM could solve this duplication for me? > > Hence I have to live with > > some warnings in b about classes, that might not be accessible due to > > missing transitive. > > missing transitive where? Missing in b (original example). But I could solve this issue by removing the require, that I called bilateral, accepting the inconvenience described above. > Well, if somehow you found a way to define a circular module graph, then > strange compilation behavior could easily be the result of it. I solved all of the cycles except what I pictured in the above example about the diamond dependency. The behavior is consistent now. Unfortunately this means, it consistently doesn't compile seemingly fully valid code. Can I provide you with debug output? I cannot post my code. And the compile is still terribly slow even with stripped dependencies.
OK, I found another bug in my module configuration. It fixed the final compilation fails. Strangely the reported phantom bugs had nothing to do with the actual misconfiguration. Looks like the compiler is now able to consistently compile the complete workspace. It is still terribly slow (showstopping) and it seems to be prone to very strange behavior / "independent" compilation fails, if the module configuration is not perfect. Maybe that's something, that can be improved? The compiler must detect misconfigurations faster. It has to report in details, what's actually wrong. And it should not report "false negatives" when compiling misconfigured modules. This is not meant to sound cocky. Sorry, if it does. Please understand it as suggestions to improve this wonderful IDE, that accompanied myself for so many years.
Is there a way to find out, what class or even what part or a class takes a long time to compile? I can tell, what package is taking longer than it did with 1.8. But I would like to know, where exactly to try out changes.
This really is a showstopper. Eclipse freezes when I change a thing in a class (and Eclipse starts to compile and freeze), Eclipse freezes when I put something into the clipboard. And sometimes it even crashes to desktop. Yes, it seems to be something related to our code. At home with my personal code it works just fine. But it is no exotic code, that we have here. Isn't there a debug switch, that I could turn on to give you some debug output to help me find out, what's going on here? Currently our company can't move to Java 9/10 because of this.
(In reply to Marvin Fröhlich from comment #7) > This really is a showstopper. Eclipse freezes when I change a thing in a > class (and Eclipse starts to compile and freeze), Eclipse freezes when I put > something into the clipboard. And sometimes it even crashes to desktop. This (clipboard / crash) sounds not related to the compilation issue, but who knows. If it crashes, you should be able to find hs_error_pid* files left by the crashed JVM. Please attach them here. You have not provided details about your config- could you? OS, JVM, Eclipse versions please. > Isn't there a debug switch, that I could turn on to give you some debug > output to help me find out, what's going on here? Currently our company > can't move to Java 9/10 because of this. While Eclipse freezes next time, create few jstack thread dumps and attach them here - for *both* cases: clipboard freeze and compile freeze.
(In reply to Marvin Fröhlich from comment #7) > Isn't there a debug switch, that I could turn on to give you some debug > output to help me find out, what's going on here? Currently our company > can't move to Java 9/10 because of this. You can try "Preferences > General > Tracing" (Note: I think you need an eclipse with PDE to see that). I currently don't have time to check what you need exactly, but I guess: - master switch for JDT Core: org.eclipse.jdt.core/debug=true - plus some specific switches, probably org.eclipse.jdt.core/debug/compiler=true I'm not sure, but I think jdt.core always logs to stdout/stderr, not sure if that gets redirected to a trace file if you try to select that in the ui.
Thanks for your replies, guys. (In reply to Andrey Loskutov from comment #8) > This (clipboard / crash) sounds not related to the compilation issue, but > who knows. If it crashes, you should be able to find hs_error_pid* files > left by the crashed JVM. Please attach them here. Yes, I will do that. Though, after I further cleaned up the build path it hasn't crashed again, yet. (In reply to Andrey Loskutov from comment #8) > You have not provided details about your config- could you? OS, JVM, Eclipse > versions please. Sure. Here it comes. I'm on OpenSuSE Linux 42.3 (64 bit). I am using jre-1.8.0-openjdk (coming with SuSE) to run eclipse. The active "installed JRE" in eclipse to compile against is JRE-10.0.2, coming from Oracle. My Eclipse release is Photon 4.8.0 (Build id: 20180619-1200). I am using Eclipse for Java developers with optimized plugins. (No Mylyn, plus some plugin dev and web dev plugins, plus Subclipse) (In reply to Andrey Loskutov from comment #8) > While Eclipse freezes next time, create few jstack thread dumps and attach > them here - for *both* cases: clipboard freeze and compile freeze. Ok, I will do so. But I have some new findings, that might make this obsolete. More about that in the next comment. (In reply to Till Brychcy from comment #9) > You can try "Preferences > General > Tracing" (Note: I think you need an > eclipse with PDE to see that). I currently don't have time to check what you > need exactly, but I guess: Yes, this option is available here. Will check that out. (In reply to Till Brychcy from comment #9) > - master switch for JDT Core: > org.eclipse.jdt.core/debug=true > > - plus some specific switches, probably > org.eclipse.jdt.core/debug/compiler=true Where do I put that? I created a .options file in the eclipse install root folder and placed these two lines in there. Doesn't seem to have any effect.
Ok guys, I have some new findings. I have a mini workspace here with only a few projects, all are modules. a (big base library) b.x (small library) requires (transitive) a, compiled and packed to a jar c (big framework) requires a (as project) and b.x (as jar) Compiling this takes about 26 seconds. Now, if I reduce c to only require b.x, which brings a for free, it still takes 26 seconds. If I strip the requirement for a from b.x and let c require a and b.x, it compiles in about 22 seconds (reproducibly). So, it looks like the compiler has huge problems with custom module graphs. And the bigger the imported projects, the longer it takes. The imported module b.x is not even effectively used in c (just module-imported). Please note, that at the end of the day it is not an option to require a through b.x only, because there are other b.y and b.z modules, that need a. It is not a problem to produce these kinds of diamonds with Java internal modules like java.desktop etc. So this must have something to do with custom modules. Here is the module-info of b.x module infolog.treegraph { requires transitive infolog.commons; // This is "a" from above. exports com.infolog.treegraph; exports com.infolog.treegraph.impl; exports com.infolog.treegraph.util; } The project TreeGraph has project "INFOLOG Commons" (module infolog.commons) on the module path and exports it. Am I doing something very wrong? Should this custom module diamond be valid? On a side note: Shouldn't for a Java 9+ module project the project's build path be just a list of jars and not decide about classpath or module path? The module path should be configured through module-info only. the current build path is kind of redundant. All jars and projects, that are on the build path, but not required in module-info, would automatically be on the classpath. Would that be worth another feature request ticket?
(In reply to Marvin Fröhlich from comment #11) > On a side note: Shouldn't for a Java 9+ module project the project's build > path be just a list of jars and not decide about classpath or module path? > The module path should be configured through module-info only. the current > build path is kind of redundant. All jars and projects, that are on the > build path, but not required in module-info, would automatically be on the > classpath. Would that be worth another feature request ticket? At first I thought you forgot about automatic modules, but on re-reading I understand that you want the current project's module-info to decide which deps are modules (those required in module-info) or not. Is that your idea? Note that our Build Path UI roughly models those options specified in JEP 261. While I'm all in favor of improving usability, I'm afraid if we do too much magic behind the scenes some ppl will be quite confused. After all those design efforts that have gone into the current solution, I feel there is at least one show-stopper prohibiting your proposal, just I can't exactly think of it at this time of the day :) Your comment actually challenges why JEP 261 needed to introduce the classpath/modulepath distinction in the first place ;p -- unlikely that they did it without a good reason.
(In reply to Stephan Herrmann from comment #12) > At first I thought you forgot about automatic modules, but on re-reading I > understand that you want the current project's module-info to decide which > deps are modules (those required in module-info) or not. Is that your idea? Exactly. (In reply to Stephan Herrmann from comment #12) > While I'm all in favor of improving usability, I'm afraid if we do too > much magic behind the scenes some ppl will be quite confused. I understand that. It really shouldn't be confusing. For me it looks confusing, if I have to do the exact same thing two times: once in project build path and once in module-info. The only difference is the path of the jars. It looks like I might have misunderstood something, because the UI got indeed updated, but still looks like the existence of (in that sense) redundant module-info hasn't been thought of. It shouldn't be too confusing,if the project build path is not titled as build path, but something like library pool with a big label, that all libs (and projects) from the pool are put on the classpath, if not explicitly required in module-info and hence put on the modulepath. > After all those design efforts that have gone into the current solution, I > feel there is at least one show-stopper prohibiting your proposal, just I > can't exactly think of it at this time of the day :) Can't wait to hear it. Well, I think, this goes a little off topic. If we really want to discuss this further, we might have to move it to a separate ticket. What do you think? Any thoughts about the initial issue, that I compressed quite clearly in the previous comment?
I have the exact same problems (slow compilation, and errors everywhere). About the errors: > About half of the compiles even fails. Two of the projects (only > one of them at a time) complain about missing/inaccessible packages. Doing a > complete recompile MAY fix this, but does not always. I opened a specific ticket with a test model: https://bugs.eclipse.org/bugs/show_bug.cgi?id=539458
Great so see, that I'm not alone with this. Do you need more info about this to solve this very high priority issue?
(In reply to Marvin Fröhlich from comment #15) > Great so see, that I'm not alone with this. > > Do you need more info about this to solve this very high priority issue? A (as minimal as possible) example workspace would certainly help. Actually I have no idea how anybody can work on this without it.
A new try to provide you some example workspace: https://bugs.eclipse.org/bugs/show_bug.cgi?id=540293
Marvin, can you please try latest 4.10 nightly SDK build, may be we had some fixes which may be relevant for your issue? Beside this, if Eclipse is slow and freeze, jstack dumps will be of a great help to identify the code in question.
As requested, I added some jstack dumps in the bug 540293
Could affected parties please pick up a recent I-build (>= I20181019-1800)? Hopefully build times have been brought back to normal after the fix in bug 537934. Once the dust around long builds settles, we should get a better picture about any remaining bugs.
(In reply to Stephan Herrmann from comment #20) > Could affected parties please pick up a recent I-build (>= I20181019-1800)? Better still: the next I-build >= I20181020 ... the fix in bug 537934 was not complete.
If this bug really is a blocker for someone, then I'd really appreciate re-testing after recent fixes (most recently: bug 540788). BTW, what problem are we actually tracking under the heading "Compiler broken"??
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.
