[12] Review request: 8209791 : OpenJFX build fails in PrismPrint.c due to missing JNICALL

[Priyanka Mangal]

Hi,

Please review this fix :
Webrev : http://cr.openjdk.java.net/~dkumar/primanga/8209791/webrev.00/
JBS : https://bugs.openjdk.java.net/browse/JDK-8209791

Thanks,
Priyanka

JI-9056801 : Scene: Allow to add a stylesheet using a typed URL, not a stringified URL

[Michael Binz]

Hi all,

I opened a proposal for an extension of the javafx.scene.Scene API to allow
to add a stylesheet using a typed java.net.URL.

Currently the Scene class offers a list of stylesheet URLs in their
stringified representation accessible by Scene.getStylesheets().

The problem is that in some cases an URL instance encapsulates internal
state that gets lost in the conversion into its external form and back into
an URL instance, namely information on an URL handler. This ultimately
results in a failure (IOException file not found) when the Screen class
tries to load a stylesheet though code that loads the file contents using
URL#openStream() on the original URL instance can read the file contents
successfully.

In my case the problem showed up when creating an executable jar file
containing my JavaFX application (using OneJar).  The application startup
in this case installs a customized Classloader that implements special
logic for accessing the jars contained classes,  This works transparently
for classes and resources, but the URLs returned by Class#getResource( name
) do not survive the conversion to string and back because of the described
reason.

There is a workaround that caches the resource in a temporary file and
passes this file's URL to the Scene's list of stylesheets, but this poses
other problems.
As a remark, other APIs in JavaFX use the same pattern of expecting
stringified URLs like the Image() constructor and have the same problem,
but offer alternative constructors accepting a stream which allows to solve
the problem nicely.

Please discuss and decide if the proposal can be added as a change request
for JavaFX.

Best wishes,
Michael.

Re: JavaFX 11 maven snapshots - empty jars

[Lennart Börjeson]

Sound reasonable, thank you.

In the meantime (waiting for the next version of the maven artefacts) I've 
updated my PR (https://github.com/johanvos/javafx11samples/pull/1 
) for your javafx11samples 
with a build.gradle work-around to filter out the empty javafx-jars.

This makes your samples run with Java 11, gradle 4.9 and openjdx 11-ea+19.

/Lennart

> 22 aug. 2018 kl. 14:11 skrev Johan Vos :
> 
> I spent some more time on this.
> Adding the Automatic-Module-Name seems the easiest fix to me. I created a PR 
> at https://github.com/javafxports/openjdk-jfx/pull/162 
>  for this.
> 
> Having the platform-name hardcoded in the artifact Id would require upfront 
> magic in build.gradle or pom.xml to prevent the need to put a platform 
> hardcoded in the build.gradle or pom.xml.
> Removing the empty jars never gives a result that works fine for both maven 
> and gradle, see 
> https://github.com/javafxports/openjdk-jfx/pull/83#issuecomment-404828804 
> 
> 
> In the end, the real fix for this should be in maven/gradle. We currently 
> need to specify dependencies in both the module-info.java as well as in the 
> pom.xml. That doesn't sound right. I would assume that the gradle Java plugin 
> should check if a dependency contains a module-info.class, and if so, parse 
> it and process it.
> 
> - Johan
> 
> 
> 
> On Thu, Aug 16, 2018 at 11:26 AM Lennart Börjeson  > wrote:
> FWIW, I've fixed the Gradle builds in the current javafx11samples and sent 
> you a pull request.
> 
> I know these samples are only temporary, but I believe I'm not the only 
> gradle user who's been frustrated by not having any working example to try 
> out.
> 
> My fix still uses the 11.0.0-SNAPSHOT builds and sets the classifier in the 
> dependencies using Gradle's OPeratingSystem class.
> 
> 
> 
> Best regards,
> 
> /Lennart
> 
> 

Re: JavaFX 11 maven snapshots - empty jars

[Johan Vos]

I spent some more time on this.
Adding the Automatic-Module-Name seems the easiest fix to me. I created a
PR at https://github.com/javafxports/openjdk-jfx/pull/162 for this.

Having the platform-name hardcoded in the artifact Id would require upfront
magic in build.gradle or pom.xml to prevent the need to put a platform
hardcoded in the build.gradle or pom.xml.
Removing the empty jars never gives a result that works fine for both maven
and gradle, see
https://github.com/javafxports/openjdk-jfx/pull/83#issuecomment-404828804

In the end, the real fix for this should be in maven/gradle. We currently
need to specify dependencies in both the module-info.java as well as in the
pom.xml. That doesn't sound right. I would assume that the gradle Java
plugin should check if a dependency contains a module-info.class, and if
so, parse it and process it.

- Johan



On Thu, Aug 16, 2018 at 11:26 AM Lennart Börjeson 
wrote:

> FWIW, I've fixed the Gradle builds in the current javafx11samples and sent
> you a pull request.
>
> I know these samples are only temporary, but I believe I'm not the only
> gradle user who's been frustrated by not having any working example to try
> out.
>
> My fix still uses the 11.0.0-SNAPSHOT builds and sets the classifier in
> the dependencies using Gradle's OPeratingSystem class.
>
>
>
> Best regards,
>
> /Lennart
>
>
>