On 11/11/2014 1:31 PM, Wang Weijun wrote:
> A subclass of Exception would also return true when using instanceof, where I
> think the class name is still informational.
>
Got it. But Exception is still informational as it means it is not an
other exception.
I'm not sure it is something we reall
A subclass of Exception would also return true when using instanceof, where I
think the class name is still informational.
--Max
> On Nov 11, 2014, at 11:14, Xuelei Fan wrote:
>
> Why not use "instanceof"?
>
> Xuelei
>
> On 11/11/2014 10:58 AM, Wang Weijun wrote:
>> Please review the fix at
Looks fine to me.
A pretty minor comment.
share/classes/javax/xml/crypto/dsig/spec/XPathType.java
---
157 this.expression = expression;
158 this.filter = filter;
159 if (namespaceMap == null) {
160 throw new NullPointerException("namespa
Why not use "instanceof"?
Xuelei
On 11/11/2014 10:58 AM, Wang Weijun wrote:
> Please review the fix at
>
>http://cr.openjdk.java.net/~weijun/8063087/webrev.00/
>
> which is simply
>
> void displayErrorDialog(Window w, Throwable t) {
> if (t instanceof NoDisplayException) {
>
Please review the fix at
http://cr.openjdk.java.net/~weijun/8063087/webrev.00/
which is simply
void displayErrorDialog(Window w, Throwable t) {
if (t instanceof NoDisplayException) {
return;
}
+if (t.getClass() == Exception.class) {
+di
Hi,
On Mon, Nov 10, 2014 at 10:36 PM, Bernd Eckenfels
wrote:
> Hello,
>
> the question is, what is a extension API actually helping with: the JSSE
> implementation is slow to adopt to typical advances in TLS browser
> "wars". While this is not so bad as nobody implements a Web Browser in
> Java a
Another area of applicability is inner authentication mechanisms which
make use of channel binding; these mechanisms need to actually acquire
chunks of data from the handshake exchange.
http://tools.ietf.org/html/rfc5929 for more info
On 11/10/2014 03:36 PM, Bernd Eckenfels wrote:
Hello,
the
I’ve updated the fix to reduce the casts to KeyEntry:
http://cr.openjdk.java.net/~vinnie/8046777/webrev.02/
On 10 Nov 2014, at 18:48, Vincent Ryan wrote:
>
> On 10 Nov 2014, at 18:13, Sean Mullan wrote:
>
>> You missed one of my comments:
>>
623-629 similar comment as above
>
> I ma
Hello,
the question is, what is a extension API actually helping with: the JSSE
implementation is slow to adopt to typical advances in TLS browser
"wars". While this is not so bad as nobody implements a Web Browser in
Java anyway, it does make it harder for server vendors to offer a full
stack (wi
On 10 Nov 2014, at 18:13, Sean Mullan wrote:
> You missed one of my comments:
>
> >> 623-629 similar comment as above
I made the change to join the two if statements into a single one.
Did you want me to use a local variable instead of casts?
>
> Otherwise looks fine.
>
> --Sean
>
> On 11/
You missed one of my comments:
>> 623-629 similar comment as above
Otherwise looks fine.
--Sean
On 11/10/2014 01:05 PM, Vincent Ryan wrote:
Thanks Sean. I’ve generated a new webrev that addresses your comments:
http://cr.openjdk.java.net/~vinnie/8046777/webrev.01/
On 10 Nov 2014, at 16:50
Thanks Sean. I’ve generated a new webrev that addresses your comments:
http://cr.openjdk.java.net/~vinnie/8046777/webrev.01/
On 10 Nov 2014, at 16:50, Sean Mullan wrote:
> A few comments:
>
> * KeystoreImpl.m
>
> - it is odd to have a comment embedded in the parameter list and makes the
> l
A few comments:
* KeystoreImpl.m
- it is odd to have a comment embedded in the parameter list and makes
the line very long. Can you move this comment above the call?
- update copyright year
* KeychainStore.java
297-304 I think it would be cleaner to write these lines as:
} else
On 11/10/2014 07:28 AM, Simone Bordet wrote:
Hi,
On Mon, Nov 10, 2014 at 2:07 PM, Florian Weimer wrote:
On 11/07/2014 02:06 PM, Simone Bordet wrote:
This email is about the idea to introduce in JDK 9 a fully fledged TLS
Extensions API.
Adding ALPN [0] support to JDK 9 requires, differently
Hi,
On Mon, Nov 10, 2014 at 2:07 PM, Florian Weimer wrote:
> On 11/07/2014 02:06 PM, Simone Bordet wrote:
>
>> This email is about the idea to introduce in JDK 9 a fully fledged TLS
>> Extensions API.
>>
>> Adding ALPN [0] support to JDK 9 requires, differently from other TLS
>> extensions, to pr
On 11/07/2014 02:06 PM, Simone Bordet wrote:
This email is about the idea to introduce in JDK 9 a fully fledged TLS
Extensions API.
Adding ALPN [0] support to JDK 9 requires, differently from other TLS
extensions, to provide application code that will be run in the
context of the TLS implementa
16 matches
Mail list logo
