Re: OpenJFX 11 is in Rampdown Phase Two (RDP2)

[Kevin Rushforth]

One more item of interest to developers who use the 
javafxports/openjdk-jfx GitHub sandbox repo [1] :


I just pushed a new 'jfx-11' branch to GitHub. The 'jfx-11' branch will 
track changesets pushed to the HG openjfx/11-dev/rt repo in the same 
manner that the 'master' branch tracks changesets pushed to the HG 
openjfx/jfx-dev/rt repo. Developers should consider this branch 
"read-only" and not make any pull requests against it (other than 
experimental "WIP" PRs for test purposes).


All PRs should continue to be done against the develop branch.

Let Johan or I know if you have any questions.

-- Kevin

[1] https://github.com/javafxports/openjdk-jfx


On 8/7/2018 3:31 PM, Kevin Rushforth wrote:

To: OpenJFX Developers

As a reminder, OpenJFX 11 is now in Rampdown Phase Two RDP2. [1]

During RDP2, all bug fixes, except for docs and test fixes, and all 
enhancements will need explicit approval to go in. Note that these 
restrictions apply to the soon-to-be-created openjfx/11-dev/rt repo [2].


Starting now, the jfx-dev/rt mainline -- and by extension, the develop 
branch of the GitHub sandbox -- is open for openjfx12 fixes.


We will use the same rules for RDP2 that the JDK uses [3], with three 
modifications:


1. Approval is needed from one of the OpenJFX project leads (not the 
OpenJDK project lead)


2. Since we are not part of the JDK, we need to use labels that do not 
collide with the JDK 11 release. As an obvious choice, derived from 
the JBS fix version, we will use "openjfx11-fix-request", 
"openjfx11-fix-yes", "openjfx11-fix-no" and "openjfx11-fix-nmi", 
"openjfx11-enhancement-request", "openjfx11-enhancement-yes", 
"openjfx11-enhancement-no" and "openjfx11-enhancement-nmi" as 
corresponding labels.


3. Some important P3 bugs might be considered during RDP2, as long as 
those bugs have otherwise met the usual code review criteria. Having 
said that, most P3 bugs should be moved to openjfx12 at this point. I 
do not expect many P3 bugs to be approved.


If a fix is approved to push to 11-dev (with the appropriate approval 
label added by a lead), then you need not also push it to jfx-dev -- 
we will auto-sync from 11-dev --> jfx-dev for the duration of the 
openjfx11 release.


Now that we are in RDP2, the goal should be to stabilize what is 
there, with priority on fixing bugs that are new in openjfx11. We need 
to be extremely careful about including anything that introduces risk.


Let me know if there are any questions.

-- Kevin

[1] 
http://mail.openjdk.java.net/pipermail/openjfx-dev/2018-August/022233.html


[2] http://hg.openjdk.java.net/openjfx/11-dev/rt  (not yet created as 
of this writing)


[3] http://openjdk.java.net/jeps/3

JDK-8209015: Update Eclipse project files

[Nir Lisker]

Hi,

After the removal of some dependencies on JDK modules the Eclipse classpath
files should be updated to allow developers to work on Eclipse without
needing to do tricky configuration themselves. Iv'e submitted a JBS issue
[1] to track the progress.

There were discussion about removing IDE-specific files in the JBS [2] and
on GitHub (see links in JBS issue). It seems that the idea was dropped and
I propose to close this issue. A discussion on this issue can be found on
the mailing list [3].

On to the technical discussion:

Iv'e put up a gist with my classpath files [4], but Swing still gives me
problems with an NPE during the build.

On 08.08.18 08:55, Tom Schindl wrote:
> > Hi Nir,
> >
> > I currently use the attached stash to make Eclipse compile all modules.
> >
> > Unfortunately I have to modify the following java-Files to get away
> > without any compile errors:
> > * Dialog => Added a method getDialog() instead of directly accessing the
> > field
>

We have to wait for the fix [5], there's no workaround.


