[9]: : [packager] Module Path Packager Arguments

2016-04-11 Thread Chris Bensen
Kevin, Please review. This adds new argument to Java Packager, the Minesweeper FX Appstore App and cleans a lot of things up. My Packager sandbox will be in sync with 9dev except for refactoring changes. https://bugs.openjdk.java.net/browse/JDK-8150991

9-dev unlocked following sanity testing

2016-04-11 Thread Kevin Rushforth

Re: status behind JDK-8149738

2016-04-11 Thread Matthieu BROUILLARD
Kevin, Vadim, thanks for the quick reply. I tested with 1.8.0_102-ea-b01 (32 bits) and it still fails. @Kevin what kind of report would you like me to generate? how to obtain the native stack trace? I tried to set `-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=SOME_PATH` but the crash does

Re: status behind JDK-8149738

2016-04-11 Thread Kevin Rushforth
> is "writing address 0xbbadbeef". So they are not the same. Good catch, Vadim. This is likely an OOM or some other internal failure. That is the tell-tale sign of a call to the internal abort . The fact that this works with 64-bit and fails with 32-bit suggests an OOM problem. -- Kevin

Re: status behind JDK-8149738

2016-04-11 Thread Vadim Pakhnushev
Matthieu, It's unlikely that your problem is the same as in the JDK-8149738. You see, your crash is due to "reading address 0x002e0060" and in the JDK-8149738 it's "writing address 0xbbadbeef". So they are not the same. Vadim On 11.04.2016 19:39, Matthieu BROUILLARD wrote: Hi all, In our

Re: status behind JDK-8149738

2016-04-11 Thread Kevin Rushforth
Without a native stack trace it will be hard to say whether this is the same bug or not. Several fixes for other crashes (not specifically JDK-8149738) have recently gone into 8-dev for 8u102. An early access build of 8u102-b01 with some of these fixes is available here:

status behind JDK-8149738

2016-04-11 Thread Matthieu BROUILLARD
Hi all, In our application that integrates some webapps we are facing quite the same error than the one reported at https://bugs.openjdk.java.net/browse/JDK-8149738. The issue above has been marked with 'bugdb_22696741' ; does it mean it is referenced with more details elsewhere? Is there a known

[9] Review request for 8150181: javafx print jobs take 60 times longer than javax.print

2016-04-11 Thread mikhail cherkasov
Hi all, Could you please review the fix for: https://bugs.openjdk.java.net/browse/JDK-8150181 webrev: http://cr.openjdk.java.net/~mcherkas/8150181/webrev.02/ Javafx print is slow because after sending node for printing we wait 1 sec before checking that page was done, see implPrintPage method:

Re: RFR: JDK-8075550 - Error "JavaFX runtime not found" in nashorn when load predefines scripts to import JavaFX packages

2016-04-11 Thread Sundararajan Athijegannathan
+1 On 4/11/2016 6:13 PM, Jim Laskey (Oracle) wrote: > Any one else. > >> On Apr 11, 2016, at 9:13 AM, Michael Haupt wrote: >> >> Hi Jim, >> >> lower-case thumbs up! >> >> Best, >> >> Michael >> >>> Am 08.04.2016 um 19:05 schrieb Jim Laskey (Oracle)

Re: RFR: JDK-8075550 - Error "JavaFX runtime not found" in nashorn when load predefines scripts to import JavaFX packages

2016-04-11 Thread Jim Laskey (Oracle)
Thank you. > On Apr 11, 2016, at 9:52 AM, Sundararajan Athijegannathan > wrote: > > +1 > > On 4/11/2016 6:13 PM, Jim Laskey (Oracle) wrote: >> Any one else. >> >>> On Apr 11, 2016, at 9:13 AM, Michael Haupt wrote: >>> >>>

Re: RFR: JDK-8075550 - Error "JavaFX runtime not found" in nashorn when load predefines scripts to import JavaFX packages

2016-04-11 Thread Michael Haupt
Hi Jim, lower-case thumbs up! Best, Michael > Am 08.04.2016 um 19:05 schrieb Jim Laskey (Oracle) : > > The code was reworked to use jrtfs: instead of reading from javafx.jar. > > http://cr.openjdk.java.net/~jlaskey/8075550/webrev/index.html >