Review Request: JDK-8226850: Use an EnumSet for DirtyBits instead of an ordinal-based mask

[Nir Lisker]

Hi Kevin/Ambarish,

Please review the simple fix for:
https://bugs.openjdk.java.net/browse/JDK-8226850
http://cr.openjdk.java.net/~nlisker/8226850/webrev.00/

Thanks,
Nir

Re: Javapackager 10 to bundle OpenJDK 11 runtime

[Alan White]

Apologies for the spam. This was my issue, I got confused renewing my certs, as 
to which one did what. Apple have not changed the prefix, and despite warnings 
about notarising, it seems to all work. Just wish there weren’t so many cert 
types flying around to sign an app!

Meantime, crisis over and patch distributed, I’ll work to migrate to jpackage.

Thanks
Alan

> On 9 Jul 2019, at 18:51, Alan White  wrote:
> 
> Hi Johan
> 
> Been using the gluon packager successfully on windows and macOS, awaiting the 
> release of the JEP343 (I think) one - thank you (from me and my user base)!
> 
> I just had to renew my Apple developer cert that’s used for signing and 
> discover that Apple have changed the CN in the developer cert from “Developer 
> ID Application:” to “Mac Developer:”. Checking 
> https://github.com/johanvos/openjdk-mobile11/blob/packager/src/jdk.packager/macosx/classes/jdk/packager/internal/mac/MacAppBundler.java
>  
> 
>  I see the CN prefix is hard-coded, so my options appear to be fork, edit  
> rebuild.
> 
> Anyone aware of any other options, or is now the time to switch to the early 
> access jpackage plse?
> 
> Thanks
> Alan
> 
>> On 19 Dec 2018, at 18:10, Johan Vos > > wrote:
>> 
>> The packager that works with Java 11 and JavaFX 11 is at
>> 
>> http://download2.gluonhq.com/jpackager/11/jdk.packager-linux.ziphttp://download2.gluonhq.com/jpackager/11/jdk.packager-osx.ziphttp://download2.gluonhq.com/jpackager/11/jdk.packager-windows.zip
>>  
>> 
>> 
>> (see
>> http://mail.openjdk.java.net/pipermail/openjfx-dev/2018-September/022500.html
>> ).
>> 
>> However, I highly recommend testing the early access version of jpackage.
>> That is the way forward for the packager.
>> 
>> - Johan
>> 
>> 
>> On Wed, Dec 19, 2018 at 6:36 PM Kevin Rushforth 
>> wrote:
>> 
>>> I doubt that will work.
>>> 
>>> We are developing a replacement tool, jpackage [1], which will be part
>>> of OpenJDK. It is planned for JDK 13, and will support JDK 11 or later
>>> as a Java runtime. You can download an early access of this tool on
>>> jdk.java.net [2]. Discussion on jpackage is happening on the
>>> core-libs-dev mailing list [3]. Alternatively, Gluon has a standalone
>>> version of javapackager that will work with JDK 11. Johan Vos can
>>> provide a pointer.
>>> 
>>> -- Kevin
>>> 
>>> [1] https://openjdk.java.net/jeps/343
>>> [2] http://jdk.java.net/jpackage/
>>> [3] http://mail.openjdk.java.net/mailman/listinfo/core-libs-dev
>>> 
>>> On 12/19/2018 5:28 AM, Alan White (Drum Score Editor) wrote:
 I understand the guidance for apps created with OpenJDK 11, is to use
>>> the javapackager from jdk 10.
 
 The old basedir parameter that could be used to direct the packager to
>>> use a specific runtime is no longer present.
 
 Is there any mechanism I’ve missed in order to have the packager from
>>> jdk10 bundle the 11 runtime plse?
 
 Thanks
>>> 
>>> 
> 

[14] RFR: JDK-8226365: Change JavaFX release version to 14

[Kevin Rushforth]

Please review the following to bump the JavaFX release version in 
jfx-dev to 14:


https://bugs.openjdk.java.net/browse/JDK-8226365
https://github.com/javafxports/openjdk-jfx/pull/523

-- Kevin

OpenJFX 13 is in Rampdown Phase One (RDP1)

[Kevin Rushforth]

OpenJFX 13 is now in Rampdown Phase One RDP1 [1]. We have forked a new 
jfx-13/rt repo [2] for stabilizing the OpenJFX 13 release.


Here is the short summary of what this means:

- The openjfx/13-dev/rt repo is now open for pushing changesets for FX 
13 that meet the RDP1 criteria as outlined below.


- The openjfx/jfx-dev/rt repo is available for pushing bug fixes or 
enhancements for FX 14.


- I will periodically sync 13-dev --> jfx-dev (meaning that developers 
should push to one or the other, not both)


- The develop branch of the javafxports/openjdk-jfx GitHub sandbox may 
be used for either FX 13 or FX 14 changes


During RDP1, the only restriction is that any enhancements will need 
explicit approval to go into openjfx13, although most enhancements 
should be retargeted to openjfx14 now. Note that these restrictions 
apply only to the forked 13-dev/rt repo. The jfx-dev/rt repo is open for 
openjfx14 fixes.


We will use the same rules for RDP1 that the JDK uses [3], with the same 
three modifications we did for the previous release:


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 13 release. As an obvious choice, derived from the 
JBS fix version, we will use "openjfx13-enhancement-request", 
"openjfx13-enhancement-yes", "openjfx13-enhancement-no" and 
"openjfx13-enhancement-nmi" as corresponding labels.


