JDK-8196130: Eclipse configuration files need to be updated
Kevin Rushforth
kevin.rushforth at oracle.com
Wed Jan 31 14:21:51 UTC 2018
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 <mailto: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 <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