I just noticed that doc/building.{md,html} describes minimum toolchain versions,
so also needs to be updated. Here’s the update, matching what’s now in the JEP:
full: https://cr.openjdk.java.net/~kbarrett/8246032/open.05/
incr: https://cr.openjdk.java.net/~kbarrett/8246032/open.05.inc/
I also
Please review the jpackage fix for bug [1] at [2].
Added timestamp to verbose and test output in form of [HH:mm:ss.SSS].
[1] https://bugs.openjdk.java.net/browse/JDK-8248261
[2] http://cr.openjdk.java.net/~almatvee/8248261/webrev.00/
Thanks,
Alexander
On 7/6/20 4:55 PM, Stuart Marks wrote:
On 7/6/20 4:37 PM, huizhe.w...@oracle.com wrote:
Please refer to the previous review for 8248348. This patch should
have been pushed into 15 in the first place. I hope a merge with 16
repo won't cause any trouble/conflict.
JBS:
Hello Nikola,
I added to the issue [1] a link [2] to the archive of your message.
I should note that the discussion should ideally be conducted on nio-dev [3] as
the topic pertains to that subcomponent.
Thanks,
Brian
[1] https://bugs.openjdk.java.net/browse/JDK-8232092
[2]
On 7/6/20 4:37 PM, huizhe.w...@oracle.com wrote:
Please refer to the previous review for 8248348. This patch should have been
pushed into 15 in the first place. I hope a merge with 16 repo won't cause any
trouble/conflict.
JBS: https://bugs.openjdk.java.net/browse/JDK-8248884
webrev:
Please refer to the previous review for 8248348. This patch should have
been pushed into 15 in the first place. I hope a merge with 16 repo
won't cause any trouble/conflict.
JBS: https://bugs.openjdk.java.net/browse/JDK-8248884
webrev: http://cr.openjdk.java.net/~joehw/jdk15/8248884/webrev/
Please review the jpackage fix for bug [1] at [2].
Substituted old File APIs with Path/Files APIs when it was possible and
makes sense.
[1] https://bugs.openjdk.java.net/browse/JDK-8223955
[2] http://cr.openjdk.java.net/~almatvee/8223955/webrev.00/
Thanks,
Alexander
Thanks for that extra info.
I think it would be much cleaner to avoid having to set that property
and instead start the handshake synchronously if the
"com.sun.jndi.ldap.tls.cbtype" property is set. This way only one
property needs to be set and you don't need to guess what an acceptable
Hi Sean,
Alexey answered the same question for me:
I mean “com.sun.jndi.ldap.connect.timeout” property.
The positive value forces to start TLS handshake and wait for it completion
during the connectTimeout milliseconds:
Connection.java
if (connectTimeout > 0) {
int socketTimeout =
Hello core-libs-dev,
I was asked to help look into JDK-8232092 by Christian Stein (the bug
reporter), and since I don't have an OpenJDK account yet I'm sharing my
findings on the issue here. I looked into two separate issues that might cause
FileSystemProvider.checkAccess to return an
Hi Roger,
the structure of the original design is preserved, the details change
with the intent of having code that is easier to reason about.
The main loop has many exit points in the original code, as well as in
the new code. For this reason, I prefer not to express it as a while or
as a
Hi Alexey,
This may have been discussed already, but can you explain why the
"com.sun.jndi.ldap.connect.timeout" property needs to be set in order to
use this feature? That property is mostly used in tests to avoid long
socket timeouts, etc.
Why does that need to be set? What problem are
Hi Raffaello,
I'm still not sure it needed this much of a re-write to fix the bug;
It will take some time to look at the changes.
Regardless, OpenJDK conventions call for following the style of the
existing code.
Your new comments follow neither the existing convention to use "//..."
comments
13 matches
Mail list logo