> > * javafx.fxml => Add a static require for controls
> > * javafx.web  => Add a static require for java.management
>
> Looking once more I think read-edges are completely missing in Eclipse
> for projects. I can patch other projects to get a read-edge but not the
> project itself!
>
> In the end what we want is to patch eg the javafx.fxml-module to have a
> read-edge for javafx.control. I don't see how this can be done with the
> current Eclipse setup!
>
> My work around today is to add static-require and I don't see a way
> around that.
>

It's possible to do it in the classpath file as Iv'e shown in [6], but I
don't know if JUnit will work. I seem to have general JUnit problems. Can
you try with my files and unmodified module-info.java files and see which
projects can run JUnit? They should all compile.

The bulk of the work for modular support is tracked under [7] and they want
input from users, so try to help them. There's also a UI specific issue for
modular projects [8].

- Nir

[1] https://bugs.openjdk.java.net/browse/JDK-8209015

[2] https://bugs.openjdk.java.net/browse/JDK-8198795

[3]
http://mail.openjdk.java.net/pipermail/openjfx-dev/2018-April/021740.html

[4] https://gist.github.com/nlisker/fd2d42f6467c069cf8c4cc054ba0ea40

[5] https://bugs.eclipse.org/bugs/show_bug.cgi?id=536330

[6] https://bugs.eclipse.org/bugs/show_bug.cgi?id=526963

[7] https://bugs.eclipse.org/bugs/show_bug.cgi?id=526831

[8] https://bugs.eclipse.org/bugs/show_bug.cgi?id=536330

Re: Swing module's module-info file

[Nir Lisker]

Yes, but since this thread was about the Swing module's module-info I'll
start another thread with the link to the JBS issue I created a few days
ago about Eclipse.

On Wed, Aug 8, 2018 at 10:10 AM, Tom Schindl 
wrote:

> Hi,
>
> On 08.08.18 08:55, Tom Schindl wrote:
> > Hi Nir,
> >
> > I currently use the attached stash to make Eclipse compile all modules.
> >
> > Unfortunately I have to modify the following java-Files to get away
> > without any compile errors:
> > * Dialog => Added a method getDialog() instead of directly accessing the
> > field
> > * javafx.fxml => Add a static require for controls
> > * javafx.web  => Add a static require for java.management
>
> Looking once more I think read-edges are completely missing in Eclipse
> for projects. I can patch other projects to get a read-edge but not the
> project itself!
>
> In the end what we want is to patch eg the javafx.fxml-module to have a
> read-edge for javafx.control. I don't see how this can be done with the
> current Eclipse setup!
>
> My work around today is to add static-require and I don't see a way
> around that.
>
> Tom
>
> --
> Tom Schindl, CTO
> BestSolution.at EDV Systemhaus GmbH
> Eduard-Bodem-Gasse 5-7. A-6020 Innsbruck
> Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck
>

Re: Swing module's module-info file

[Tom Schindl]

Hi,

On 08.08.18 08:55, Tom Schindl wrote:
> Hi Nir,
> 
> I currently use the attached stash to make Eclipse compile all modules.
> 
> Unfortunately I have to modify the following java-Files to get away
> without any compile errors:
> * Dialog => Added a method getDialog() instead of directly accessing the
> field
> * javafx.fxml => Add a static require for controls
> * javafx.web  => Add a static require for java.management

Looking once more I think read-edges are completely missing in Eclipse
for projects. I can patch other projects to get a read-edge but not the
project itself!

In the end what we want is to patch eg the javafx.fxml-module to have a
read-edge for javafx.control. I don't see how this can be done with the
current Eclipse setup!

My work around today is to add static-require and I don't see a way
around that.

Tom

-- 
Tom Schindl, CTO
BestSolution.at EDV Systemhaus GmbH
Eduard-Bodem-Gasse 5-7. A-6020 Innsbruck
Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck

Re: Swing module's module-info file

[Tom Schindl]

Hi Nir,

I currently use the attached stash to make Eclipse compile all modules.

Unfortunately I have to modify the following java-Files to get away
without any compile errors:
* Dialog => Added a method getDialog() instead of directly accessing the
field
* javafx.fxml => Add a static require for controls
* javafx.web  => Add a static require for java.management
* MarlinUtils => Small JavaDoc fix because one can not access
 sun.security