3. No explicit approval is needed to push P4 bugs to jfx-13/rt during 
RDP1, as long as those bugs have otherwise met the usual code review 
criteria. Having said that, most P4 bugs should now go into jfx-dev for 
openjfx14, since we do not want to risk anything that would destabilize 
the openjfx13 release without a compelling reason. Also, we have less 
than 4 weeks until RDP2 of openjfx13 and we would be better served 
fixing higher priority bugs. Note that doc bugs and test bugs of any 
priority are fine to fix for openjfx13 during this time.


Let me know if there are any questions.

-- Kevin

[1] http://mail.openjdk.java.net/pipermail/openjfx-dev/2019-June/023385.html

[2] http://hg.openjdk.java.net/openjfx/13-dev/rt

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

[RFR] JDK-8223760: allow to build static libs

[Johan Vos]

Hi Kevin,

Please review the following PR:

JBS: https://bugs.openjdk.java.net/browse/JDK-8223760

https://github.com/javafxports/openjdk-jfx/pull/470

Thanks,

- Johan

Re: Windows (32bit) build problems

[Robert Lichtenberger]

After restarting from scratch (on a different machine) the build
problems described below simply went away :-). So there was probably
something in my environment or I changed something inadvertently.

Best regards,
Robert

Am 08.07.19 um 08:13 schrieb Robert Lichtenberger:
> Am 05.07.19 um 11:32 schrieb Dan Howard:
>> You will need Windows 7 or later (Windows 10 is recommended) 64-bit OS
> I have Windows 7 64-bit OS, but my target platform is Windows 32-bit ;-).
>
>
> From a first cursory look it seems that in win.gradle:
>
> def winSdkBinDir = "$WINDOWS_SDK_DIR/Bin"
> if (WINDOWS_VS_VER != "100") {
>     winSdkBinDir += "/$CPU_BITS"
> }
>
> appends x86 to the winSdkBinDir and thus cannot find rc.exe which is
> located at C:\Program Files\Microsoft SDKs\Windows\v7.1\Bin and not in
> C:\Program Files\Microsoft SDKs\Windows\v7.1\Bin\x86.

Re: Table data entry

[Kevin Rushforth]

The JBS bug is: https://bugs.openjdk.java.net/browse/JDK-8089514

The current status is still as Jonathan described it. This would be a 
very good enhancement to have, but it will require a fair bit of work to 
drive consensus on the best way to define and implement this, and then 
to finish it.


-- Kevin



On 7/8/2019 11:49 PM, Jonathan Giles wrote:

It was never merged. It exists somewhere in JBS as a patch file or webrev
link. The API was decent (IMHO), but not completely implemented (and nor
did everyone agree with my opinion). It worked for simple cases (i.e.
ListCell, TreeCell, TableCell, and TreeTableCell), but probably needed more
fleshing out to work appropriately in the TableRow and TreeTableRow cases.

On Tue, Jul 9, 2019 at 6:45 PM Tom Eugelink  wrote:


There is a chance that I may need to start a complete rewrite of a Swing
client, of course I'm considering JavaFX, but only if I can do efficient
data entry in tables. This means: enter commits value and moves focus to
another (not necessarily the next) cell. AFAIK one of the requirements is
the TableView & CellEditor patch that Jonathan Giles discussed while he was
still working at Oracle. I was wondering if that was ever implemented. And
if not, why not; it seemed like a doable and highly requested patch.

Regards, Tom

[RFR] [openjfx13] 8227431: [Windows] Fix assertion failure on X86 32-bit when enabling CLOOP based JavaScript interpreter

[Arunprasad Rajkumar]

Hi Kevin,

Please review the following PR,

https://github.com/javafxports/openjdk-jfx/pull/525

Thanks,
Arun

[RFR] [openjfx13] 8222912: Websocket client doesn't work in WebView

[Arunprasad Rajkumar]

Hi Kevin,

Please review the following PR,

JBS: https://bugs.openjdk.java.net/browse/JDK-8222912

https://github.com/javafxports/openjdk-jfx/pull/524

Thanks,
Arun

Re: Table data entry

[Jonathan Giles]

It was never merged. It exists somewhere in JBS as a patch file or webrev
link. The API was decent (IMHO), but not completely implemented (and nor
did everyone agree with my opinion). It worked for simple cases (i.e.
ListCell, TreeCell, TableCell, and TreeTableCell), but probably needed more
fleshing out to work appropriately in the TableRow and TreeTableRow cases.

On Tue, Jul 9, 2019 at 6:45 PM Tom Eugelink  wrote:

> There is a chance that I may need to start a complete rewrite of a Swing
> client, of course I'm considering JavaFX, but only if I can do efficient
> data entry in tables. This means: enter commits value and moves focus to
> another (not necessarily the next) cell. AFAIK one of the requirements is
> the TableView & CellEditor patch that Jonathan Giles discussed while he was
> still working at Oracle. I was wondering if that was ever implemented. And
> if not, why not; it seemed like a doable and highly requested patch.
>
> Regards, Tom
>
>

Table data entry

[Tom Eugelink]

There is a chance that I may need to start a complete rewrite of a Swing client, of 
course I'm considering JavaFX, but only if I can do efficient data entry in tables. 
This means: enter commits value and moves focus to another (not necessarily the 
next) cell. AFAIK one of the requirements is the TableView & CellEditor patch 
that Jonathan Giles discussed while he was still working at Oracle. I was wondering 
if that was ever implemented. And if not, why not; it seemed like a doable and 
highly requested patch.

Regards, Tom