Hi s'marks,
You probably don't need to absolutify paths.
And you can easily handle multiple args.
(just for fun!)
Checks for javadoc comment; handles popular html entities; handles multiple
lines; handles both tt and code:
#!/bin/bash
find "$@" -name '*.java' | \
xargs -r perl -p0777i -e \
'd
> 在 2015年10月1日,上午8:21,Steve Drach 写道:
>
>> Can you add a -debug option to show the full exception stack info? I even
>> could not see how SSL is involved here.
>
> Would you still like me to do this?
Yes, please. I cannot reproduce the problem in my jdk9 repo using a public
cacerts file. If
Hi Alexander, Martin,
The challenge of Perl file slurping and Emacs one-liners was too much to bear.
This is Java, so one-liners are hardly possible. Still, there are a bunch of
improvements that can be made to the Java version. (OK, and I'm showing off a bit.)
Take a look at this:
http://cr
>>> The jarsigner from jdk9/dev can not, giving me the error
>>>
>>> jarsigner: unable to sign jar: javax.net.ssl.SSLException:
>>> java.lang.RuntimeException: Unexpected error:
>>> java.security.InvalidAlgorithmParameterException: the trustAnchors
>>> parameter must be non-empty
>>>
>>> I’m
Hi Max,
Here are updated answers to your questions, after I received some help (thank
you Sean Mullan).
> Can you describe if there is any effect on signed jars? Including:
>
> 1. Will jarsigner be able to sign such a jar?
The jarsigner from 1.8.0_51 can sign the jar. The jarsigner from jdk9/
> 在 2015年10月1日,上午2:51,Sean Mullan 写道:
>
>> The jarsigner from jdk9/dev can not, giving me the error
>>
>> jarsigner: unable to sign jar: javax.net.ssl.SSLException:
>> java.lang.RuntimeException: Unexpected error:
>> java.security.InvalidAlgorithmParameterException: the trustAnchors parameter
looks good!
sherman
On 09/23/2015 10:42 AM, Kumar Srinivasan wrote:
Hi John, Sherman,
I noticed a flaw in my fix, ie. in a section of the logic that is present
but unused, and reserved for future use, fixed it here anyway, for
correctness.
The full webrev:
http://cr.openjdk.java.net/~ksrini/
Hi,
This is an enhancement to allow a SAX parsing process to be stopped and
resumed. A SAX process scans through an entire document while making
callbacks to its handler when defined events are met. The stop and
resume methods make it easy to stop and subsequently resume the process
as needed
Reviewed. Thank you, thank you, Joda-Time! — John
On Sep 23, 2015, at 10:42 AM, Kumar Srinivasan
wrote:
>
> Hi John, Sherman,
>
> I noticed a flaw in my fix, ie. in a section of the logic that is present
> but unused, and reserved for future use, fixed it here anyway, for
> correctness.
>
I noticed that the Navigable* class descriptions were incompletely
@link-ified.
Index: src/main/java/util/NavigableMap.java
===
RCS file:
/export/home/jsr166/jsr166/jsr166/src/main/java/util/NavigableMap.java,v
retrieving revision 1.2
On 9/30/15 2:30 PM, Steve Drach wrote:
Hi Max,
Can you describe if there is any effect on signed jars? Including:
1. Will jarsigner be able to sign such a jar?
The jarsigner from 1.8.0_51 can sign the jar. The jarsigner from jdk9/dev can
not, giving me the error
jarsigner: unable to sig
Hi Joe,
On Sep 25, 2015, at 10:33 AM, joe darcy wrote:
> Full webrev of the changes up at
>
>JDK-8136874: Bug in port of fdlibm pow to Java - Java Bug System
>http://cr.openjdk.java.net/~darcy/8136874.0/
>
> The bulk of the changeset is a new battery of tests including the failing
> v
You are correct that the discussion on the serviceLoader may be off-topic wrt
JEP 264. I believe I mentioned that currently Log4j only supports binding with
a single implementation as well. But we don’t take the first, we take the one
with the highest priority.
Ralph
> On Sep 30, 2015, at 9:50
Hi Max,
> Can you describe if there is any effect on signed jars? Including:
>
> 1. Will jarsigner be able to sign such a jar?
The jarsigner from 1.8.0_51 can sign the jar. The jarsigner from jdk9/dev can
not, giving me the error
jarsigner: unable to sign jar: javax.net.ssl.SSLException:
jav
+1 for having check methods start with 'require' .. that's a nice and
useful naming pattern.
On Wed, Sep 30, 2015 at 9:13 AM, Remi Forax wrote:
>
>
> - Mail original -
> > De: "Paul Benedict"
> > À: "Peter Levart"
> > Cc: "core-libs-dev"
> > Envoyé: Mercredi 30 Septembre 2015 16:06:18
Hi Ralph,
On 30/09/15 18:30, Ralph Goers wrote:
What would be preferable is to have the serviceLoader accept “criteria” (which are
callbacks) that can evaluate each of the located services based on any additional
properties that are included in the properties file and either eliminate them or
Alan,
Your suggestion is literally the same thing that Peter suggested which is what
my reply below was to. So you can take that reply as the reply to your message
as well.
What would be preferable is to have the serviceLoader accept “criteria” (which
are callbacks) that can evaluate each of
+1
-Joe
On 9/30/2015 7:49 AM, Chris Hegarty wrote:
Adding additional diagnostic information to help find the root cause
of the intermittent failures seems like the right thing to do. Reviewed.
-Chris.
On 30/09/15 15:21, Roger Riggs wrote:
Please review an enhancement to the test to help dia
On 30/09/15 16:50, Georgiy Rakov wrote:
Hello Miroslav,
could you please see some more comments below:
1. I believe it's better to say that exactly "fully qualified name" of
the provider factory implementation class is assumed to be the value
of the property:
* {@code javax.xml.soap.
On 30/09/15 16:20, Deva Sagar wrote:
Hi Georgiy,
I think both Miran and I are referring to the mention of
SAAJMetaFactory in the bullet list about the public newInstance()
method. The Javadoc of the SAAJMetaFactory class still describes it as
an SPI and it is accessible from package-info. T
Note that the patches are not all independent - each patch was tested with
previous patches applied. My original intent was to push all the patches
at once, but of course there are testing advantages to pushing them
individually.
On Wed, Sep 30, 2015 at 5:59 AM, Paul Sandoz wrote:
>
> > On 30 S
Adding additional diagnostic information to help find the root cause of
the intermittent failures seems like the right thing to do. Reviewed.
-Chris.
On 30/09/15 15:21, Roger Riggs wrote:
Please review an enhancement to the test to help diagnose this failure
in the ProcessHandle TreeTest.
Web
Please review an enhancement to the test to help diagnose this failure
in the ProcessHandle TreeTest.
Webrev:
http://cr.openjdk.java.net/~rriggs/webrev-treetest-8137313/
Issue:
https://bugs.openjdk.java.net/browse/JDK-8137313
Thanks, Roger
- Mail original -
> De: "Paul Benedict"
> À: "Peter Levart"
> Cc: "core-libs-dev"
> Envoyé: Mercredi 30 Septembre 2015 16:06:18
> Objet: Re: RFR 8135248: Add utility methods to check indexes and ranges
>
> Ah, I was going to write about "values" ... glad this was mentioned. With
> Val
On 30/09/2015 14:59, Ralph Goers wrote:
If I understand you correctly, then no that isn’t what I would want. The
version and priority are captured in the same properties file where the class
name is specified. If the class implements the wrong version or isn’t chosen
due to its priority then t
If I understand you correctly, then no that isn’t what I would want. The
version and priority are captured in the same properties file where the class
name is specified. If the class implements the wrong version or isn’t chosen
due to its priority then the class isn’t loaded. To do what you are
Ah, I was going to write about "values" ... glad this was mentioned. With
Valhalla working on value classes, it does raise the question if
range-checking is particular to Objects. Clearly it won't be once values
are introduced.
PS: I am still in favor of using Objects at the time being though just
> On 30 Sep 2015, at 04:16, Martin Buchholz wrote:
>
> Thanks for the specdiff - much easier to review for javadoc changes!. I went
> through it. There were a small number of minor mistakes, which are now
> corrected. Now would be a good time to regenerate the specdiff.
>
Updated.
As you
On 29/09/15 16:43, Deva Sagar wrote:
Hi Miran,
Sorry for the delay in responding to this - I was busy with WLS
release close down, and now I have moved to a different job in the
cloud organization outside of WLS and web services.
Regarding your question in #3 - I think Georgiy made a good
> On 25 Sep 2015, at 17:19, Peter Levart wrote:
>
> Hi Paul,
>
> Thanks for looking into this.
>
Apologies for the late reply.
> On 09/25/2015 04:07 PM, Paul Sandoz wrote:
>> Hi,
>>
>> This looks like a partial dup of
>> https://bugs.openjdk.java.net/browse/JDK-8076596
>
> Ah, sorry, I w
On 09/29/2015 11:17 PM, Ralph Goers wrote:
FWIW, I considered using the ServiceLoader to bind the Log4j API to the
implementation. However, Log4j also includes the API version and only looks for
bindings that implement that version. We also include a “priority” - the
binding with the highest
On 09/29/2015 10:01 PM, Paul Sandoz wrote:
>I think it's worth introducing Preconditions class. checkNotNull overloads are
equally well suited for Objects as they are for Preconditions, so it's not wrong
to have them in both, while checkIndex and friends don't really suit any of the
existing
32 matches
Mail list logo