Issues 1 - 3 are Eclipse issues. The error in Dialog is known by the
Eclipse people. I'm not sure with the Read-Edges we'd have to add to get
around the module-info.java changes, IMHO the UI in Eclipse in this area
is completely senseless (or I'm too dumb to understand it)

Issue 4: Is something one could discuss if the Marlin maintainers would
be ok to change?

Tom

On 08.08.18 01:27, Nir Lisker wrote:
> Ah, yes, I was trying to see what modifications each project needs so I
> didn't have it modified.
> 
> Can you share your Swing .classpath? Eclipse gives me a NPE during the
> build task, I think something broke.
> 
> On Tue, Aug 7, 2018 at 8:54 PM, Tom Schindl  > wrote:
> 
> Oh but naturally my .classpath-File is modified
> 
> Tom
> 
> On 07.08.18 19:51, Tom Schindl wrote:
> > Yes they do!
> >
> > Tom
> >
> > On 07.08.18 19:36, Nir Lisker wrote:
> >> And both newimlp and oldimpl packages compile for you?
> >>
> >> On Tue, Aug 7, 2018 at 8:04 PM, Tom Schindl
> mailto:tom.schi...@bestsolution.at>
> >>  >> wrote:
> >>
> >>     Hi Nir,
> >>
> >>     I'm using OpenJDK-11 in my eclipse for development so I have
> that module
> >>     included.
> >>
> >>     Tom
> >>
> >>     On 07.08.18 18:34, Nir Lisker wrote:
> >>     > So you rebuilt the JDK with the new jdk.unsupported.desktop
> module?
> >>     >
> >>     > On Tue, Aug 7, 2018 at 3:11 PM, Tom Schindl
> mailto:tom.schi...@bestsolution.at>
>  >
> >>     >  
>   >>     wrote:
> >>     >
> >>     >     Well I simply added the folder to my class-folders and
> things then work
> >>     >     perfectly fine inside Eclipse
> >>     >
> >>     >     Tom
> >>     >
> >>     >     On 07.08.18 14:02, Nir Lisker wrote:
> >>     >     > Thanks for the info. I'm working on updating the
> Eclipse files and
> >>     >     this is
> >>     >     > causing problems for javafx.swing. When will the
> minimum version
> >>     >     be bumped
> >>     >     > to 11?
> >>     >     >
> >>     >     > On Tue, Aug 7, 2018 at 7:51 AM, Prasanta Sadhukhan <
> >>     >     > prasanta.sadhuk...@oracle.com
> 
>  >
> >>     >      
> >>       >>     >     >
> >>     >     >> This is because if fx is compiled with a jdk version
> which does
> >>     >     not have
> >>     >     >> jdk.unsupported.desktop module then having
> module-info.java in
> >>     >     its original
> >>     >     >> place would cause compilation error as module-info.java
> >>     contains
> >>     >     >>
> >>     >     >> requires static jdk.unsupported.desktop;
> >>     >     >>
> >>     >     >> So, the idea was to copy the file into a directory
> which is not
> >>     >     on the
> >>     >     >> module-source-path. Then build.gradle copy it from
> there to
> >>     gensrc
> >>     >     >> directory optionally filtering the above line
> >>     >     >>  task copyModuleInfo(type: Copy, description: "copy
> module-info
> >>     >     file to
> >>     >     >> gensrc") {
> >>     >     >>         from "src/main/module-info/module-info.java"
> >>     >     >>         into "$buildDir/gensrc/java/"
> >>     >     >>         filter { line->
> >>     >     >>             !HAS_UNSUPPORTED_DESKTOP &&
> >>     >     line.contains('jdk.unsupported.desktop')
> >>     >     >> ? null : line
> >>     >     >>         }
> >>     >     >>     }
> >>     >     >>
> >>     >     >> Regards
> >>     >     >> Prasanta
> >>     >     >>
> >>     >     >> On 8/7/2018 6:42 AM, Nir Lisker wrote:
> >>     >     >>
> >>     >     >>> Hi,
> >>     >     >>>
> >>     >