Re: Testing JavaFX with Java14 preview features

[Nir Lisker]

I managed to get it working by adding  "--enable-preview" in several
places, I'm not sure if they are all needed. There will be a test branch in
my fork with the working build.grade.

On Tue, Apr 14, 2020 at 4:35 AM Nir Lisker  wrote:

> It contains:
> -source
> 14
> -target
> 14
>
> Looks like I'll have to do some digging.
>
> Thanks
>
> On Tue, Apr 14, 2020 at 2:38 AM Kevin Rushforth <
> kevin.rushfo...@oracle.com> wrote:
>
>> Not sure, but you might check here:
>>
>> modules/javafx.base/build/tmp/compileJava/java-compiler-args.txt
>>
>> That's the list of args that gradle generates to pass to javac (using
>> @.../java-compiler-args.txt)
>>
>> -- Kevin
>>
>> On 4/13/2020 4:10 PM, Nir Lisker wrote:
>>
>> Thanks, yes, testing on JavaFX itself.
>> I made these changes. I'm getting "error: invalid source release: 14"
>> when trying to build. These are the settings that are output during the
>> task:
>>
>> Gradle Distribution: Gradle wrapper from target build
>> Gradle Version: 6.3
>> Java Home: C:\Program Files\Java\jdk-14
>> JVM Arguments: None
>> Program Arguments: None
>> Build Scans Enabled: false
>> Offline Mode Enabled: false
>> Gradle Tasks: build
>>
>> This is the full error message:
>>
>> error: invalid source release: 14
>> Usage: javac  
>> use --help for a list of possible options
>>
>> FAILURE: Build failed with an exception.
>>
>> * What went wrong:
>> Execution failed for task ':base:compileJava'.
>> > Compilation failed with exit code 2; see the compiler error output for
>> details.
>>
>> On Tue, Apr 14, 2020 at 2:00 AM Kevin Rushforth <
>> kevin.rushfo...@oracle.com> wrote:
>>
>>> I guess you mean modifying the FX build in your local repo so that you
>>> can test the use of JDK 14 preview features in FX itself? (if you were
>>> just trying to use it from your app you wouldn't need any build changes
>>> in FX). At a minimum you would need to add the "--enable-preview" flag
>>> to compile.options.compilerArgs, and change "sourceCompatibility" from
>>> "11" to "14". Not sure if anything more is needed. I've never tried it.
>>>
>>> -- Kevin
>>>
>>>
>>> On 4/13/2020 1:49 PM, Nir Lisker wrote:
>>> > Hi,
>>> >
>>> > I would like to test the preview features in Java 14 on JavaFX. What
>>> > changes should I make in the build files to get it working?
>>> >
>>> > - Nir
>>>
>>>
>>

Re: Re: Windows Installation Instructions, All DLL Files Missing

[Eric Bresie]

Would jdeps help to see what dependencies are needed?

