Community
Participate
Working Groups
(In reply to Dani Megert from bug 525713 comment #9) > (In reply to Stephan Herrmann from comment #8) > > So perhaps the UI should say: > > > > "An automatic module with an unstable name is required: [E/W/I/I]" > > > > ? > > I'd be fine with that. I'm also fine doing this in 4.9 as long as we have a > bug report that covers the UI work.
*** Bug 537052 has been marked as a duplicate of this bug. ***
New Gerrit change created: https://git.eclipse.org/r/126724
(In reply to Eclipse Genie from comment #2) > New Gerrit change created: https://git.eclipse.org/r/126724 Implements the request, we even have a mnemonic (which not all options have). Duplicate bug 537052 discussed: > There should be an option to reduce this "problem" to an info. And this > should be default. It really is not worth a warning. What will happen, if > the jar name changes? The whole project will not compile, since the module > path doesn't find the module. After fixing that, the automatic module name > won't match and an error will be generated. But before all that, meaning > before I manually change something, nothing will fail. So, this shouldn't be > warned. Some answers: javac, too, has this warning. Things get increasingly dangerous when there is a distance between building a project and running it. Consider: you build your stuff against foo.jar and publish your artifacts. A user / adopter consumes both your stuff and foo.jar. Later the author of foo.jar decides the official module name should be org.foo. Not only your build will be broken, but more drastically: the adopter's build as well, an he doesn't have a good chance to fix the problem. Things get even worse, when foo.jar was a file name invented by yourself or some 3rd party where you obtained the jar from. Your adopters may not even know about that file name, but only find apache-foo.jar on the net. Since we can't blame the author of pre-java9 foo.jar, it's the consumer who pulls that pre-java9 jar into a modular build, who creates a risk for his/her adopters. If you are developing a standalone application the risk is lower than discussed above. It's for that exact use case that you may deliberately reduce the severity - once you're aware of the risk and confirm that you won't spread the risk to others.
Gerrit change https://git.eclipse.org/r/126724 was merged to [master]. Commit: http://git.eclipse.org/c/jdt/eclipse.jdt.ui.git/commit/?id=93952051228c7e9ec3f9cd0cd6a9a0fa80ae954e
(In reply to Eclipse Genie from comment #4) > Gerrit change https://git.eclipse.org/r/126724 was merged to [master]. > Commit: > http://git.eclipse.org/c/jdt/eclipse.jdt.ui.git/commit/ > ?id=93952051228c7e9ec3f9cd0cd6a9a0fa80ae954e Released for 4.9 M2
(In reply to Stephan Herrmann from comment #3) > Things get increasingly dangerous when there is a distance between building > a project and running it. I do understand that point. The eclipse compiler and the javac should go too far off. Though Eclipse is an IDE. And if you're rtying to keep your projects warning free and in some way rely on it, you're stuck here, because you can't get rid of that warning, that even doesn't tell you much. And if you ignore that warning or reduce it to an info, it will still compile on javac (but produce that warning). So, nothing really dangerous here, right?
(In reply to Stephan Herrmann from comment #5) > Released for 4.9 M2 Great. I can't find a release plan for 4.9 on the net. Do you have a link? When will 4.9 M2 be available? 4.9 itself seems to be planned for September 2018. What will be the name for that release?
(In reply to Marvin Fröhlich from comment #6) > (In reply to Stephan Herrmann from comment #3) > > Things get increasingly dangerous when there is a distance between building > > a project and running it. > > I do understand that point. The eclipse compiler and the javac should go too > far off. Though Eclipse is an IDE. And if you're rtying to keep your > projects warning free and in some way rely on it, you're stuck here, because > you can't get rid of that warning, that even doesn't tell you much. And if > you ignore that warning or reduce it to an info, it will still compile on > javac (but produce that warning). So, nothing really dangerous here, right? I'm not sure we talk about the same thing here. I mentioned javac to explain that this warning is not our own invention. When I spoke of dangers I wasn't referring to differences between compilers but about users producing fragile stuff, that may easily break in the hands of their adopters. I mentioned all this to illustrate, why I believe the *default* should still be warning: to educate users about a hidden risk that is new with Java 9 and automatic modules. Once they learned about this, it's now their choice to assign the severity of their liking.
(In reply to Marvin Fröhlich from comment #7) > (In reply to Stephan Herrmann from comment #5) > > Released for 4.9 M2 > > Great. I can't find a release plan for 4.9 on the net. Do you have a link? > When will 4.9 M2 be available? 4.9 itself seems to be planned for September > 2018. What will be the name for that release? 4.9 is the version number used by the Eclipse Project, you may be more interested in the simultaneous release - named "SimRel 2018-09". Please find the schedule in https://wiki.eclipse.org/SimRel/2018-09/Simultaneous_Release_Plan
(In reply to Stephan Herrmann from comment #9) > 4.9 is the version number used by the Eclipse Project, you may be more > interested in the simultaneous release - named "SimRel 2018-09". Please find > the schedule in > https://wiki.eclipse.org/SimRel/2018-09/Simultaneous_Release_Plan Thanks. Yes, that's, what I was looking for.
(In reply to Stephan Herrmann from comment #8) > I'm not sure we talk about the same thing here. > > I mentioned javac to explain that this warning is not our own invention. > > When I spoke of dangers I wasn't referring to differences between compilers > but about users producing fragile stuff, that may easily break in the hands > of their adopters. Ok, indeed I understood it about the compile differences. Thanks for the clarification. (In reply to Stephan Herrmann from comment #8) > I mentioned all this to illustrate, why I believe the *default* should still > be warning: to educate users about a hidden risk that is new with Java 9 and > automatic modules. Once they learned about this, it's now their choice to > assign the severity of their liking. Ok, I'm fine with that. Thanks.
Eclipse SDK Version: 4.9 Build id: I20180731-2000
