[prev in list] [next in list] [prev in thread] [next in thread]
List: openjdk-openjfx-dev
Subject: Re: JDK-8196130: Eclipse configuration files need to be updated
From: Kevin Rushforth <kevin.rushforth () oracle ! com>
Date: 2018-01-31 14:21:51
Message-ID: 5A71D0FF.1040004 () oracle ! com
[Download RAW message or body]
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@oracle.com <mailto:kevin.rushforth@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@oracle.com <mailto:kevin.rushforth@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@oracle.com
> > > <mailto:kevin.rushforth@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@oracle.com
> > > > <mailto:kevin.rushforth@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@oracle.com
> > > > > <mailto:kevin.rushforth@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
> > > > >
> > > > >
> > > >
> > >
> >
>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic