JDK-8196130: Eclipse configuration files need to be updated

[Nir Lisker]

>
> rt/modules/javafx.base/build/classes/main/javafx.base/
> rt/modules/javafx.base/src/main/java/


Why not rely on source first?

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?

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\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/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
>>>>>>>
>>>>>>
>>>>
>>>
>>
>