JDK-8196130: Eclipse configuration files need to be updated

Fri Feb 2 16:52:33 UTC 2018

Alright, got most of them ready.

About buildSrc:
- What is
"rt\buildSrc\build\generated-src\antlr\com\sun\scenario\effect\compiler"
supposed to be? It is listed as a source folder but it's empty.
- The project lists dependencies such as "build/libs/swt-debug.jar", JUnit
and a JRE/JDK, but doesn't need any of them (from Eclipse's point of view).
I see the base module listing this project as a dependency, but it's not
used. Where is it located in the dependency chain?

On Thu, Feb 1, 2018 at 9:48 PM, Kevin Rushforth <kevin.rushforth at oracle.com>
wrote:

> It probably makes sense to submit what you have now as a partially working
> solution.
>
> As for Eclipse making any changes, I'm not sure there is a spec you could
> point to ... we do some of the same magic that I'm sure other projects have
> had to do w.r.t running tests:
>
> * We have test "shims" for white-box testing that we add into our modules
> when running tests (this requires copying all of the class files for our
> modules and adding the shim classes on top of that)
>
> * We build the tests separately (the tests are in a separate source set in
> gradle) without a module-info so that they run in the unnamed module. This
> allows them to access JUnit, etc., as well as any public package of any
> module in the system. As such we need to explicitly list any internal
> packages that they use from the module they are testing. These are listed
> in src/test/addExports
>
>
> -- Kevin
>
>
> Nir Lisker wrote:
>
> Looks like I understood the problem. Eclipse does not support (yet)
> multiple modules per project. Do you know any specifications I can point
> them to to fix this properly?
>
> The current workaround would be to add 'requires' for all the modules
> which are used in tests as well. This change is local and would be excluded
> from webrevs.
>
> At this point I can either submit the partially fixed Eclipse files, which
> work with main code fully and with test code only if the above fix is used;
> or wait until Eclipse sorts it out.
>
> On Wed, Jan 31, 2018 at 4:21 PM, Kevin Rushforth <
> kevin.rushforth at oracle.com> wrote:
>
>>
>>
>> Nir Lisker wrote:
>>
>> rt/modules/javafx.base/build/classes/main/javafx.base/
>>> rt/modules/javafx.base/src/main/java/
>>
>>
>> Why not rely on source first?
>>
>>
>> Yes, that might work...you could try switching the order.
>>
>>
>>
>> Another question as I move along: there are imports
>> from java.util.logging in base module, but the module-info doesn't
>> require java.logging. How do I give access to these imports?
>>
>>
>> The only references to java.util.logging are in the javafx.base unit
>> tests, which are compiled and run in the unnamed modules (no
>> module-info.java for the unit tests).
>>
>> -- Kevin
>>
>>
>>
>> On Tue, Jan 30, 2018 at 9:03 PM, Kevin Rushforth <
>> kevin.rushforth at oracle.com> wrote:
>>
>>> Oh, I see. You are pointing to the exploded modules  for the JDK in
>>> build/XXXXX/jdk rather than the JDK image in build/XXXXX/images/jdk.
>>>
>>> Yes, I think it would be preferable to both reverse the order and also
>>> add in the location of the built class files. So the following order seems
>>> best:
>>>
>>> rt/modules/javafx.base/build/classes/main/javafx.base/
>>> rt/modules/javafx.base/src/main/java/
>>> jdk/modules/javafx.base
>>>
>>>
>>> -- Kevin
>>>
>>>
>>> Nir Lisker wrote:
>>>
>>> This is what I mean: In the type /base/src/test/java/test/
>>> com/sun/javafx/collections/ListListenerHelperTest.java there are these
>>> imports:
>>>
>>> import test.javafx.collections.MockListObserver;
>>> import java.util.BitSet;
>>> import javafx.beans.Observable;
>>>
>>> The first one is the one in FX: rt\modules\javafx.base\src
>>> \test\java\test\javafx\collections\MockListObserver.java
>>> The second one is in the referenced JDK which was built with
>>> FX: jdk\modules\java.base\java\util\BitSet.class
>>> The third one exists in both:
>>> - in JFX it's in: rt\modules\javafx.base\src\mai
>>> n\java\javafx\beans\Observable.java
>>> - in the JDK it's in: jdk\modules\javafx.base\ja
>>> vafx\beans\Observable.class
>>>
>>> Does the question make sense now?
>>>
>>> On Tue, Jan 30, 2018 at 5:04 AM, Kevin Rushforth <
>>> kevin.rushforth at oracle.com> wrote:
>>>
>>>>
>>>> one in "rt\modules\javafx.base\src\main\java\javafx\beans\InvalidationListener.java"
>>>> or the one in "jdk\modules\javafx.base\javaf
>>>> x\beans\InvalidationListener.class"?
>>>>
>>>>
>>>> Not sure I get what you mean. There isn't a jdk/modules/ directory
>>>> created by the build. Perhaps this is an Eclipse construct that it uses to
>>>> indicate the modules that are in the JDK that you are using? The FX build
>>>> puts the class files in:
>>>>
>>>> rt/build/modular_sdk/modules/javafx.base/...
>>>>
>>>>
>>>> -- Kevin
>>>>
>>>>
>>>> Nir Lisker wrote:
>>>>
>>>> Another question: do imports of javafx.* packages point to the javafx
>>>> source or to the jdk compilation?
>>>>
>>>> For example, in the base module, the type test.javafx.beans.InvalidationListenerMock
>>>> imports javafx.beans.InvalidationListener (twice, by the way, along
>>>> with Observable). Should the imported class be the one in
>>>> "rt\modules\javafx.base\src\main\java\javafx\beans\InvalidationListener.java"
>>>> or the one in "jdk\modules\javafx.base\javaf
>>>> x\beans\InvalidationListener.class"?
>>>>
>>>> Currently, the way it is in the Eclipse files is that the jdk .class
>>>> files are imported first[1], but it seemed odd to me - if I work on 2 files
>>>> which depend on each other they should see the changes in each other at
>>>> once.
>>>>
>>>> [1]http://hg.openjdk.java.net/openjfx/jfx-dev/rt/file/305d12
>>>> 7c6ed5/modules/javafx.base/.classpath ("JRE_CONTAINER" is before
>>>> "src/main/java"),
>>>>
>>>> - Nir
>>>>
>>>> On Fri, Jan 26, 2018 at 9:20 PM, Kevin Rushforth <
>>>> kevin.rushforth at oracle.com> wrote:
>>>>
>>>>> inline
>>>>>
>>>>> Nir Lisker wrote:
>>>>>
>>>>> Alright, cleaned that part. fxpackager build fails with an internal
>>>>> NPE in Eclipse, so I'm going to leave that alone and all of the projects
>>>>> that depends on it.
>>>>>
>>>>> Now that projects can be built there are errors in deeper levels:
>>>>>
>>>>> 1. All org.junit imports cannot be resolved. This causes tons of
>>>>> errors in various test folders obviously. All the .classpath files use
>>>>>
>>>>> <classpathentry kind="con" path="org.eclipse.jdt.junit.JU
>>>>> NIT_CONTAINER/4"/>
>>>>>
>>>>> which is a jar distributed with Eclipse (in the plugins folder) with
>>>>> version 4.12.0. Is this really where the imports are supposed to come from?
>>>>> How does it work in Netbeans or IntelliJ?
>>>>>
>>>>>
>>>>> For NetBeans we use their internal version of JUnit. I don't know
>>>>> about IntelliJ (maybe someone else on the list can answer that).
>>>>>
>>>>> 2. In the 'base' module, in "/src/main/java-jfr/com/sun/javafx/logging"
>>>>> there are imports of com.oracle.jrockit.jfr that can't be resolved. Where
>>>>> are these located?
>>>>>
>>>>>
>>>>> These classes used to be part of the JFR commercial feature in the
>>>>> Oracle JDK. The java-jfr sources are obsolete and no longer built (and no
>>>>> longer buildable), so you can safely remove it from your IDE files. I also
>>>>> still see references to it in the netbeans/base project. I will file a bug
>>>>> to remove this obsolete code and fix the NetBeans references at the same
>>>>> time.
>>>>>
>>>>> -- Kevin
>>>>>
>>>>>
>>>>>
>>>>> On Thu, Jan 25, 2018 at 5:24 PM, Kevin Rushforth <
>>>>> kevin.rushforth at oracle.com> wrote:
>>>>>
>>>>>> Ah, I see. Then yes, just removing the old ones is fine.
>>>>>>
>>>>>> As for the larger question, unless there are dependencies on apps,
>>>>>> you can assume that the only ones you care about are the ones created by
>>>>>> "gradle sdk".
>>>>>>
>>>>>> -- Kevin
>>>>>>
>>>>>>
>>>>>>
>>>>>> Nir Lisker wrote:
>>>>>>
>>>>>> So this is why I was asking about the optional stuff: 'graphics'
>>>>>> module has BOTH
>>>>>>
>>>>>> build/resources/jsl-decora
>>>>>> build/resources/jsl-prism
>>>>>>
>>>>>> and
>>>>>>
>>>>>> build/gensrc/jsl-decora
>>>>>> build/gensrc/jsl-prism
>>>>>>
>>>>>> That led me to think that when the new dependencies were added the
>>>>>> old ones weren't removed. Those that weren't optional (like the /resources
>>>>>> ones, which I removed) were easy to catch and we could have finished here.
>>>>>> Those that are optional are not causing trouble even when missing because
>>>>>> they are optional.
>>>>>>
>>>>>> gradle sdk does not create the ones which are marked optional that
>>>>>> Iv'e surveyed, but I don't know if that's the only way they can be created.
>>>>>> If I compare solely with gradle sdk then I can just remove whatever is
>>>>>> missing on grounds that it's left over.
>>>>>>
>>>>>> - Nir
>>>>>>
>>>>>> On Thu, Jan 25, 2018 at 4:06 PM, Kevin Rushforth <
>>>>>> kevin.rushforth at oracle.com> wrote:
>>>>>>
>>>>>>> One more thing about the specific path you mentioned as not being
>>>>>>> there.
>>>>>>>
>>>>>>> <classpathentry kind="src" exported="true"
>>>>>>> path="build/resources/jsl-decora"/>
>>>>>>> <classpathentry kind="src" exported="true"
>>>>>>> path="build/resources/jsl-prism"/>
>>>>>>>
>>>>>>> These are still being created by 'gradle sdk', but the path is wrong
>>>>>>> (the files moved in JDK 9) and should be:
>>>>>>>
>>>>>>> build/gensrc/jsl-decora
>>>>>>> build/gensrc/jsl-prism
>>>>>>>
>>>>>>> You might want to take that into account.
>>>>>>>
>>>>>>> -- Kevin
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Kevin Rushforth wrote:
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Nir Lisker wrote:
>>>>>>>>
>>>>>>>>> Iv'e removed all the classpath dependencies that were causing
>>>>>>>>> errors. I don't mind sorting out the rest of the files while at it, though
>>>>>>>>> for that there are a few things I'm not sure about:
>>>>>>>>>
>>>>>>>>> 1. Some dependencies are marked as optional and as such they don't
>>>>>>>>> cause errors, but they are still missing. Is it safe to remove them or is
>>>>>>>>> it possible that they will be created as some point?
>>>>>>>>>
>>>>>>>>
>>>>>>>> Some of them might be created...not sure without checking. I
>>>>>>>> recommend running "gradle sdk" and then seeing if the dependencies are
>>>>>>>> there.
>>>>>>>>
>>>>>>>> Examples are the 'base' module with "src/test/resources" and
>>>>>>>>> "src/main/resources" optional dependencies, and 'controls' module has the
>>>>>>>>> optional dependency "src/main/resources" commented out.
>>>>>>>>>
>>>>>>>>
>>>>>>>> I see. You might as well leave them, but it probably doesn't matter.
>>>>>>>>
>>>>>>>> 2. Can I assume that all other dependencies are really needed?
>>>>>>>>> (Eclipse won't complain about unused ones as far as I know.)
>>>>>>>>>
>>>>>>>>
>>>>>>>> That seems best.
>>>>>>>>
>>>>>>>> 3. What are the formatting standards for XML (indentation, line
>>>>>>>>> length...)? From a quick look I see different styles in different files.
>>>>>>>>>
>>>>>>>>
>>>>>>>> For IDE files, we don't worry about formatting. In many cases they
>>>>>>>> are auto-generated anyway.
>>>>>>>>
>>>>>>>> -- Kevin
>>>>>>>>
>>>>>>>>
>>>>>>>>> - Nir
>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>