Hi Nadeesh,
I cannot say for sure does tck tests have same issue or not because now
they broken and failing as with limited JRE as well with full JDK. To
make sure if we have same issue with tck tests we need to fix them
first. I can take a look at the problem in separate CR. An example of
fa
Hi Sergei,
Though I am not a reviewer, But I have one comment on this fix.
test/java/time/TEST.properties declares "modules = jdk.localedata" , so
that all tests for java.time can have access to "jdk.localedata" module.
If we are restricting usage of jdk.localedata module for different
tests
Hi,
since java.util.concurrent.AtomicReference was changed to use a
VarHandle internally, using it from within the security libraries can
lead to hard to diagnose bootstrap cycles (since VarHandles has to do
doPrivileged calls during setup). The need to initialize VarHandles is
also cause for a s
Hi Jason,
At the moment, a subclass would need to overwrite this method with the
same behaviour. The other solution would be to make the internal state
auto-flush to no longer be final.
-Patrick
On 2016-12-21 22:40, Jason Mehrens wrote:
Patrick,
How is 'withAutoFlush' expected to behave fo
You should add a subclass test to prove that it works in practice. If the
subclasses are required to override the method then shouldn't the
'withAutoFlush' method check that getClass() == PrintWriter.class otherwise
throw something like UnsupportedOperationException?
Jason
___
Hi,
can I please have a review and approval for pushing the following
small, ppc64-only fix to jdk8u-dev:
http://cr.openjdk.java.net/~simonis/webrevs/2016/8172053/
https://bugs.openjdk.java.net/browse/JDK-8172053
The problem is that the recent downport of "8170153:
PPC64/s390x/aarch64: Poor Str
Hi Volker,
As this is a build change I have added build-dev.
The change looks fine to me.
Aside: More generally it would be nice if there was a simple way to
record minimum compiler versions necessary for a given flag/option.
Thanks,
David
On 28/12/2016 3:17 AM, Volker Simonis wrote:
Hi,
Hi Claes,
A nice find! This is certainly a straightforward and low-risk fix for
breaking the initialization cycle problem with JDK-8062389.
Related to VarHandles, the call trace of the initialization cycle also
includes the following part of code in VarHandle:
AccessMode(final Stri
Hi all
I tried to run jvisualvm in Linux with both b147 and b150(by adding add-opens
option), it always quit quietly after showing a splash
screen. Does it still work?
Thanks
Frank
