JDK-8196130: Eclipse configuration files need to be updated
Kevin Rushforth
kevin.rushforth at oracle.com
Tue Jan 30 19:03:42 UTC 2018
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 <mailto: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
>> <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 <mailto: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.JUNIT_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
>>> <mailto: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
>>>> <mailto: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
>>>>
>>>>
>>>
>>
>
More information about the openjfx-dev
mailing list