Iris,
Did you consider to split version string into array of groups first
(using String.split()), then validate each group separately?
It may make the code better readable and more resilient to possible
future changes.
-Dmitry
On 2015-11-25 04:54, Iris Clark wrote:
> Hi.
>
> Please review the
Hi Iris,
Do you consider an option to let community reuse JDK versioning style for their
own purposes. Probably defining an interface with basic default methods which
can be extended by various libraries to provide unified way to gather version
information from MANIFEST.MF, ClassLoader's jars a
On 13/01/2016 21:54, Iris Clark wrote:
:
This diff has been applied to modules.xml:
This looks okay.
:
When this came up earlier, I filed this bug to track finding
a more appropriate module for jdk.Version:
8144062: Determine appropriate module for jdk.Version
https://bugs.openj
The "stopThread” RuntimePermission is granted by default. The Thread.stop
methods have been deprecated for more than 15 years. It seems reasonable,
in a major release, to remove the default grant of stopThread.
diff --git a/src/java.base/share/conf/security/java.policy
b/src/java.base/share/conf
On 14/01/2016 10:05, Chris Hegarty wrote:
The "stopThread” RuntimePermission is granted by default. The Thread.stop
methods have been deprecated for more than 15 years. It seems reasonable,
in a major release, to remove the default grant of stopThread.
This looks okay to me, we should have droppe
Hi Chris,
I would have expected some tests to need modifying here (or other places!).
David
On 14/01/2016 8:05 PM, Chris Hegarty wrote:
The "stopThread” RuntimePermission is granted by default. The Thread.stop
methods have been deprecated for more than 15 years. It seems reasonable,
in a major
On 14 Jan 2016, at 10:37, David Holmes wrote:
> Hi Chris,
>
> I would have expected some tests to need modifying here (or other places!).
I haven’t seen any test failures resulting from this change ( not sure
if that is a good or a bad thing! ). Though, there were several implementation
bugs t
Dear all,
please review this fix.
Bug: https://bugs.openjdk.java.net/browse/JDK-8147078
Webrev: http://cr.openjdk.java.net/~mhaupt/8147078/webrev.00
Unlike MethodHandles.throwException, MethodHandles.catchException does not
enforce that the passed exception type is indeed a subtype of Throwable.
+1
-Sundar
On 1/14/2016 4:52 PM, Michael Haupt wrote:
Dear all,
please review this fix.
Bug: https://bugs.openjdk.java.net/browse/JDK-8147078
Webrev: http://cr.openjdk.java.net/~mhaupt/8147078/webrev.00
Unlike MethodHandles.throwException, MethodHandles.catchException does not
enforce that t
On 2016-01-11 22:44, Iris Clark wrote:
Hi, Joe, Roger, Alan, Magnus, and Mandy.
At the end of December (shortly before the Christmas/Winter
break and my vacation), I provided responses to your messages
and an updated webrev:
http://cr.openjdk.java.net/~iris/verona/8072379/webrev.2/
I didn't
Hi all,
Please review the fix for bug: https://bugs.openjdk.java.net/browse/JDK-8144988
Webrev: http://cr.openjdk.java.net/~rpatil/8141243/webrev.00
This is basically a backport of JDK9 bug:
https://bugs.openjdk.java.net/browse/JDK-8141243
JDK9 changeset(for reference):
http://hg.openjdk.
> On 14 Jan 2016, at 12:22, Michael Haupt wrote:
>
> Dear all,
>
> please review this fix.
> Bug: https://bugs.openjdk.java.net/browse/JDK-8147078
> Webrev: http://cr.openjdk.java.net/~mhaupt/8147078/webrev.00
>
> Unlike MethodHandles.throwException, MethodHandles.catchException does not
> en
Looks good to me.
--Sean
On 01/14/2016 05:05 AM, Chris Hegarty wrote:
The "stopThread” RuntimePermission is granted by default. The Thread.stop
methods have been deprecated for more than 15 years. It seems reasonable,
in a major release, to remove the default grant of stopThread.
diff --git a/
On 2015-12-18 15:11, Wang Weijun wrote:
Hi Vinnie
I take a look and it includes a change for
src/jdk.crypto.mscapi/windows/native/libsunmscapi/security.cpp in the
Java_sun_security_mscapi_KeyStore_getKeyLength() function.
It seems there is no sun.security.mscapi.KeyStore#getKeyLength on the j
On 2016-01-05 03:25, Kim Barrett wrote:
On Dec 18, 2015, at 7:41 PM, Kim Barrett wrote:
On Dec 16, 2015, at 8:50 AM, Magnus Ihse Bursie
wrote:
Bug: https://bugs.openjdk.java.net/browse/JDK-8145549
WebRev:
http://cr.openjdk.java.net/~ihse/JDK-8145549-vs2015-community-edition/webrev.01
/Magn
Hi, Magnus.
Thanks for taking the time to look at this again.
> I noted that your java source file had a lot of initial tabs instead of
> spaces.
> I'm not sure if we have any code guidelines about this,
jcheck prevents tabs in comments and source. I remove them, one of my
editors adds them
> On Jan 13, 2016, at 9:27 PM, Iris Clark wrote:
>
> These are the diffs to address both of your comments:
>
> $ diff Version.java_save Version.java
> 28a29,30
>> import java.security.AccessController;
>> import java.security.PrivilegedAction;
> 154,155d155
> < * @see http://openjdk.java.net/
> On Jan 14, 2016, at 2:05 AM, Chris Hegarty wrote:
>
> The "stopThread” RuntimePermission is granted by default. The Thread.stop
> methods have been deprecated for more than 15 years. It seems reasonable,
> in a major release, to remove the default grant of stopThread.
+1 to remove "stopThread
On 14 Jan 2016, at 16:52, Mandy Chung wrote:
>> On Jan 14, 2016, at 2:05 AM, Chris Hegarty wrote:
>>
>> The "stopThread” RuntimePermission is granted by default. The Thread.stop
>> methods have been deprecated for more than 15 years. It seems reasonable,
>> in a major release, to remove the def
> On Jan 14, 2016, at 9:19 AM, Chris Hegarty wrote:
>
>> There are existing tests whose grants this "stopThread” RuntimePermission
>> that may not be needed for the test. The test policy likely copies that
>> from the default system java.policy. We should update these test policy as
>> well
On 14 Jan 2016, at 17:29, Mandy Chung wrote:
>
>> On Jan 14, 2016, at 9:19 AM, Chris Hegarty wrote:
>>
>>> There are existing tests whose grants this "stopThread” RuntimePermission
>>> that may not be needed for the test. The test policy likely copies that
>>> from the default system java.
The process grim reaper ends up being the first point of failure since
it tries not to waste the user's memory and it's in a core library,
but in principle it's not special. I think a more general workaround
would be to add a hotspot flag that would add a memory safety zone to
all threads. If it'
Thanks for the feedback.
Investigating the regression failure.
We'll get back as soon as we figure this out. (and yes, we'll run this through
some localized Windows VMs)
Cheers
-Original Message-
From: Kumar Srinivasan [mailto:kumar.x.sriniva...@oracle.com]
Sent: Tuesday, January 12
sun.misc.ClassFileTransformer has not been used since its hooks were
removed in JDK 8, see 8009645 [1]. It is now time to remove the class
itself.
hg rm src/java.base/share/classes/sun/misc/ClassFileTransformer.java
-Chris.
[1] https://bugs.openjdk.java.net/browse/JDK-8009645
> On Jan 14, 2016, at 11:53 AM, Chris Hegarty wrote:
>
> sun.misc.ClassFileTransformer has not been used since its hooks were
> removed in JDK 8, see 8009645 [1]. It is now time to remove the class
> itself.
>
> hg rm src/java.base/share/classes/sun/misc/ClassFileTransformer.java
+1
Mandy
On 14/01/2016 19:53, Chris Hegarty wrote:
sun.misc.ClassFileTransformer has not been used since its hooks were
removed in JDK 8, see 8009645 [1]. It is now time to remove the class
itself.
hg rm src/java.base/share/classes/sun/misc/ClassFileTransformer.java
Got for it. If you look at the histo
Looks good to me.
Naoto
On 1/14/16 4:21 AM, Ramanand Patil wrote:
Hi all,
Please review the fix for bug: https://bugs.openjdk.java.net/browse/JDK-8144988
Webrev: http://cr.openjdk.java.net/~rpatil/8141243/webrev.00
This is basically a backport of JDK9 bug:
https://bugs.openjdk.java.net/brow
> On Jan 14, 2016, at 11:00 PM, Magnus Ihse Bursie
> wrote:
>
> On 2015-12-18 15:11, Wang Weijun wrote:
>> Hi Vinnie
>>
>> I take a look and it includes a change for
>> src/jdk.crypto.mscapi/windows/native/libsunmscapi/security.cpp in the
>> Java_sun_security_mscapi_KeyStore_getKeyLength() f
On 15/01/2016 4:59 AM, Martin Buchholz wrote:
The process grim reaper ends up being the first point of failure since
it tries not to waste the user's memory and it's in a core library,
but in principle it's not special. I think a more general workaround
would be to add a hotspot flag that would
Hi Ramanand,
test/java/text/Format/DateFormat/Bug8141243.java:
28 * @run main Bug8141243
29 * @run main/othervm -Djava.locale.providers=COMPAT Bug8141243
"COMPAT" is a new name of "JRE" in JDK 9. It's not supported in 8u. I
think COMPAT is slightly ignored and that it becomes the same th
Hello!
Current documentation for BaseStream.onClose() does not specify
explicitly how the stream would behave if additional close handlers
are registered after the stream is consumed or even closed. The
implementation actually allows registering the additional close
handlers after consumption or c
31 matches
Mail list logo
