looks good to me. Dont we need to add this bugid to the tests?
Regards
Prasanta
On 11/28/2017 7:57 AM, Sergey Bylokhov wrote:
Hello.
Please review the fix for jdk10. This is the second attempt to move
windows L&F from non-windows platforms. The first attempt
JDK-6461834[1] was reverted because
Some more specifics - these lines in the makefiles
(CompileJavaModules.gmk) are used to workaround the layout oddities:
ifeq ($(MODULE), jdk.internal.vm.ci)
## WORKAROUND jdk.internal.vm.ci source structure issue
JVMCI_MODULESOURCEPATH := $(MODULESOURCEPATH) \
$(subst /$(MODULE)/,/*/,
Hi,
Further to below email thread -
https://bugs.openjdk.java.net/browse/JDK-8187676
https://bugs.openjdk.java.net/browse/JDK-8160404
Please note 8187676 task was blocked by related 8160404.
But as mentioned in latest jbs comments of 8160404,
found the build warning with gcc7 persists with late
On 28/11/2017 01:50, mandy chung wrote:
This is a follow-up on JDK-8189611 that defines a new public API to
return a stream of versioned entries and to return the real name of a
JAR entry. JDK-8189611 leaves jdeps untouched because jdeps is
compiled with the boot JDK.
This patch includes:
(1
Magnus:
Looks good to me as well.
/Tim
On 11/27/17 15:44, Erik Joelsson wrote:
Looks good.
/Erik
On 2017-11-27 15:11, Magnus Ihse Bursie wrote:
From the bug report:
A common scenario is adding vm arguments when running tests. While
this can be accomplished by JTREG="VM_OPTIONS=-Xfoo", thi
Build change looks good.
/Erik
On 2017-11-27 17:50, mandy chung wrote:
This is a follow-up on JDK-8189611 that defines a new public API to
return a stream of versioned entries and to return the real name of a
JAR entry. JDK-8189611 leaves jdeps untouched because jdeps is
compiled with the bo
From a build point of view, this looks great.
/Erik
On 2017-11-27 18:27, Sergey Bylokhov wrote:
Hello.
Please review the fix for jdk10. This is the second attempt to move
windows L&F from non-windows platforms. The first attempt
JDK-6461834[1] was reverted because of JDK-8184813[2].
The root
These modules are certainly an annoyance in the build. Please file a bug
with this concern.
/Erik
On 2017-11-28 03:16, Maurizio Cimadamore wrote:
Some more specifics - these lines in the makefiles
(CompileJavaModules.gmk) are used to workaround the layout oddities:
ifeq ($(MODULE), jdk.inte
I see this opens was moved to platform-specific code ... 115 opens
com.sun.java.swing.plaf.windows to
116 jdk.jconsole;
So jdk.jconsole definitely accesses this only on Windows ?
-phil.
On 11/28/2017 09:28 AM, Erik Joelsson wrote:
From a build point of view, this looks great.
/Erik
On 2017
Every jtreg run would like to have the most helpful failure handling
possible. Should some/all of this be pushed into jtreg itself instead of
the makefiles?
On Mon, Nov 27, 2017 at 1:39 PM, Magnus Ihse Bursie <
magnus.ihse.bur...@oracle.com> wrote:
> The jtreg failure handler needs to be used wh
On 28/11/2017 13:38, Phil Race wrote:
I see this opens was moved to platform-specific code ... 115 opens
com.sun.java.swing.plaf.windows to
116 jdk.jconsole;
So jdk.jconsole definitely accesses this only on Windows ?
Its is accessed under the windows check:
http://hg.openjdk.java.net/jdk/clie
jconsole checks if it uses windows LAF (
com.sun.java.swing.plaf.windows.WindowsLookAndFeel class. And also
reflectively access the fields in
com.sun.java.swing.plaf.windows.TMSchema$Part to workaround some issue.
Mandy
On 11/28/17 1:38 PM, Phil Race wrote:
I see this opens was moved to plat
Catching up after mini-vacation ...
On 23/11/2017 2:47 AM, Christian Tornqvist wrote:
Please review this small change that allows a user to scale up or down the
concurrency for running Hotspot jtreg tests using CONCURRENCY_FACTOR.
Webrev: http://cr.openjdk.java.net/~ctornqvi/webrev/8191768/web
13 matches
Mail list logo
