JDK-8196130: Eclipse configuration files need to be updated

[Nir Lisker]

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\main\java\javafx\beans\Observable.java
- in the JDK it's in: jdk\modules\javafx.base\javafx\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\javafx\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\javafx\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/
> 305d127c6ed5/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
>>>>>>
>>>>>
>>>
>>
>