On Tue, 2 Nov 2021 19:14:23 GMT, Pavel Rappo wrote:
>> Pragmatically, fix the script to ignore those keywords on comment lines.
>> Learn Perl, its just a regular expression pattern match and replace
>> expression.
>>
>> All of the changes have to be manually reviewed by the author and then th
On Tue, 2 Nov 2021 16:30:56 GMT, Pavel Rappo wrote:
> This PR follows up one of the recent PRs, where I used a non-canonical
> modifier order. Since the problem was noticed [^1], why not to address it at
> mass?
>
> As far as I remember, the first mass-canonicalization of modifiers took place
On Sun, 17 Jan 2021 20:24:44 GMT, Martin Buchholz wrote:
> 8252412: [macos11] system dynamic libraries removed from filesystem
This pull request has now been integrated.
Changeset: c836da38
Author: Martin Buchholz
URL: https://git.openjdk.java.net/jdk/commit/c836da38
Stats:
On Sat, 23 Jan 2021 02:03:01 GMT, Valerie Peng wrote:
>> Martin Buchholz has refreshed the contents of this pull request, and
>> previous commits have been removed. The incremental views will show
>> differences compared to the previous content of the PR.
>
> Marked
forwarded to other teams for review.
On Fri, Dec 13, 2019 at 3:14 AM Patrick Zhang OS <
patr...@os.amperecomputing.com> wrote:
> Hi
>
> Please review this patch, if it should be reviewed by any group other than
> core-libs, please help forward it. Thanks.
>
> JBS: https://bugs.openjdk.java.net/br
s long as the certs and their aliases are
> unchanged, the output cacerts will always be the same. I can send out a
> code review today.
> >
> > Thanks,
> > Max
> >
> >> On Jun 12, 2019, at 10:59 AM, Weijun Wang
> wrote:
> >>
> >> Good idea
On Wed, Oct 10, 2018 at 3:10 AM, Weijun Wang wrote:
>
>
> > On Oct 10, 2018, at 1:07 AM, Martin Buchholz
> wrote:
> >
> > Seems alright to this non-crypto expert.
> >
> > The key thing I would like to see working is:
> >
> > If I create a keyst
Seems alright to this non-crypto expert.
The key thing I would like to see working is:
If I create a keystore for cacerts and then use it via -with-cacerts-file
taking the defaults, this results in goodness (which presumably means not
getting JKS keystore)
Make sure keystore creators don't have
On Wed, Mar 28, 2018 at 3:14 PM, Magnus Ihse Bursie <
magnus.ihse.bur...@oracle.com> wrote:
> On 2018-03-28 23:53, Martin Buchholz wrote:
>
> I can't find any documentation for what JNIEXPORT and friends actually do.
> People including myself have been cargo-culting JN
I can't find any documentation for what JNIEXPORT and friends actually do.
People including myself have been cargo-culting JNIEXPORT and JNICALL for
decades.
Why aren't they in the JNI spec?
---
It's fishy that the attribute externally_visible (which seems very
interesting!) is ARM specific.
#
On Mon, Jan 15, 2018 at 7:47 PM, Weijun Wang wrote:
> Hi Martin
>
> This is fine as a test. I don't know which is the recommended call, but
> "keytool -list -cacerts" also does it.
>
>
The test uses an API that adds a layer of abstraction, not exposing the
presence of a cacerts file.
> BTW, usu
https://bugs.openjdk.java.net/browse/JDK-8194960
http://cr.openjdk.java.net/~martin/webrevs/jdk/CacertsExplorer/
I have no idea what I'm doing, so review this carefully.
Is this really the recommended way to list all the cacerts?
Looks good.
---
I suspect there's some way to specify the styles more compactly, but I
don't know enough css to say.
---
+table.borderless thead tr th, table.borderless tbody tr th,
table.borderless tr th,
+table.plain > thead > tr > th, table.plain > tbody > tr > th, table.plain
> tr > th,
I
Jonathan Gibbons for "css style czar"!
---
I checked the tables at
http://cr.openjdk.java.net/~jjg/8179479-8179592/api/java/util/concurrent/BlockingDeque.html
They look perfectly fine, although I feel a twinge of
non-collapsed-border-nostalgia.
---
Yes, "striped" is a much better name than "al
Jon, I am happy for you to own the html5 style for the entire javadoc;
consistency wins; my comments are only suggestions and I'm no html or css
expert.
On Wed, May 3, 2017 at 5:03 PM, Jonathan Gibbons <
jonathan.gibb...@oracle.com> wrote:
>
>
> On 05/03/2017 04:39 PM, M
Thanks, Jon.
For the Deque/Queue tables
- *
+ *
I expected that we would modify these to
which rendered alright and is compliant (although "border" is a weird
boolean) and makes the "border intent" clear to humans and to browsers.
THIS IS JAVA, so I'd prefer more verbose meaningful names for
I judge this to be more serious than P3, even though correctness is not
affected, since production services have noticed unacceptable performance
regressions.
On Mon, Jan 30, 2017 at 12:08 PM, Sean Mullan
wrote:
> The fix looks ok to me, but I would also like Valerie to review it since
> she is
On Fri, Sep 30, 2016 at 11:14 AM, Bradford Wetmore <
bradford.wetm...@oracle.com> wrote:
> Looks fine. Looks like a copy/paste error. Good catch.
>
> If you want to be consistent, you could do the same with the others in
> this directory, or just the one.
>
It would be a fine project to delete
https://bugs.openjdk.java.net/browse/JDK-8166976
http://cr.openjdk.java.net/~martin/webrevs/openjdk9/TestCipherPBECons/
Pushed.
Xuelei, would you like to do the paperwork for the follow-on jdk8 backport?
On Fri, May 13, 2016 at 4:58 PM, Xuelei Fan wrote:
> On 5/14/2016 3:50 AM, Martin Buchholz wrote:
>> Hi Xuelei,
>>
>> The jdk9 version is still up in the air. I propose committing:
>>
Hi Xuelei,
The jdk9 version is still up in the air. I propose committing:
http://cr.openjdk.java.net/~martin/webrevs/openjdk9/AlgorithmId-get-race/
On Thu, May 12, 2016 at 5:01 PM, Xuelei Fan wrote:
> On 5/13/2016 3:00 AM, Martin Buchholz wrote:
>> I have a new simpler webrev follo
tin,
>
> If you agree with the update, I will sponsor your contribution for the
> testing and integration for JDK 9.
>
> Thanks,
> Xuelei
>
> On 5/12/2016 2:27 PM, Martin Buchholz wrote:
>> Xuelei,
>>
>> I again invite you to take ownership of this change.
>>
. But we
can also use the default initial capacity (16) if you prefer.
On Wed, May 11, 2016 at 10:54 PM, Xuelei Fan wrote:
> On 5/12/2016 1:21 PM, Martin Buchholz wrote:
>> Hi Xuelei,
>>
>> I think the non-test code will work well with any set of providers,
>> but is optim
plications may customize
> Security providers and more OID numbers may get removed/added later, so
> the oid number may be not a fixed hard-coded number. It may be easier
> to maintain the code if using the default initial capacity of HashMap.
>
> Thanks,
> Xuelei
>
>
> On
Webrev updated.
Still looking for crypto-collaborator.
On Tue, May 10, 2016 at 12:43 PM, Martin Buchholz wrote:
> https://bugs.openjdk.java.net/browse/JDK-8156584
> http://cr.openjdk.java.net/~martin/webrevs/openjdk8/AlgorithmId-get-race/
>
> I'm not a crypto engineer, so I&#x
https://bugs.openjdk.java.net/browse/JDK-8156584
http://cr.openjdk.java.net/~martin/webrevs/openjdk8/AlgorithmId-get-race/
I'm not a crypto engineer, so I'm hoping someone on security-dev
adopts this fix. But current webrev is intended to be a complete fix
for jdk8.
ksandr Otenko" <
> oleksandr.ote...@oracle.com>:
>
> Can someone summarize what happened?
>>
>> SecureRandom used to get entropy from /dev/random, which is configurable
>> through a policy file to /dev/urandom. Has this changed?
>>
>> Alex
>>
>>
Thanks to Peter for digging into the secure seed generator classes and
coming up with a patch. Openjdk security folks, please review. I confess
to getting lost whenever I try to orient myself in the twisty maze of seed
generator implementation files.
Anyways, it seems important to have prngs lik
On Fri, Jun 20, 2014 at 1:42 AM, Peter Levart
wrote:
>
> This pertains to the other thread (ThreadLocalRandom clinit troubles)
> started by Martin Buchholz, right? He's making a valid point. The "seeder"
> static field is still uninitialized during either NetworkInter
Hi Joe,
On Fri, Feb 22, 2013 at 11:19 AM, Joe Darcy wrote:
>
> Should third-party vendor extensions that are "supported" for public use
> by the third-party use jdk.Supported?
>
>
> No; as I envision it, the jdk.Supported annotation is only meant to convey
> supported-ness in the JDK of parts o
On Thu, Feb 21, 2013 at 6:16 PM, Joe Darcy wrote:
>
> However, the com.sun.* subpackages are a mix of APIs that are supported as
> described above as well as APIs that are not supported.
I was under the impression that the general rule was that all of com.sun.*
fell under the "jdk supported" um
as I'm not a subscriber.>
>>
>> Doug Lea said the following on 04/16/10 21:43:
>>>
>>> On 04/15/10 18:34, Martin Buchholz wrote:
>>>
>>>> People are using Atomic field updaters to update fields in classes in
>>>> other classloader
#x27;m not a subscriber.>
>
> Doug Lea said the following on 04/16/10 21:43:
>>
>> On 04/15/10 18:34, Martin Buchholz wrote:
>>
>>> People are using Atomic field updaters to update fields in classes in
>>> other classloaders.
>>>
>>
>>
On Thu, Apr 15, 2010 at 19:04, David Holmes wrote:
> Martin Buchholz said the following on 04/16/10 11:38:
>>
>> On Thu, Apr 15, 2010 at 17:49, David Holmes
>> wrote:
>>>
>>> If this proceeds I think you need to include AtomicReferenceFieldUpdater
>>
seems inconsistent that getDeclaredField's internal checks say you don't
> have permission to access this field, while what should amount to the same
> checks via ReflectUtil say you do. The question is: which check is wrong?
>
> David
> -
>
>
> Martin Bu
Hi java.util.concurrent security team,
People are using Atomic field updaters to update fields in classes in
other classloaders.
Toby writes:
We received a bug report for App Engine that AtomicLongFieldUpdater
(and its sibling) were failing with RuntimePermission
accessDeclaredMembers. Looking a
eedom from security
* exceptions.
* @author Martin Buchholz
*/
import java.lang.annotation.Annotation;
import java.lang.annotation.ElementType;
import java.lang.annotation.Retention;
import java.lang.annotation.RetentionPolicy;
import java.lang.annotation.Target;
import java.lang.reflect.M
37 matches
Mail list logo
