>We are looking at the possibility of providing a replacement packaging
tool in OpenJDK.
+1 for this. Or something like a Maven Shade build with an exacting set of
dependency exclusions, and Launch4J would accomplish something similar? Has
the advantage that all the other plugins like resources,
On 05/16/2018 02:04 PM, Kevin Rushforth wrote:
On 5/16/2018 10:49 AM, Ty Young wrote:
That one, as mentioned in the wiki build guide. I get an immediate
build fail(see: https://pastebin.com/geR4LLMm). The JDK works just
fine: I can set it as the default JDK, run Netbeans, set the project
Hi all,
we have some customers in the wild who use Matrox 9148LP (9100 series)
graphics cards because they drive more than 2 monitors and JavaFX always
reports an error initializing HW pipeline and forcing gpu results in system
instability.
I checked the bug reports but couldn't see anything abou
Hi Matthew,
Is there a way to get more details on why JavaFx fails to enable the D3D
> pipeline?
Add the VM argument -Dprism.verbose=true and post what it spits.
- Nir
On Thu, May 17, 2018 at 5:04 PM, Matthew Elliot <
matthew.james.ell...@gmail.com> wrote:
> Hi all,
>
> we have some customers
Hi Matthew,
Please see the below file for blaclisted hardware on D3D.
http://hg.openjdk.java.net/openjfx/jfx-dev/rt/file/9e0e0e65e642/modules/javafx.graphics/src/main/native-prism-d3d/D3DBadHardware.h
Regards,
Anirvan
On Thu, 17 May 2018 at 11:04 PM, Matthew Elliot <
matthew.james.ell...@gmail
Hi Nir,
Regarding “com.sun.javafx.webkit.drt.DumpRenderTree”, you can comment out the
below code in “main” method from DumpRenderTree.java file.
if ( isDebug() ) {
log.setLevel(Level.FINEST);
FileHandler handler = new FileHandler("drt.log", true);
Note: This is different from what is discussed in
http://mail.openjdk.java.net/pipermail/openjfx-dev/2018-April/021762.html
The following text is about bundling native code within a jar, and doesn't
talk about how to deal with platform-specific libraries in generic jar
files.
At this moment, the
Hey, thanks for the second link, exactly what I needed just not the best news.
I see all Matrox cards are disabled which is a bit tricky for us when many of
our customers are have 4+ monitors and some have chosen those cards.
I then managed to find this - https://bugs.openjdk.java.net/browse/J
Did you check how SWT does addresses the problem? If you run it outside of OSGi
it needs to deal with this problem as well.
Tom
Von meinem iPhone gesendet
> Am 17.05.2018 um 21:25 schrieb Johan Vos :
>
> Note: This is different from what is discussed in
> http://mail.openjdk.java.net/pipermail
To answer my own question the trick swt uses is to encode the build-id into the
dll/so so it never needs to delete a file
See
http://git.eclipse.org/c/platform/eclipse.platform.swt.git/tree/bundles/org.eclipse.swt/Eclipse%20SWT%20PI/common/org/eclipse/swt/internal/Library.java#n144
Tom
Von mei
Thanks Murali, Iv'e also commented out isDebug() (though maybe it can be
completely removed, only that the commented out code relies on it).
Kevin, after this change, HelloService in the packager is the only one
requiring file handling. What is the future of the packager now? Is it
worth supplying
I think it isn't worth doing anything for the packager. In any case,
since "HelloService" is a test program, I see no problem with it
continuing to use java.util.logging.
Regarding your other comment:
Thanks Murali, Iv'e also commented out isDebug() (though maybe it can
be completely removed,
>
> There was one other place where isDebug() was called, that being the mLog
> method. Did you replace the call ti isDebug() with a direct call to
> isLoggable instead?
>
Yes, I should have been clearer: I inlined `isDebug` into `mLog`, then
commented out `isDebug` so that if someone reads the co
On 5/17/2018 3:16 AM, Ty Young wrote:
And could the new standalone modules be integrated with the source
code somehow so that a JDK without JavaFX support can be compiled?
Not sure what you mean, but you can use an OpenJDK without modules
+ the JavaFX standalone modules to build and run you
That all sounds good.
As for the packager, it will likely continue to be a source of issues
like this now that it is gone from the JDK, and isn't part of the
unbundled FX builds.
I just filed a bug [1] to remove the qualified export from
javafx.graphics to jdk.packager (and to disable buildi
15 matches
Mail list logo
