Hi Valerie,
many thanks for the thorough review. I've taken all your feedback on
board with the latest push. Some of the test anomalies were a result of
previous iterations of test edits I had been making.
Regarding the extra edits in
"src/java.base/share/lib/security/default.policy", I had
Thank for the feedback Peter. Comments inline.
On 22/06/2021 22:40, Peter Firmstone wrote:
Was ever to run with SecurityManager?
I found the issue while porting to jdk8u where Solaris uses a
configuration file with the SunPKCS11 Provider by default - We have
tests to register Providers while
.
JavaUtilZipFileAccess.java #44: Change posixPerms to extraAttrs.
ZipFile.java #661: Suggest to keep the comment and update it with the
additional 4 bits for symlink.
The rest of code changes and CSR look good.
Thanks,
Hai-May
On Aug 28, 2020, at 7:17 AM, Seán Coffey <mailto:sean.cof...@oracle.
;= 6G)
Regards,
Fernando
On 1 Sep 2020, at 17:25, Seán Coffey <mailto:sean.cof...@oracle.com>> wrote:
Wouldn't you require the sun.arch.data.model == "64" jtreg config in
these tests also ?
regards,
Sean.
On 28/08/2020 19:13, Fernando Guallini wrote:
Hi,
May
Wouldn't you require the sun.arch.data.model == "64" jtreg config in
these tests also ?
regards,
Sean.
On 28/08/2020 19:13, Fernando Guallini wrote:
Hi,
May I please get reviews and a sponsor for this trivial change:
webrev: http://cr.openjdk.java.net/~fguallini/8249694/webrev.00/
28, 2020, at 10:17 AM, Seán Coffey wrote:
I've been poking around the zip internals and am now able to locate the 16 bits
of interest. The position of these actual bits does appear to move around from
one test run to another. For now, I guess it's sufficient to look for the
pattern of inter
Apologies. Meant to reply yesterday. Your edit looks fine to me.
regards,
Sean.
On 27/08/2020 16:41, Fernando Guallini wrote:
Thanks Sean, updated webrev here:
http://cr.openjdk.java.net/~fguallini/8249699/webrev.01/
Regards,
Fernando
- Original Message -
From: sean.cof...@oracle.com
I've been poking around the zip internals and am now able to locate the
16 bits of interest. The position of these actual bits does appear to
move around from one test run to another. For now, I guess it's
sufficient to look for the pattern of interest in the signed zip file.
New testcase
conscious design decision to only allow recording of
POSIX permission bits for this field (& 0xFFF). I don't see anything
about symlink support in zipfs docs.
regards,
Sean.
No other comment.
Thanks,
Max
On Aug 27, 2020, at 3:26 AM, Seán Coffey wrote:
updated webrev:
http://cr.op
updated webrev:
http://cr.openjdk.java.net/~coffeys/webrev.8250968.v2/webrev/
regards,
Sean.
On 27/08/2020 07:42, Seán Coffey wrote:
Hi Max,
I looked at updating the warning string but figured that it might have
been of no interest to end users. How about this edit
5, Weijun Wang wrote:
Are you going to update the warning text or create a new one?
Thanks,
Max
On Aug 26, 2020, at 2:26 PM, Seán Coffey wrote:
This is a follow on from the recent 8218021 fix. The jarsigner tool removes
symlink attribute data from zipfiles when signing them. jarsigner should
p
test/jdk/java/util/Base64/TestEncodingDecodingLength.java is an example
of another test using -Xmx8g. Do you want to push the os.maxMemory
requirement up to 10g perhaps ? It might avoid border line resource
failures. Also I think it might need a "sun.arch.data.model == "64" "
requirement :
This is a follow on from the recent 8218021 fix. The jarsigner tool
removes symlink attribute data from zipfiles when signing them.
jarsigner should preserve this data. The fix involves preserving the 16
bits associated with the file attributes (instead of the current 12).
That's done in
Looks fine to me Evan.
regards,
Sean.
On 17/08/2020 16:25, Evan Whelan wrote:
Hi all,
This is a small fix that helps with some test cleanup. One redundant test file
has been removed.
Webrev found at: http://cr.openjdk.java.net/~kravikumar/8249691/webrev/
Link to JBS issue:
ected. These attributes are ignored
when signing and are not protected by the signature."
regards,
Sean.
On 02/07/2020 08:59, Alan Bateman wrote:
On 30/06/2020 14:51, Seán Coffey wrote:
:
During the CSR review, a suggestion was made to have jarsigner
preserve such attributes by default. Warn
t\\.report\\(.*,\"(.*?)\",");
If you agree to add a whitespace in the calls in OSCP.java and DistributionFetcher.java, you might want to add a whitespace (or "\s*") here as well.
Thanks,
Max
On Jun 30, 2020, at 9:51 PM, Seán Coffey wrote:
Thanks Lance.
During the
/
regards,
Sean.
On 22/06/2020 17:17, Lance Andersen wrote:
HI Sean,
Looks OK based on our exchanges. Thank you for your time on this one!
Best
Lance
On Jun 22, 2020, at 7:22 AM, Seán Coffey <mailto:sean.cof...@oracle.com>> wrote:
Thanks Lance.
I've updated the patch with some extr
://cr.openjdk.java.net/~coffeys/webrev.8218021.v3/webrev/
regards,
Sean.
On 12/06/2020 17:05, Lance Andersen wrote:
Hi Sean,
I think your changes look fine so all good FMPOV.
Best
Lance
On Jun 12, 2020, at 6:21 AM, Seán Coffey <mailto:sean.cof...@oracle.com>> wrote:
Hi,
I'd like to reboot this
Hi,
I'd like to reboot this jarsigner enhancement request[1]. I've removed
the problem references to zip file name extensions. Instead, there's a
new JDK implementation specific jarsigner option: -keepposixperms
https://bugs.openjdk.java.net/browse/JDK-8218021
I've also created JDK-8238688 to track the specification clarification
request. I'll start an RFR for that shortly.
Regards,
Sean.
On 07/02/20 14:23, Seán Coffey wrote:
I've introduced such a class: FactoryInitializationError
Also added a new simple testcase method check for case where
I've introduced such a class: FactoryInitializationError
Also added a new simple testcase method check for case where this new
exception would be exercised : testBadContextCall(Hashtable)
http://cr.openjdk.java.net/~coffeys/webrev.8223260.v4/webrev/
On 6 February 2020 21:13:52 GMT, Peter Levart wrote:
>
>
>On 2/6/20 6:54 PM, Seán Coffey wrote:
>> the current proposal is still:
>> http://cr.openjdk.java.net/~coffeys/webrev.8223260.v2/webrev/
>
>But wasn't this one already better:
>
>https://cr.openjdk.ja
the current proposal is still:
http://cr.openjdk.java.net/~coffeys/webrev.8223260.v2/webrev/
I'd like to make the specification change in a follow on bug ID (if that
works for people)
Regards,
Sean.
On 06/02/20 17:49, Alan Bateman wrote:
On 06/02/2020 15:32, Seán Coffey wrote
On 05/02/20 16:51, Daniel Fuchs wrote:
On 05/02/2020 15:31, Peter Levart wrote:
I think this is about allow the InitialContextFactory instance to be
GC'ed when the thread is long lived. It might not be a concern for
the LDAP or the other providers in the JDK.
-Alan
Ah, I see. You mean
lso - I'm hoping to port this to JDK 11u also so I might spin the
specification changes into a different bug ID.
regards,
Sean.
On 03/02/2020 09:05, Peter Levart wrote:
Hi Seán,
On 2/1/20 12:22 AM, Seán Coffey wrote:
The following is also possible:
// 1st try find
Peter,
thanks again for your review. comments inline..
On 31/01/2020 17:16, Peter Levart wrote:
Hi Seán,
On 1/31/20 2:16 PM, Seán Coffey wrote:
Thanks for the review Peter. All good points! My latest patch
contains adjustments based on feedback from you and others to date.
* Incorporate
our
purpose.
Regards, Peter
On 1/29/20 6:22 PM, Seán Coffey wrote:
Thanks for the reviews. I found an issue with the new test also -
it's loading the custom factory class via the non-serviceloader
approach. I was hoping to exercise ServiceLoader here. I'll address
this and the comments rai
Thanks for the reviews. I found an issue with the new test also -
it's loading the custom factory class via the non-serviceloader
approach. I was hoping to exercise ServiceLoader here. I'll address this
and the comments raised and revert with a new patch shortly.
Regards,
Sean.
On 29/01/20
Looks like we can improve performance in this area. I've put together a
testcase which exercises the ServiceLoader and keeps track of whether
we're able to cache or not.
https://bugs.openjdk.java.net/browse/JDK-8223260
http://cr.openjdk.java.net/~coffeys/webrev.8223260.v1/webrev/
regards,
tools docs
accordingly.
Let me have a think about this. A new flag in jarsigner may help.
regards,
Sean.
Regards,
Philipp
On Fri, 2020-01-17 at 13:07 +, Seán Coffey wrote:
Hi Philipp,
On 17/01/2020 12:40, Philipp Kunz wrote:
Hi Sean,
Nice patch. I wonder why permissions should be preserv
Looks good to me Claes - thanks for fixing.
Regards,
Sean.
On 20/01/20 12:15, Claes Redestad wrote:
Makes sense to keep even trivial logic out of the access bridge. Let's
also clean up the placement of the static variable and the pre-existing
use of the unconventional "final static" combo:
d the test would not have to check that files with another name
extension than zip don't preserve permissions.
Philipp
On Fri, 2020-01-17 at 10:59 +0000, Seán Coffey wrote:
Hi,
Looking to introduce some JDK private functionality which will help
preserve internal zip file attribute permis
Hi,
Looking to introduce some JDK private functionality which will help
preserve internal zip file attribute permissions when jarsigner is run
on a zip file. Some of the logic is taken from the recent work carried
out in this area for zipfs API.
Thanks Alan. Updates made and changes pushed.
regards,
Sean.
On 13/01/2020 18:50, Alan Bateman wrote:
On 13/01/2020 10:28, Seán Coffey wrote:
some off line comments suggested that I could move the jar
initialization checks to the EventHelper class. With that in place,
the EventHelper utility
Thanks for the reviews. All callers of EventHelper log methods are
ensuring that isLoggingSecurity() is true before proceeding. I've added
an assert null check in the 4 logger methods to ensure expectations are
in place.
http://cr.openjdk.java.net/~coffeys/webrev.8234466.v5/webrev/
Hope this
/webrev/
regards,
Sean.
On 16/12/2019 14:15, Seán Coffey wrote:
The recent crypto event logging mechanism (JDK-8148188) has introduced
a regression whereby the System Logger may be invoked too early in the
bootstrap phase. This causes issue when JarFile objects are locked by
JarFile verifier
The recent crypto event logging mechanism (JDK-8148188) has introduced a
regression whereby the System Logger may be invoked too early in the
bootstrap phase. This causes issue when JarFile objects are locked by
JarFile verifier initialization code. The logging work records an X509
Certificate
Looks fine to me. I can push this for you.
Regards,
Sean.
On 04/11/19 10:04, Kiran Ravikumar wrote:
Hi,
Please review this patch to update the joni version to 2.1.16.
JBS: https://bugs.openjdk.java.net/browse/JDK-8232984
License File: https://github.com/jruby/joni/blob/joni-2.1.16/LICENSE
Quite a while since I touched this one! The nature of the test is a bit
flaky given
that we're assuming no other process will use the chosen port. I'm not sure
if a concrete solution is possible. One other option is to have this
test run
in non-concurrent mode by editing test/jdk/TEST.ROOT -->
Looks good Kiran. I'll sponsor this for you.
regards,
Sean.
On 08/10/2019 17:17, Kiran Ravikumar wrote:
Hi Guys,
I am a new hire with the Oracle Java Platform Group and will be
working mainly on JDK Update releases. Below is my first contribution.
Looking forward to contribute more to the
A minor issue that was introduced via my recent JDK-8223490 fix. One
which I noticed while backporting the edits..
https://bugs.openjdk.java.net/browse/JDK-8231124
proposed patch:
diff --git a/src/java.base/unix/native/libjava/TimeZone_md.c
b/src/java.base/unix/native/libjava/TimeZone_md.c
'\t') p++;
#define RESTARTABLE(_cmd, _result) do { \
Regards,
Sean.
On 13/09/19 13:01, Roger Riggs wrote:
Hi Sean,
The declaration can be up in the _md.c file to satify the compiler
about forward declarations.
$.02, Roger
On 9/13/19 4:34 AM, Seán Coffey wrote:
Thanks for the review Roger.
pathname" is an argument to this function, so
freeing it inside the function seems odd. Also, no need to reset
dbuf/fd since they are no longer reused in the loop.
Naoto
On 9/11/19 3:50 AM, Seán Coffey wrote:
The current algorithm for determining the default timezone on
(non-AIX) unix systems goe
he last function to
use 'pathname'. However, it's not in keeping with normal design I guess.
I've reverted and now free pathname at other call sites instead.
new webrev at http://cr.openjdk.java.net/~coffeys/webrev.8223490.v2/webrev/
regards,
Sean.
Naoto
On 9/11/19 3:50 AM, Seán Coffey wrote:
The current algorithm for determining the default timezone on (non-AIX)
unix systems goes something like :
1. If TZ environment variable is defined, use it
2. else if /etc/timezone exists, use the value contained within it
3. else if /etc/localtime exists and is a symbolic link, use the name
Looks good Ramanand.
regards,
Sean.
On 06/08/2019 06:57, Ramanand Patil wrote:
Hi all,
Please review the patch for jdk13u backport of tzdata2019b integration into jdk:
Webrev: http://cr.openjdk.java.net/~rpatil/8228469/13u/webrev.00/
Bug: https://bugs.openjdk.java.net/browse/JDK-8228469
The
Reports that this test is failing intermittently over past few months.
It's a rare occurrence but I'd like to take steps to correct it.
I've removed the dependence on randomness in the bug.
I've fixed up the zip file creation logic to produce a real zip file
I've renamed the file to a unique
Looks good.
regards,
Sean.
On 21/02/2019 08:54, Deepak Kejriwal wrote:
Hi Naoto,
Corrected the exception message. Please find below updated version of webrev:-
http://cr.openjdk.java.net/~rpatil/JapaneseEra_and_Currency_changes_8u/webrev.02/
Thanks for review.
Regards,
Deepak
Thanks. Looks good to me.
regards,
Sean.
On 21/02/2019 09:10, Deepak Kejriwal wrote:
Hi Sean,
The webrev I shared was not correct. I have corrected the webrev.02
now. Please check now:-
http://cr.openjdk.java.net/~rpatil/JapaneseEra_changes_11u/webrev.02/
Regards,
Deepak
*From:*Seán
Deepak,
this exception message in new test still needs correction:
166 "Character.isLetter(int) failed for codepoint "
167 + Integer.toHexString(cp));
As an aside, there's probably no need for such specific exception
messages in a
Looks fine to me.
some minor comments on formatting :
space after "//" style comments in your new tests :
e.g
//List of new code points are not present in Unicode 6.2.
39 add(0x20BB); //NORDIC MARK SIGN
40
Deepak,
changes look fine to me. Some minor comments on formatting :
make a space after all "//" comments
e.g.
+ //isJavaIdentifierStart strictly conforms to code points assigned
+ //in Unicode 10.0. Since code point {32FF} is not from Unicode
10.0,
+ //return false.
Thanks for the reviews. Here's the final webrev which I hope to sponsor
for Deepak once I have the necessary approvals.
http://cr.openjdk.java.net/~coffeys/webrev.8212941.jdk8u/webrev/
Regards,
Sean.
On 28/01/19 16:06, Naoto Sato wrote:
+1
Naoto
On 1/28/19 3:18 AM, Chris Hegarty wrote:
Looks fine to me. We can update the bug summary to make it more general
to affected classes.
I can help sponsor this change if required.
regards,
Sean.
On 03/01/2019 16:51, Roger Calnan wrote:
I was looking at the fix for:
https://bugs.openjdk.java.net/browse/JDK-8182992 Typo in
/11/18 21:09, Seán Coffey wrote:
Hi Sean,
comments inline..
On 13/11/2018 18:53, Sean Mullan wrote:
Looking good, a couple of comments/questions:
* src/java.base/share/classes/java/security/Security.java
The isJdkSecurityProperty method could return false positives, for
example there may
Thanks for the comments Weijun.
As per other review thread, I'm now recording all properties set via
Security.setProperty(String, String).
regards,
Sean.
On 14/11/2018 01:11, Weijun Wang wrote:
Confused. Aren't all Security properties security-related? This is not about
normal system
/jdk/jdk/security/logging/TestTLSHandshakeLog.java
--Sean
On 11/6/18 3:46 AM, Seán Coffey wrote:
With JDK-8203629 now pushed, I've re-based my patch on latest jdk/jdk
code.
Some modifications also made based on off-thread suggestions :
src/java.base/share/classes/java/security/Security.java
Erik,
comments inline..
On 08/11/18 15:12, Erik Gahlin wrote:
Hi Sean,
I think we could still call the event
"jdk.SecurityPropertyModification", but add a @Description that
explains that events are only emitted for the JDK due to security
concerns. If we at a later stage want to include
/
Regards,
Sean.
On 17/10/18 11:25, Seán Coffey wrote:
I'd like to re-boot this review. I've been working with Erik off
thread who's been helping with code and test design.
Some of the main changes worthy of highlighting :
* Separate out the tests for JFR and Logger events
* Rename some events
is dependent on the JDK-8203629 enhancement being integrated.
Regards,
Sean.
On 10/07/18 13:50, Seán Coffey wrote:
Erik,
After some trial edits, I'm not so sure if moving the event & logger
commit code into the class where it's used works too well after all.
In the code you suggested, the
would `jcmd VM.info | grep jvm_args:` help ? or `jcmd
VM.command_line`
regards,
Sean.
On 09/10/2018 16:20, Remi Forax wrote:
Hi all,
it seems that there is no simple way* to detect if a VM is started with
--enable-preview or not ?
Rémi
* apart using JMX to sniff the VM command line with
Correction looks good to me.
regards,
Sean.
On 02/10/2018 02:09, Prasadrao Koppula wrote:
Hi,
Could you please review this patch. This patch fixes the regression caused by
LDAP fixes in JDK11, JDK8u181, JDK7u191
Webrev: http://cr.openjdk.java.net/~pkoppula/8211107/webrev.01/
This RFR should be removed from core-libs-dev. nio-dev is the correct
mailing list.
The test needs to be fixed before that happens (and possibly the code also)
regards,
Sean.
On 25/09/2018 06:53, Deepak Kejriwal wrote:
Hi,
Gentle reminder for review below fix.
Regards,
Deepak
ould handle Logger via its own framework/API in a future JDK release.
I've removed the variable names using underscore. Also optimized some
variable assignments in X509Impl.commitEvent(..)
http://cr.openjdk.java.net/~coffeys/webrev.8148188.v5/webrev/
regards,
Sean.
On 09/07/2018 18:01, Seán Co
Erik,
Thanks for reviewing. Comments inline..
On 09/07/18 17:21, Erik Gahlin wrote:
Thanks Sean.
Some feedback on the code in the security libraries.
- We should use camel case naming convention for variables (not
underscore).
Sure. I see two offending variable names which I'll fix up.
-
and modifications carried out to
clean up the code up further.
http://cr.openjdk.java.net/~coffeys/webrev.8148188.v5/webrev/
This enhancement has a dependency on JDK-8203629
Regards,
Sean.
On 02/07/18 09:49, Erik Gahlin wrote:
On 29 Jun 2018, at 17:34, Seán Coffey wrote:
I've introduced a new
t;KiB" - not the normal when
examining key lengths used in X509Certificates. i.e a 2048 bit key gets
displayed as "2 KiB" - I'd prefer to keep the 2048 display version.
new webrev at: http://cr.openjdk.java.net/~coffeys/webrev.8148188.v4/webrev/
Regards,
Sean.
On 28/06/18 17:5
for the update Erik. By default I'm proposing that the new JFR
Events and Logger be disabled. As a result the event class shouldn't
escape. If performance metrics highlight an issue, we should revisit.
regards,
Sean.
On 27/06/2018 20:57, Erik Gahlin wrote:
On 2018-06-27 21:1
new to record
events. I did not get the point to use both.
I was initially hoping to concentrate on just JFR events but I got
strong feedback to also consider use of Logger (esp. in cases where
the jdk.jfr module is not available)
regards,
Sean.
Thanks,
Xuelei
On 6/26/2018 3:18 PM, Seán Coffey
the above
code will create a new instance. Is the return value of
cce.isEnabled() dynamically changed or static?
Is there a need to support both logging and JFR? I'm new to record
events. I did not get the point to use both.
Thanks,
Xuelei
On 6/26/2018 3:18 PM, Seán Coffey wrote:
Erik
/26/2018 3:18 PM, Seán Coffey wrote:
Erik,
I rebased the patch with TLS v1.3 integration today. I hadn't
realized how much the handshaker code had changed. Hopefully, I'll
get a review from security dev team on that front.
Regards the JFR semantics, I believe the edits should match majority
of
log/record functionality. I
might catch up with you tomorrow to see what the best arrangement would be.
http://cr.openjdk.java.net/~coffeys/webrev.8148188.v2/webrev/
regards,
Sean.
On 25/06/2018 21:22, Seán Coffey wrote:
Many thanks for the review comments Erik. Replies inline.
On 24/06
Many thanks for the review comments Erik. Replies inline.
On 24/06/2018 14:21, Erik Gahlin wrote:
Hi Sean,
Some of the changes in the webrev belongs to JDK-8203629 and should be
removed for clarity.
Some initial comments:
default.jfc, profile.jfr:
The events should not have
Following on from the recent JDK-8203629 code review, I'd like to
propose enhancements on how we can record events in security libs. The
introduction of the JFR libraries can give us much better ways of
examining JDK actions. For the initial phase, I'm looking to enhance
some key security
Thanks for implementing this enhancement Erik. I think it'll prove to be
popular given the functionality available in JFR recordings. I'd agree
with Alan's comment that the Event class could be documented better to
indicate its purpose.
I'm already using this enhancement to implement some new
Looks good. Thanks for adding this improvement.
Regards,
Sean.
On 08/06/18 12:28, Baesken, Matthias wrote:
Hi Goetz/Christoph, thanks for the reviews .
However of course Sean is absolutely correct about the null character message
output.
Updated the null character related message output
Not sure if this has been tested.
Don't you need to escape the printing of the \0 character ?
errorMessage = "illegal character \0 found";
regards,
Sean.
On 08/06/2018 08:14, Langer, Christoph wrote:
Hi Matthias,
this looks good. Reviewed from my end.
Best regards
Christoph
On 07/06/2018 13:03, Baesken, Matthias wrote:
Hi Christoph you are correct I compiled it on the wrong platforms , stupid
mistake !
Will send an updated web rev .
* Also, mapFileName can't be used at this place, because it has already
been free'ed there.
Yes, makes sense. Will move
Looks fine.
Approved for jdk8u-dev.
regards,
Sean.
On 31/05/2018 02:40, Ivan Gerasimov wrote:
Hello!
I'd like to backport the fix to JDK 8u-dev.
Both source patch and the regression test had to be adjusted slightly
due to the code divergence, thus the review request.
Bug:
The Cipher tests were re-grouped via
https://bugs.openjdk.java.net/browse/JDK-8132855
NIO re-grouped via https://bugs.openjdk.java.net/browse/JDK-8132854
All appears connected with exercising hotspot intrinsics in tier1 testing.
regards,
Sean.
On 17/04/2018 08:10, Alan Bateman wrote:
On
A jdk8u (and earlier) issue where some new/recent test code meant that
IndexOutOfBoundsException could be thrown.
https://bugs.openjdk.java.net/browse/JDK-8196854
http://cr.openjdk.java.net/~coffeys/webrev.8196854/webrev/
The buf array was never required and I've verified that the original
Looks fine to me Sherman.
regards,
Sean.
On 30/01/2018 22:59, Xueming Shen wrote:
Hi,
Please help review the change for JDK-8166339.
issue: https://bugs.openjdk.java.net/browse/JDK-8166339
webrev: http://cr.openjdk.java.net/~sherman/8166339/webrev
This is a regression triggered by
issue:
The changes look fine to me Ramanand. The europe file contains some
interesting comments about the rolled back changes that have been made
for 2018c. A plan on how to resolve these pending changes can be
followed up via JDK-8195595
Regards,
Sean.
On 29/01/18 08:49, Ramanand Patil wrote:
Hi
)
at
com.sun.tools.javac.util.JavacMessages.getBundles(JavacMessages.java:125)
... 15 more
Resource bundle loading issue...could that be related to this XML
issue here?
Thanks,
Kris
On Thu, Jan 25, 2018 at 8:41 AM, Seán Coffey <sean.cof...@oracle.com
<mailto:sean.cof...@oracle.com&g
On 25/01/2018 11:58, Bernd wrote:
Hello,
some of our unit tests (using PowerMock and xmlunit) fail with 8u161 (and
u162) but work with 8u152.
I cant reproduce the fault in a stand-alone program so it seems to be
related to classloader/reflection magic of those tools, sorry.
Is this a
As someone who works with alot of log files, I'd like to chime in and
support Steven's end goal. Looking at a "Connection refused" error in
the middle of a log file that possibly extends to millions of lines is
near useless. In the era of cloud compute, diagnosing network issues is
sure to
Looks fine to me.
regards,
Sean.
On 18/12/2017 11:41, Ramanand Patil wrote:
Hi all,
Please review the fix for JDK8u Backport of
https://bugs.openjdk.java.net/browse/JDK-8153955
Backport Bug: https://bugs.openjdk.java.net/browse/JDK-8161266
Webrev:
Looks good to me.
Regards,
Sean.
On 02/12/17 01:04, Xueming Shen wrote:
On 12/1/17, 3:40 PM, Paul Sandoz wrote:
On 30 Nov 2017, at 14:46, Xueming Shen wrote:
Hi,
Please help review the change for JDK-8191918:
issue:
Looks fine.
Regards,
Sean.
On 27/11/17 08:17, Muneer Kolarkunnu wrote:
Hi All,
Please review this webrev for jdk8u backport.
Webrev: http://cr.openjdk.java.net/~akolarkunnu/8191289/webrev.00/
Main Bug: https://bugs.openjdk.java.net/browse/JDK-8154017
JDK10 review thread:
rom the main zlib repo for that change [1]
regards,
Sean.
[1] https://github.com/madler/zlib/issues/275
Thanks,
Paul
On 11/22/17, 2:00 AM, "core-libs-dev on behalf of Seán Coffey"
<core-libs-dev-boun...@openjdk.java.net on behalf of sean.cof...@oracle.com> wrote:
Look
Looking to fix a recent regression that appeared in 8u151. Thanks goes
to Sherman for the src patch. Paul Hohensee has also helped by provided
some test code. I've been able to modify an existing test to mimic the
behaviour seen with FlushableGZIPOutputStream which is found in Tomcat 7.x.
I think the OpenJDK mailing lists accept attachments if in patch format.
If it's a simple short patch, it's acceptable to paste it into email body.
Easiest solution is to use webrev[1]. If you can't upload this to
cr.openjdk.java.net - then one of your colleagues may be able to help.
[1]
This looks fine Aleksei. Approved for jdk8u-dev.
The JDK-8159240 record is currently closed as a duplicate. I'd suggest
you reopen that master record for your 8u-dev port and mark it 9-na.
regards,
Sean.
On 27/09/2017 22:28, Aleks Efimov wrote:
Hi,
Can I, please, ask for review and
Looks good.
Regards,
Sean.
On 17/08/17 20:06, Ramanand Patil wrote:
Hi All,
Please review this webrev for jdk8u backport.
Webrev: http://cr.openjdk.java.net/~rpatil/8185346/jdk8u-dev/webrev.00/
Main Bug: https://bugs.openjdk.java.net/browse/JDK-8185346
JDK10 review thread:
Looks fine to me Roger. Thanks for handling.
Should the testcase get an @bug tag ?
regards,
Sean.
On 03/08/2017 15:25, Roger Riggs wrote:
Please review a relaxation of the serial filter checks on the RMI
Registry.
Arrays of any type are serializable and do not pose a risk except
based on
Ogata,
minor comments from me.
* The bug ID referenced in mail/webrev links is wrong. It should be
8182743 ?
* The copyright change in Charset-X-Coder.java.template is the wrong
format. You can simply replace 2013 with 2017.
Regards,
Sean.
On 29/06/17 19:49, Kazunori Ogata wrote:
Hi
Hi Brian,
I think it's worth fixing unless there are objections. I see Stuart's
comment about compatibility and wonder if we've any examples of such
applications.
I just put together a patch [1] for this. I'm still figuring out how
nanoseconds get recorded for macosx.
Ricardo,
I see that JDK-8177809[1] has been logged. The newer NIO APIs can report
back with higher time precision and it's probably best to use those.
JDK-6939260 is related to your issue also.
Returning a ms value not equal to the ms value used in the
setLastModified call does seem
Looks good.
regards,
Sean.
On 23/03/2017 00:26, Ivan Gerasimov wrote:
Hello!
This is an 8u-dev only fix.
(In 9 the bug was fixed with a massive update [1]).
The fix is essentially one-liner: just check that the index remains
within the bounds after update.
Regression test was updated to
roy/8173094/webrev.01/>
Thanks,
Abhijit
On 2/10/2017 10:37 PM, Seán Coffey wrote:
Hi Abhijit,
you'll need to correct the Copyright year format in your edits. It
needs to be "Copyright (c) , , Oracle..." format.
For the ZipFile change, you need to use lower case 's' in @since.
Look
1 - 100 of 310 matches
Mail list logo