On 26/10/2022 23:53, Peter Firmstone wrote:
The change will have some performance impact, by requiring redundant
parsing.
Just thought I'd mention it, in case it hasn't been thought of. If you
do an internet search there are other implementations of RFC3986 in
java also.
https://github.com/
On Wed, 26 Oct 2022 16:41:29 GMT, Michael McMahon wrote:
>> Deprecate URL constructors. Developers are encouraged to use `java.net.URI`
>> to parse or construct any URL.
>>
>> The `java.net.URL` class does not itself encode or decode any URL components
>> according to the escaping mechanism de
Hello,good that you look into that topic. While it might not be a problem in practice (large buffers are ok, but larger than 1mb seems seldom, especially in multi threaded apps) it is still a condition which can be handled. But with AE ciphers becoming the norm, such large
Interesting. Is this RFR a done deal?
While I like the concept and and understand the reasoning of URL not
having a public constructor, I think this may have been thought of in
isolation, I'm not sure how a custom URI, that strictly complies with
RFC 3986 will behave, if it must also be parse
Thanks Alan, comments inline below.
On 26/10/2022 11:07 pm, Alan Bateman wrote:
:
What would make a significant difference is returning non null
ProtectionDomain's for JDK modules, so we can reduce the size of the
trusted computing base, to make our job smaller, hopefully that will
allow
On Wed, 26 Oct 2022 20:45:57 GMT, Jamil Nimeh wrote:
>> (The first commit in this PR actually has the code without the check if
>> anyone wants to measure.. well its also trivial to edit..)
>>
>> I measured about 50% slowdown on 64 byte payloads. One could argue that 64
>> bytes is not all tha
On Wed, 26 Oct 2022 15:47:08 GMT, vpaprotsk wrote:
>> src/java.base/share/classes/com/sun/crypto/provider/Poly1305.java line 171:
>>
>>> 169: }
>>> 170:
>>> 171: if (len >= 1024) {
>>
>> Out of curiosity, do you have any perf numbers for the impact of this change
>> on systems
On Wed, 26 Oct 2022 17:39:56 GMT, Xue-Lei Andrew Fan wrote:
>> `URLStreamHandler` really belongs to `java.net.URL`, and is an
>> implementation detail of the infrastructure/SPI that makes it possible to
>> eventually call `URL::openConnection`. I do not think it would be
>> appropriate to have
On Wed, 26 Oct 2022 17:24:59 GMT, Daniel Fuchs wrote:
>> src/java.base/share/classes/java/net/URL.java line 852:
>>
>>> 850: * @since 20
>>> 851: */
>>> 852: public static URL fromURI(URI uri, URLStreamHandler streamHandler)
>>
>> What do you think to have this method in URI inste
On Wed, 26 Oct 2022 17:09:20 GMT, Xue-Lei Andrew Fan wrote:
>> Deprecate URL constructors. Developers are encouraged to use `java.net.URI`
>> to parse or construct any URL.
>>
>> The `java.net.URL` class does not itself encode or decode any URL components
>> according to the escaping mechanism
On Wed, 26 Oct 2022 16:00:56 GMT, Daniel Fuchs wrote:
> Deprecate URL constructors. Developers are encouraged to use `java.net.URI`
> to parse or construct any URL.
>
> The `java.net.URL` class does not itself encode or decode any URL components
> according to the escaping mechanism defined in
On Tue, 18 Oct 2022 17:43:53 GMT, Weijun Wang wrote:
>> java.util.Enumeration is a legacy interface from java 1.0.
>> There are a few places with cycles which use it to iterate over collections.
>> We can replace this manual cycle with enchanced-for, which is shorter and
>> easier to read.
>
>
On Thu, 20 Oct 2022 11:21:41 GMT, Andrey Turbanov wrote:
>> src/java.base/share/classes/sun/security/x509/X509CRLEntryImpl.java line 412:
>>
>>> 410: ObjectIdentifier findOID = ObjectIdentifier.of(oid);
>>> 411: for (Extension ex : extensions.getAllExtensions()) {
java.util.Enumeration is a legacy interface from java 1.0.
There are a few places with cycles which use it to iterate over collections. We
can replace this manual cycle with enchanced-for, which is shorter and easier
to read.
-
Commit messages:
- [PATCH] Use enhanced-for cycle inst
On Mon, 17 Oct 2022 21:50:08 GMT, Andrey Turbanov wrote:
> java.util.Enumeration is a legacy interface from java 1.0.
> There are a few places with cycles which use it to iterate over collections.
> We can replace this manual cycle with enchanced-for, which is shorter and
> easier to read.
src
On Wed, 26 Oct 2022 16:00:56 GMT, Daniel Fuchs wrote:
> Deprecate URL constructors. Developers are encouraged to use `java.net.URI`
> to parse or construct any URL.
>
> The `java.net.URL` class does not itself encode or decode any URL components
> according to the escaping mechanism defined in
On Wed, 26 Oct 2022 16:00:56 GMT, Daniel Fuchs wrote:
> Deprecate URL constructors. Developers are encouraged to use `java.net.URI`
> to parse or construct any URL.
>
> The `java.net.URL` class does not itself encode or decode any URL components
> according to the escaping mechanism defined in
Deprecate URL constructors. Developers are encouraged to use `java.net.URI` to
parse or construct any URL.
The `java.net.URL` class does not itself encode or decode any URL components
according to the escaping mechanism defined in RFC2396. It is the
responsibility of the caller to encode any fi
On Fri, 21 Oct 2022 19:54:57 GMT, Mark Powers wrote:
> https://bugs.openjdk.org/browse/JDK-8293093
This pull request has now been integrated.
Changeset: 8e5d680a
Author:Mark Powers
Committer: Anthony Scarpino
URL:
https://git.openjdk.org/jdk/commit/8e5d680a98ad28eb3607d227783bdea94
On Tue, 25 Oct 2022 21:48:47 GMT, Jamil Nimeh wrote:
>> vpaprotsk has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> extra whitespace character
>
> src/java.base/share/classes/com/sun/crypto/provider/Poly1305.java line 171:
>
>> 169:
On Tue, 25 Oct 2022 23:48:49 GMT, Sandhya Viswanathan
wrote:
>> vpaprotsk has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> extra whitespace character
>
> src/hotspot/cpu/x86/macroAssembler_x86_poly.cpp line 806:
>
>> 804: evmovdquq(A0
On Tue, 25 Oct 2022 21:57:34 GMT, Jamil Nimeh wrote:
>> vpaprotsk has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> extra whitespace character
>
> src/java.base/share/classes/com/sun/crypto/provider/Poly1305.java line 296:
>
>> 294:
You are currently receiving this informational message with the original email
attached. We need your help in notifying the team or sender responsible for
this mail flow to ensure future email is delivered properly.
The host that sent this message is not compliant with Oracle's email security
p
You are currently receiving this informational message with the original email
attached. We need your help in notifying the team or sender responsible for
this mail flow to ensure future email is delivered properly.
The host that sent this message is not compliant with Oracle's email security
p
You are currently receiving this informational message with the original email
attached. We need your help in notifying the team or sender responsible for
this mail flow to ensure future email is delivered properly.
The host that sent this message is not compliant with Oracle's email security
p
Continuing a conversation I had with Sean Mullan at Java One, for a broader
audience.
We tend to believe that bulk operations are good. Large bulk operations give
the system the most information at once, allowing it to make more informed
decisions. Understanding the hotspot compiler on some lev
On Wed, 26 Oct 2022 14:22:08 GMT, Martin Doerr wrote:
> Change looks good. Does it need a CSR?
Hi Martin , from what I read here
https://wiki.openjdk.org/display/csr/CSR+FAQs no CSR is needed. But I am no
expert on the topic so maybe someone else has an opinion on this ?
While looking at t
On Tue, 18 Oct 2022 14:55:12 GMT, Matthias Baesken wrote:
>> We have a number of failing sun/security/pkcs11 test on RHEL 8.6, see
>>
>> https://bugs.openjdk.org/browse/JDK-8295343
>> 8295343 : sun/security/pkcs11 tests fail on Linux RHEL 8.6
>>
>> The exceptions generated by these tests someti
On 26/10/2022 09:02, Peter Firmstone wrote:
:
That's correct, however some parts will bit rot faster than others,
historically some parts of the JDK are very slow to change, unless
someone comes through deliberately removing them, which I would hope
not, but I realise that new methods and
Thanks Alan,
That's correct, however some parts will bit rot faster than others,
historically some parts of the JDK are very slow to change, unless
someone comes through deliberately removing them, which I would hope
not, but I realise that new methods and classes might open new code
paths th
30 matches
Mail list logo
