> On Aug 7, 2018, at 2:50 AM, Sean Mullan wrote:
>
> On 8/6/18 11:14 AM, Weijun Wang wrote:
>> That would be a real behavior change and I want to be safe.
>
> I'm not seeing how this would be a behavior change if it is a new option, can
> you add more details on that? If I specify
Hi Xuelei,
I’ve attached a java file with a method that can be used as a test case. The
caller will need to provide SSLEngines. I assume that is something you can do?
As I said this is with TLS 1.2.
I catch the exceptions I mentioned in my last email. Although there are
comments that I do
Hi Sergey,
On 8/6/2018 3:39 PM, Sergey Bylokhov wrote:
Hi, Joe.
On 06/08/2018 14:30, joe darcy wrote:
Even if currently less commonly used, I think "ineffectual" better
captures the intention of what I want to convey in the comment than
"ineffective."
Can you please clarify this: what does
Hi, Joe.
On 06/08/2018 14:30, joe darcy wrote:
Even if currently less commonly used, I think "ineffectual" better
captures the intention of what I want to convey in the comment than
"ineffective."
Can you please clarify this: what does it mean "ineffectual" in this
context? why we need to
Ok, I included Max's description for the special PBE parameter handling.
Should be enough details...
Filed: https://bugs.openjdk.java.net/browse/JDK-8209038
Thanks,
Valerie
On 8/6/2018 7:16 AM, Sean Mullan wrote:
On 8/3/18 8:19 PM, Valerie Peng wrote:
I can file a follow-on issue.
+1
> On Aug 6, 2018, at 3:11 PM, joe darcy wrote:
>
> Hello,
>
> Various interfaces in the JDK extend Serializable and declare
> serialVersionUID fields. Such fields are ineffectual and
> @SuppressWarnings("serial") should be applied to such fields to suppress
> future planned serial lint
Hi Roger,
Even if currently less commonly used, I think "ineffectual" better
captures the intention of what I want to convey in the comment than
"ineffective."
Thanks all for the reviews; cheers,
-Joe
On 8/6/2018 12:44 PM, Roger Riggs wrote:
Hi Joe,
Looks fine. I would probably have
Looks fine to me.
--Sean
On 8/6/18 3:11 PM, joe darcy wrote:
Hello,
Various interfaces in the JDK extend Serializable and declare
serialVersionUID fields. Such fields are ineffectual and
@SuppressWarnings("serial") should be applied to such fields to suppress
future planned serial lint
Hi Joe,
Looks fine. I would probably have used "ineffective" instead of
"ineffectual".
(Googling "define ineffective" and "define ineffectual" shows an
interesting graph of
the use of the term with ineffective growing and ineffectual dropping in
use.
Look under the more tag)
Regards,
Hi Joe,
Looks fine.
Brian
On Aug 6, 2018, at 12:11 PM, joe darcy wrote:
> Various interfaces in the JDK extend Serializable and declare
> serialVersionUID fields. Such fields are ineffectual and
> @SuppressWarnings("serial") should be applied to such fields to suppress
> future planned
After further evaluation of the new jdk.includeInExceptions security
property originally introduced in JDK-8204233 [1] and further
generalized in JDK-8207846 [2], I felt that a stronger warning should be
added to the description of the property alerting the user to the
potential risks of
Hello,
Various interfaces in the JDK extend Serializable and declare
serialVersionUID fields. Such fields are ineffectual and
@SuppressWarnings("serial") should be applied to such fields to suppress
future planned serial lint checks (JDK-8202056).
Most of the affected files are in the
On 8/6/18 11:14 AM, Weijun Wang wrote:
That would be a real behavior change and I want to be safe.
I'm not seeing how this would be a behavior change if it is a new
option, can you add more details on that? If I specify -providerName,
intuitively I would expect it would be used, at least as
OK. No more comment from me.
Thanks,
Xuelei
On 8/6/2018 8:14 AM, Weijun Wang wrote:
That would be a real behavior change and I want to be safe.
-providername is now used by "keytool -importcert" to choose keystore
implementations. I am not sure if someone already using -providername for
That would be a real behavior change and I want to be safe.
-providername is now used by "keytool -importcert" to choose keystore
implementations. I am not sure if someone already using -providername for this
purpose might encounter any unexpected change.
We can rethink about this decision if
Maybe, the specified provider should be honored firstly?
Xuelei
On 8/6/2018 1:53 AM, Weijun Wang wrote:
Ping again.
Also please take a review at the CSR at
https://bugs.openjdk.java.net/browse/JDK-8208689.
Thanks
Max
On Aug 2, 2018, at 10:28 AM, Weijun Wang wrote:
Please take a review
On 8/3/18 8:19 PM, Valerie Peng wrote:
I can file a follow-on issue. However, I want to clarify what we want to
do before filing it.
Based on current exchanges: We want to update
Cipher.getParameters()/CipherSpi.engineGetParameters() with similar
format/wording as
Ping again.
Also please take a review at the CSR at
https://bugs.openjdk.java.net/browse/JDK-8208689.
Thanks
Max
> On Aug 2, 2018, at 10:28 AM, Weijun Wang wrote:
>
> Please take a review at
>
> http://cr.openjdk.java.net/~weijun/8201290/webrev.00/
>
> Please note I didn't use
18 matches
Mail list logo