Eric Bresie
ebre...@gmail.com
> On April 18, 2020 at 1:44:43 PM CDT, Michael Paus  wrote:
> Hi Christopher,
> I do not know what your specific problem is but maybe you just have to
> shift your goals a little bit.
> Continuing like you did in the Java 8 days is not a good idea for
> various reasons. The current trend
> for distributing desktop software with Java is to build a platform
> specific installer. The tools for that
> are all there. Just give it a try. Together with Dirk Lemmermann I have
> set up a working example
> and tutorial on GitHub. It uses the latest Java/JavaFX and works on Mac
> and Windows (should also work
> on Linux but I haven't tested it.)
> 
> The nice thing about this approach is that your customer does not have
> to have anything installed on his
> own machine. He can just install your software like he would install any
> other piece of software.
> Michael
>
> Am 18.04.20 um 20:18 schrieb Christopher Miles:
> > Yep, that's where I downloaded it from.
> >
> > > PS C:\Users\cmiles\source\repos\xmltool> java --version
> > > openjdk 14.0.1 2020-04-14
> > > OpenJDK Runtime Environment (build 14.0.1+7)
> > > OpenJDK 64-Bit Server VM (build 14.0.1+7, mixed mode, sharing)
> >
> > When I look at the "bin" directory that came with the JavaFX SDK and
> > compare it to the "bin" directory that comes with OpenJDK there are
> > things in the JavaFX distribution that aren't present in the OpenJDK
> > distribution. These three caught my attention:
> >
> > + prism_common.dll
> > + prism_d3d.dll
> > + prism_sw.dll
> >
> > I suspect missing these DLL's is what is causing the exception when I
> > try to launch my application.
> >
> > I took a look at "JDK-8207015" and I don't think that is my problem,
> > yet. It could be that if the "prism_xxx.dll" files were present, I
> > might run into this issue.
> >
> > I changed my `jlink` command to point at the "mods" as this seems like
> > the correct way to do this. Still, the app refuses to launch with the
> > same error message.
> >
> > > Graphics Device initialization failed for : d3d, sw
> > > Error initializing QuantumRenderer: no suitable pipeline found
> > > java.lang.RuntimeException: java.lang.RuntimeException: Error
> > initializing QuantumRenderer: no suitable pipeline found
> >
> > I would very much like to avoid adding switches to a `java` invocation
> > in order to run the application. In your example, I would need to have
> > customer installed the JavaFX JDK to a specific location in order for
> > that to work. I'd also need to have some kind of wrapper to handle
> > other operating systems, like Linux or OS X. My goal is to distribute
> > one package with custom launching scripts (i.e. one for batch,
> > Powershell, and Linux/OS X shell) as I did under Java 8. This makes me
> > think that using `jlink` with the mods is the way to go, as long as I
> > can figure out why that is not working.
> >
> > Thank you for your help with this. :-)
> >
> > Kevin Rushforth wrote on 4/17/2020 17:34:
> > > From where are you getting your OpenJDK build?
> > > https://jdk.java.net/14 ? Somewhere else?
> > >
> > > -- Kevin
> > >
> > >
> > > On 4/17/2020 2:16 PM, Christopher Miles wrote:
> > > > Yeah, I've tried it with both. The instructions on the JavaFX page
> > > > tell you to add the "lib" directory to the `javac` path and the
> > > > "mods" to the `jlink` path. I figured, since nothing is working, why
> > > > not try them the other way around? In all cases the results are the
> > > > same.
> > > >
> > > > I'm using OpenJDK, wouldn't that project have the same issue
> > > > distributing these DLL files? I would bet they would, since they are
> > > > also an open source project. I can run Swing projects, however,
> > > > without these DLL files.
> > > >
> > > > I can give the Oracle JDK a try. I had been shying away from it
> > > > since OpenJDK is getting to be so popular. If that works, I will let
> > > > the list know.
> > > >
> > > > As an aside, the JavaFX home page recommends using OpenJDK right now:
> > > >
> > > > https://openjfx.io/openjfx-docs/#install-java
> > > >
> > > > Thank you!
> > > >
> > > > Kevin Rushforth wrote on 4/17/2020 16:51:
> > > > > Where are you getting JDK 14.0.1 from? Does it include the
> > > > > Microsoft VS2017 DLLs and Windows SDK DLLs in jdk-14.0.1/bin? There
> > > > > are 45 of them (40 of them are of the form api-ms-win-*.dll). The
> > > > > JavaFX 14.0.1 sdk includes them, but the jmods do not. See
> > > > > JDK-8207015 [1] for why not. If the JDK has them, then there should
> > > > > be no problem running a jlinked app.
> > > > >
> > > > > One possible problem is that your jlink line is wrong. You should
> > > > > not point to the SDK at all when running jlink. Use the jmods with
> > > > > jlink (don't use the sdk). Use the sdk with javac and java
> > > > > --module-path (don't use the jmods at all).
> > > > >

mailing list invite

[Apurwa Agrawal]

Hello

Please add me to mailing list:
apurw...@gmail.com

Thanks and Regards
Apurwa Agrawal

Re: [Rev 01] RFR: 8198402: ToggleButton.setToggleGroup causes memory leak when button is removed via ToggleGroup.getToggles()

[Jesper Skov]

On Sun, 19 Apr 2020 12:44:23 GMT, Jesper Skov 
 wrote:

>> I have failed getting web:tests to work.
>> Both with java 11.0.7 and 14.0.0 (adoptajdk 14.0.1 not ready yet), I get the 
>> error below.
>> 
>> And that is with both a locally built webkit, and the one from 
>> javafx-web-15-ea+3-linux.jar
>> 
>> So it seems I am unable to run web:tests task on my box (Fedora 31, FWIW).
>> 
>> Any suggestions for how to resolve this?
>> 
>> `
>>> Task :web:test
>> *
>> WARNING: running web tests without building webkit.
>> The webkit native library will be copied from the JDK,
>> which might lead to failures in some web tests.
>> To avoid these failures, you should either build
>> webkit locally, copy the native webkit library from a
>> recent build, or skip execution of web test cases with
>> '-x :web:test'
>> *
>> Exception in thread "JavaFX Application Thread"
>> #
>> # A fatal error has been detected by the Java Runtime Environment:
>> #
>> #  SIGSEGV (0xb) at pc=0x7f4e01ae8a61, pid=78774, tid=78815
>> #
>> # JRE version: OpenJDK Runtime Environment (11.0.7+10) (build 11.0.7+10)
>> # Java VM: OpenJDK 64-Bit Server VM (11.0.7+10, mixed mode, tiered, 
>> compressed oops, g1 gc, linux-amd64)
>> # Problematic frame:
>> # V  [libjvm.so+0x579a61]  
>> AccessInternal::PostRuntimeDispatch> G1BarrierSet>,
>> (AccessInternal::BarrierType)2, 1097844ul>::oop_access_barrier(void*)+0x1 #
>> # Core dump will be written. Default location: Core dumps may be processed 
>> with "/usr/lib/systemd/systemd-coredump %P
>> %u %g %s %t %c %h" (or dumping to 
>> /opt/sources/github/jfx/modules/javafx.web/core.78774) #
>> # An error report file with more information is saved as:
>> # /opt/sources/github/jfx/modules/javafx.web/hs_err_pid78774.log
>> #
>> # If you would like to submit a bug report, please visit:
>> #   https://github.com/AdoptOpenJDK/openjdk-support/issues
>> #
>> `
>
> Uh, the exception is (as the comment note suggests) from using a prebuilt 
> webkit.
> I will try a locally built one now.

Ah, well. Ended with the same VM crash when building webkit myself.

So I am kinda stuck. Suggestions?

-

PR: https://git.openjdk.java.net/jfx/pull/167

Re: [Rev 01] RFR: 8198402: ToggleButton.setToggleGroup causes memory leak when button is removed via ToggleGroup.getToggles()

[Jesper Skov]

On Sun, 19 Apr 2020 12:42:09 GMT, Jesper Skov 
 wrote:

>> @kevinrushforth I tested by:
>> `
>> bash ./gradlew clean all test -x :web:test
>> `
>> I assumed that would do it.
>> But I see use of ToggleButton in javafx.web, so that was clearly a faulty 
>> assumption.
>> 
>> I will try to get webkit working.
>
> I have failed getting web:tests to work.
> Both with java 11.0.7 and 14.0.0 (adoptajdk 14.0.1 not ready yet), I get the 
> error below.
> 
> And that is with both a locally built webkit, and the one from 
> javafx-web-15-ea+3-linux.jar
> 
> So it seems I am unable to run web:tests task on my box (Fedora 31, FWIW).
> 
> Any suggestions for how to resolve this?
> 
> `
>> Task :web:test
> *
> WARNING: running web tests without building webkit.
> The webkit native library will be copied from the JDK,
> which might lead to failures in some web tests.
> To avoid these failures, you should either build
> webkit locally, copy the native webkit library from a
> recent build, or skip execution of web test cases with
> '-x :web:test'
> *
> Exception in thread "JavaFX Application Thread"
> #
> # A fatal error has been detected by the Java Runtime Environment:
> #
> #  SIGSEGV (0xb) at pc=0x7f4e01ae8a61, pid=78774, tid=78815
> #
> # JRE version: OpenJDK Runtime Environment (11.0.7+10) (build 11.0.7+10)
> # Java VM: OpenJDK 64-Bit Server VM (11.0.7+10, mixed mode, tiered, 
> compressed oops, g1 gc, linux-amd64)
> # Problematic frame:
> # V  [libjvm.so+0x579a61]  
> AccessInternal::PostRuntimeDispatch G1BarrierSet>,
> (AccessInternal::BarrierType)2, 1097844ul>::oop_access_barrier(void*)+0x1 #
> # Core dump will be written. Default location: Core dumps may be processed 
> with "/usr/lib/systemd/systemd-coredump %P
> %u %g %s %t %c %h" (or dumping to 
> /opt/sources/github/jfx/modules/javafx.web/core.78774) #
> # An error report file with more information is saved as:
> # /opt/sources/github/jfx/modules/javafx.web/hs_err_pid78774.log
> #
> # If you would like to submit a bug report, please visit:
> #   https://github.com/AdoptOpenJDK/openjdk-support/issues
> #
> `

Uh, the exception is (as the comment note suggests) from using a prebuilt 
webkit.
I will try a locally built one now.

-

PR: https://git.openjdk.java.net/jfx/pull/167

Re: [Rev 01] RFR: 8198402: ToggleButton.setToggleGroup causes memory leak when button is removed via ToggleGroup.getToggles()

[Jesper Skov]

On Sun, 19 Apr 2020 09:56:27 GMT, Jesper Skov 
 wrote:

>> The fix looks correct to me. Have you run all tests to ensure no regressions?
>> 
>> I left a couple inline comments.
>
> @kevinrushforth I tested by:
> `
> bash ./gradlew clean all test -x :web:test
> `
> I assumed that would do it.
> But I see use of ToggleButton in javafx.web, so that was clearly a faulty 
> assumption.
> 
> I will try to get webkit working.

I have failed getting web:tests to work.
Both with java 11.0.7 and 14.0.0 (adoptajdk 14.0.1 not ready yet), I get the 
error below.

And that is with both a locally built webkit, and the one from 
javafx-web-15-ea+3-linux.jar

So it seems I am unable to run web:tests task on my box (Fedora 31, FWIW).

Any suggestions for how to resolve this?

`
> Task :web:test
*
WARNING: running web tests without building webkit.
The webkit native library will be copied from the JDK,
which might lead to failures in some web tests.
To avoid these failures, you should either build
webkit locally, copy the native webkit library from a
recent build, or skip execution of web test cases with
'-x :web:test'
*
Exception in thread "JavaFX Application Thread"
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x7f4e01ae8a61, pid=78774, tid=78815
#
# JRE version: OpenJDK Runtime Environment (11.0.7+10) (build 11.0.7+10)
# Java VM: OpenJDK 64-Bit Server VM (11.0.7+10, mixed mode, tiered, compressed 
oops, g1 gc, linux-amd64)
# Problematic frame:
# V  [libjvm.so+0x579a61]  
AccessInternal::PostRuntimeDispatch,
(AccessInternal::BarrierType)2, 1097844ul>::oop_access_barrier(void*)+0x1 #
# Core dump will be written. Default location: Core dumps may be processed with 
"/usr/lib/systemd/systemd-coredump %P
%u %g %s %t %c %h" (or dumping to 
/opt/sources/github/jfx/modules/javafx.web/core.78774) #
# An error report file with more information is saved as:
# /opt/sources/github/jfx/modules/javafx.web/hs_err_pid78774.log
#
# If you would like to submit a bug report, please visit:
#   https://github.com/AdoptOpenJDK/openjdk-support/issues
#
`

-

PR: https://git.openjdk.java.net/jfx/pull/167

Re: RFR: 8129123: ComboBox popup list view does not scrollTo when ComboBox value/selection is set

[Craig Cavanaugh]

On Fri, 17 Apr 2020 10:42:30 GMT, Jeanette Winzenburg  
wrote:

> repeating my comment from the [previous pull 
> request](https://github.com/openjdk/jfx/pull/136#issuecomment-608401086):
> I don't think this is yet ready for a technical review - there are some more 
> basic questions that are not yet answered
> :)

> - is it really a bug or a nice-to-have enhancement? couldn't find an example 
> in win, didn't try too hard and nowadays,
>   such plain combos are not a really frequent
>  - while none of the virtualized controls (nor ChoiceBox) combines selection 
> with scrolling to the selected item. For
>combo and choice, I see no reason not make it the default behavior. We 
> need to make certain it behaves "naturally" when
>navigating in the open popup.
>  - instead of catching every list.select (and not forget the unselect) we 
> might consider doing it in a showing handler
>  - alternatively, we might consider to go deeper and support it directly in 
> the listView

- For me / my users / and the open bug, it is a bug due to the current behavior 
being unexpected.  It creates the
  illusion of a preselected value not actually being selected because it's not 
visible if the list is large and has been
  shown.  It creates doubt and the user has to scroll to reconfirm their 
selection which takes extra unnecessary effort
  and time.

- With my testing, for the ComboBox, behavior was smooth and natural.  I've not 
made any attempt to change selection with
  it shown and I'm not certain it can happen unless done programmatically.  
User selection within the list requires
  scrolling, so the selected value is already visible.

- I'm not opposed to taking this approach.  My current work around by extending 
ComboBox is based on scrolling when the
  value is set (restored) programmatically.  I could see how it may be more 
efficient if multiple selections were being
  performed programmatically, but not sure why someone would write code this 
way.  I would think it's a one shot process
  to select the final value.

- Implementing the change in ListView would not change/improve ChoiceBox simply 
because it does not use an underlying
  ListView.   My search on uses of ListView only reviled ComboBox other than 
itself.  Since ListView by itself is not
  collapsed/hidden for typical uses, would automatic scrolling within ListView 
create a confusing experience?

-

PR: https://git.openjdk.java.net/jfx/pull/166

Re: [Rev 01] RFR: 8198402: ToggleButton.setToggleGroup causes memory leak when button is removed via ToggleGroup.getToggles()

[Jesper Skov]

On Sat, 18 Apr 2020 16:04:34 GMT, Kevin Rushforth  wrote:

>> Jesper Skov has updated the pull request incrementally with three additional 
>> commits since the last revision:
>> 
>>  - Fail instead of print message
>>  - addedToggles list is final
>>  - Leave unrelated file alone
>
> The fix looks correct to me. Have you run all tests to ensure no regressions?
> 
> I left a couple inline comments.

@kevinrushforth I tested by:
`
bash ./gradlew clean all test -x :web:test
`
I assumed that would do it.
But I see use of ToggleButton in javafx.web, so that was clearly a faulty 
assumption.

I will try to get webkit working.

-

PR: https://git.openjdk.java.net/jfx/pull/167

Re: [Rev 01] RFR: 8198402: ToggleButton.setToggleGroup causes memory leak when button is removed via ToggleGroup.getToggles()

[Jesper Skov]

> Make the two ways of associating a ToggleButton with a ToggleGroup interact 
> correctly.
> 
> This fixes https://bugs.openjdk.java.net/browse/JDK-8198402

Jesper Skov has updated the pull request incrementally with three additional 
commits since the last revision:

 - Fail instead of print message
 - addedToggles list is final
 - Leave unrelated file alone

-

Changes:
  - all: https://git.openjdk.java.net/jfx/pull/167/files
  - new: https://git.openjdk.java.net/jfx/pull/167/files/1386ad74..10eef05b

Webrevs:
 - full: https://webrevs.openjdk.java.net/jfx/167/webrev.01
 - incr: https://webrevs.openjdk.java.net/jfx/167/webrev.00-01

  Stats: 5 lines in 3 files changed: 0 ins; 3 del; 2 mod
  Patch: https://git.openjdk.java.net/jfx/pull/167.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/167/head:pull/167

PR: https://git.openjdk.java.net/jfx/pull/167

Re: RFR: 8198402: ToggleButton.setToggleGroup causes memory leak when button is removed via ToggleGroup.getToggles()

[Jesper Skov]

On Sat, 18 Apr 2020 15:50:55 GMT, Kevin Rushforth  wrote:

>> Make the two ways of associating a ToggleButton with a ToggleGroup interact 
>> correctly.
>> 
>> This fixes https://bugs.openjdk.java.net/browse/JDK-8198402
>
> modules/javafx.controls/src/main/java/javafx/scene/control/ToggleButton.java 
> line 196:
> 
>> 195: private ObjectProperty toggleGroup;
>> 196: @Override
>> 197: public final void setToggleGroup(ToggleGroup value) {
> 
> This is unrelated to the fix. The changes in this file should be reverted.

OK.  They are gone.

Would this (keeping the changes very specific to the bug?) be worth mentioning 
in CONTRIBUTING.md?
That is, like the note about imports: do not fix warnings that are not directly 
related to the issue?

-

PR: https://git.openjdk.java.net/jfx/pull/167

RFR: 8242077: Add information about HTTP/2 and HttpClient usage in WebEngine

[Abhinay Agarwal]

Update WebEngine's Javadoc to add information on how it switches to HttpClient 
instead of URLConnection in JavaFX 14
when used with JDK 12 or later.

Identification the correct client is important as both these clients may offer 
different ways to achieve a task. One
such task can be bypassing insecure HTTPS connection.

-

Commit messages:
 - Remove trailing whitespace
 - 8242077: Add information about HTTP/2 and HttpClient usage in WebEngine

Changes: https://git.openjdk.java.net/jfx/pull/189/files
 Webrev: https://webrevs.openjdk.java.net/jfx/189/webrev.00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8242077
  Stats: 6 lines in 1 file changed: 6 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jfx/pull/189.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/189/head:pull/189

PR: https://git.openjdk.java.net/jfx/pull/189