On Tue, 26 Apr 2022 11:35:10 GMT, Daniel Fuchs wrote:
>> - use `String.equalsIgnoreCase()` instead of hand-written code relying on
>> `String.charAt()`
>> - use `String.compareToIgnoreCase()` instead of hand-written code relying on
>> `String.charAt()`
>> - drop branches that are never executed
On Sat, 5 Feb 2022 20:29:50 GMT, Xue-Lei Andrew Fan wrote:
> In [JDK-8281289](https://bugs.openjdk.java.net/browse/JDK-8281289), the
> SSLParameters class was updated with the patch:
>
> - return Collections.unmodifiableList(new
> ArrayList<>(sniNames.values()));
> + return List.copyOf(sniName
On Fri, 4 Feb 2022 23:02:21 GMT, Xue-Lei Andrew Fan wrote:
> Please review this trivial code clean up, for a little bit better performance.
There's a small compatibility risk with this change, e.g.,
`List.copyOf(...).contains(null)` will throw NPE while
`Collections.unmodifiableList(...).conta
On Wed, 18 Aug 2021 10:07:35 GMT, Claes Redestad wrote:
> C-style array declarations generate noisy warnings in IDEs, et.c. This patch
> cleans up all java.* packages.
>
> (Copyrights intentionally not updated due the triviality of most changes)
This pull request has now bee
On Wed, 18 Aug 2021 10:07:35 GMT, Claes Redestad wrote:
> C-style array declarations generate noisy warnings in IDEs, et.c. This patch
> cleans up all java.* packages.
>
> (Copyrights intentionally not updated due the triviality of most changes)
Thanks for reviewing, Dan
C-style array declarations generate noisy warnings in IDEs, et.c. This patch
cleans up all java.* packages.
(Copyrights intentionally not updated due the triviality of most changes)
-
Commit messages:
- Avoid C-style array declarations in java packages
Changes: https://git.openjdk
On Tue, 10 Aug 2021 05:08:54 GMT, Sergey Bylokhov wrote:
> This is the continuation of JDK-8233884 and JDK-8271456. This change affects
> fewer cases so I fix all "java." modules at once.
>
> In many places standard charsets are looked up via their names, for example:
> absolutePath.getBytes("U
On Mon, 5 Jul 2021 13:42:15 GMT, Сергей Цыпанов
wrote:
>> There is an optimization opportunity for the widespread use-case when a
>> resource is read from classpath using
>> `getClass().getClassLoader().getResource()` or
>> `getClass().getClassLoader().getResourceAsStream()`.
>>
>> Pay atten
On Mon, 26 Jul 2021 08:27:20 GMT, Сергей Цыпанов
wrote:
>> After I've renamed remove branch GitHub for some reason has closed original
>> https://github.com/openjdk/jdk/pull/2744, so I've decided to recreate it.
>
> Сергей Цыпанов has updated the pull request with a new target base due to a
>
On Wed, 17 Feb 2021 16:38:03 GMT, Сергей Цыпанов
wrote:
>> Non-static classes hold a link to their parent classes, which in many cases
>> can be avoided.
>
> Сергей Цыпанов has updated the pull request incrementally with one additional
> commit since the last revision:
>
> 8261880: Remove s
On Thu, 18 Mar 2021 17:02:57 GMT, Alex Blewitt
wrote:
>> Sonar displays a warning message that modifiers should be declared in the
>> order listed in the JLS; specifically, that isntead of using `final static`
>> the `static final` should be preferred.
>>
>> This fixes the issues in the `java
On Thu, 18 Mar 2021 17:06:04 GMT, Alex Blewitt
wrote:
>>> If I have other fixes for different modules, should I file PRs with the
>>> same bug number e.g. "8263658: Use the blessed modifier order in
>>> java.logging/java.desktop" or should we have separate bug numbers for them?
>>
>> Separate
On Thu, 18 Mar 2021 16:51:35 GMT, Alex Blewitt
wrote:
> If I have other fixes for different modules, should I file PRs with the same
> bug number e.g. "8263658: Use the blessed modifier order in
> java.logging/java.desktop" or should we have separate bug numbers for them?
Separate bug numbers
On Thu, 18 Mar 2021 16:42:39 GMT, Alex Blewitt
wrote:
>> Yeah, I agree.
>
> Is that there to indicate a placeholder value that was once used and is kept
> for documentation purposes? Should the corresponding JavaDoc be removed as
> well? Should I do this in the same commit/PR as this one, or s
On Sat, 13 Mar 2021 22:45:30 GMT, Alex Blewitt
wrote:
> Sonar displays a warning message that modifiers should be declared in the
> order listed in the JLS; specifically, that isntead of using `final static`
> the `static final` should be preferred.
>
> This fixes the issues in the `java.base
On Wed, 17 Feb 2021 16:35:02 GMT, liach
wrote:
>> I'll just revert them
>
> For static methods, since in java language you cannot declare static method
> in instance inner classes, I'd say making them static makes more sense
> language-wise. Also making them static reduces compiler synthetic i
On Tue, 16 Feb 2021 14:30:58 GMT, Сергей Цыпанов
wrote:
> Non-static classes hold a link to their parent classes, which in many cases
> can be avoided.
src/java.base/share/classes/java/lang/invoke/DelegatingMethodHandle.java line
192:
> 190:
> 191: /* Placeholder class for DelegatingMet
On Wed, 27 Jan 2021 19:03:38 GMT, Sean Mullan wrote:
>> Claes Redestad has updated the pull request incrementally with two
>> additional commits since the last revision:
>>
>> - Copyrights
>> - Same for Windows
>
> Marked as reviewed by mullan (Reviewe
On Wed, 27 Jan 2021 14:47:08 GMT, Claes Redestad wrote:
> 8260520: Avoid getting permissions in JarFileFactory when no SecurityManager
> installed
This pull request has now been integrated.
Changeset: 8fe1323d
Author: Claes Redestad
URL: https://git.openjdk.java.net/jdk/
> 8260520: Avoid getting permissions in JarFileFactory when no SecurityManager
> installed
Claes Redestad has updated the pull request incrementally with two additional
commits since the last revision:
- Copyrights
- Same for Windows
-
Changes:
- all:
On Wed, 27 Jan 2021 16:57:25 GMT, Sean Mullan wrote:
> Will you make the same change to
> `src/java.base/windows/classes/sun/net/www/protocol/jar/JarFileFactory.java`?
Good catch. Let's keep things consistent. :-)
-
PR: https://git.openjdk.java.net/jdk/pull/2263
On Wed, 27 Jan 2021 14:54:33 GMT, Alan Bateman wrote:
>> 8260520: Avoid getting permissions in JarFileFactory when no SecurityManager
>> installed
>
> Should be okay as the side effect of getPermission is not observable. Make
> sure to run all the tests before integrating.
@AlanBateman @dfuch
8260520: Avoid getting permissions in JarFileFactory when no SecurityManager
installed
-
Commit messages:
- Avoid getting permissions when there's no SM installed
Changes: https://git.openjdk.java.net/jdk/pull/2263/files
Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2263&r
On Thu, 21 Jan 2021 10:11:11 GMT, Eirik Bjorsnos
wrote:
>> By moving string splitting and concatenation into the canonizeString
>> utility, we can defer allocation until we determine that canonization is
>> required. This saves two string allocations and a string concat for the
>> common case
On Wed, 20 Jan 2021 15:25:18 GMT, eirbjo
wrote:
> By moving string splitting and concatenation into the canonizeString utility,
> we can defer allocation until we determine that canonization is required.
> This saves two string allocations and a string concat for the common case
> where canon
On Thu, 14 Jan 2021 11:48:16 GMT, Claes Redestad wrote:
>> @cl4es SB brings pessimization both for time and memory, try
>> `org.openjdk.bench.java.net.URLEncodeDecode`:
>> master
>> (count) (maxLength)
>> (my
On Thu, 14 Jan 2021 09:31:19 GMT, Сергей Цыпанов
wrote:
>> Looks good.
>>
>> I wonder... `CharArrayWriter` is an old and synchronized data structure, and
>> since the instance used here isn't shared that synchronization seem useless.
>> And since you're now bypassing the `char[]` and going st
On Thu, 3 Dec 2020 14:29:58 GMT, Сергей Цыпанов
wrote:
> Instead of allocating a copy of underlying array via
> `CharArrayWriter.toCharArray()` and passing it to constructor of String
> String str = new String(charArrayWriter.toCharArray());
> we could call `toString()` method
> String str = ch
On Fri, 6 Nov 2020 20:11:24 GMT, Pavel Rappo wrote:
> This PR proposes to remove
> 1. JavaDoc `@author` tags with unclear semantics: `@author
> unascribed|unattributed|unknown`
> 2. A couple of astray Form Feed (a.k.a. FF, `\f`, `0xC`, or `^L`) characters
A removed @author tag is a good @autho
On Thu, 22 Oct 2020 20:46:15 GMT, Сергей Цыпанов
wrote:
> As discussed in https://github.com/openjdk/jdk/pull/510 there is never a
> reason to explicitly instantiate any instance of `Atomic*` class with its
> default value, i.e. `new AtomicInteger(0)` could be replaced with `new
> AtomicInteg
On Thu, 22 Oct 2020 20:46:15 GMT, Сергей Цыпанов
wrote:
> As discussed in https://github.com/openjdk/jdk/pull/510 there is never a
> reason to explicitly instantiate any instance of `Atomic*` class with its
> default value, i.e. `new AtomicInteger(0)` could be replaced with `new
> AtomicInteg
On 2020-08-27 16:11, Alan Bateman wrote:
For the micro, I'm curious if iterations is needed.
I'd say the canonical JMH way of doing these might be something as
simple as this:
@Benchmark
public URI encodeURI() throws URISyntaxException {
return new URI("http", "\u00A0", "\u
On 2020-04-06 13:22, Chris Hegarty wrote:
Bug:https://bugs.openjdk.java.net/browse/JDK-8242186
Let me know if there are any concerns, otherwise I'll push
once tier1 testing comes back green. Thanks!
Thanks all for this nice micro-optimization. The changes look good to me.
-Chris.
Thanks,
7;/');
Bug: https://bugs.openjdk.java.net/browse/JDK-8242186
Let me know if there are any concerns, otherwise I'll push
once tier1 testing comes back green. Thanks!
/Claes
On 2020-04-05 19:48, Claes Redestad wrote:
Hi Christoph,
looks good and trivial. I'll sponsor.
/Claes
On 202
On 2020-02-14 13:01, Chris Hegarty wrote:
http://cr.openjdk.java.net/~pconcannon/8237480/webrevs/webrev.03/
LGTM.
+1
/Claes
Hi,
looks reasonable to me.
To keep default execution times at a manageable level, I'd recommend
excluding some of the 9 values for the size parameter (3-5 values seem
reasonable).
/Claes
On 2020-02-12 16:04, Patrick Concannon wrote:
Hi,
Could someone please review my webrev for JDK-8237480
On 2019-07-19 15:28, Chris Hegarty wrote:
Nice cleanup! Reviewed.
Thanks for reviewing, Chris!
/Claes
On 2019-07-19 15:01, Alan Bateman wrote:
This looks good to me.
Thanks for reviewing, Alan!
/Claes
Hi,
please review this cleanup to remove a few java.net access objects that
are no longer in use.
Webrev: http://cr.openjdk.java.net/~redestad/8228394/open.00/
Bug:https://bugs.openjdk.java.net/browse/JDK-8228394
(One usage was from sun.misc.ClassLoaderUtil, removed by
https://bugs.openjdk
lize the two paths
during bootstrap and put them in final fields.
These are pre-existing issues though, so I think I'll take my reviews
and push this enhancement for now. :-)
Thanks!
/Claes
Regards, Peter
On 7/16/19 3:48 PM, Claes Redestad wrote:
Hi,
refactored to use a BootLoader::loa
On 2019-07-16 17:11, Vyom Tewari26 wrote:
Looks good to me.
Vyom
Thanks for reviewing, Vyom
/Claes
On 2019-07-16 17:01, Chris Hegarty wrote:
On 16 Jul 2019, at 15:06, Claes Redestad wrote:
Webrev: http://cr.openjdk.java.net/~redestad/8227720/open.00/
This looks good to me Claes. Thanks for doing it. Reviewed.
Thanks for reviewing, Chris!
/Claes
Hi,
a small cleanup and startup optimization for apps that setup and/or use
sockets of various kinds, which pulls in ExtendedSocketOptions. By being
slightly more eager we avoid a few potentially costly streams (featuring
capturing lambdas) that we'd end up calling eagerly from places like
Abstra
skips the security
permission overhead and only for boot loader use. It would require
refactoring.
I think java.base and java.desktop having its own utility method is
a simpler solution.
Mandy
On 7/12/19 7:55 AM, Claes Redestad wrote:
Hi,
I'm dropping the java.desktop changes, and Mandy
9 10:39 AM, Claes Redestad wrote:
Hi Roger,
On 2019-07-11 16:10, Roger Riggs wrote:
Hi Claes,
JavaLangAccess.java:
316: Add @param tag
done.
System.java: 2282, 2287
Runtime.loadLibrary0 makes a second check for a security manager.
Is there any potential gain by calling ClassLoader.loadLibrar
Hi Roger,
On 2019-07-11 16:10, Roger Riggs wrote:
Hi Claes,
JavaLangAccess.java:
316: Add @param tag
done.
System.java: 2282, 2287
Runtime.loadLibrary0 makes a second check for a security manager.
Is there any potential gain by calling ClassLoader.loadLibrary directly?
None of the interna
Hi,
by adding a method to load libraries with privileges to JavaLangAccess,
we can simplify a slew of places where we are currently implementing
adhoc privileged actions. This is a tiny but measurable gain on a range
of startup tests.
Webrev: http://cr.openjdk.java.net/~redestad/8227587/open.00
Thanks, Daniel!
/Claes
On 2019-07-05 12:07, Daniel Fuchs wrote:
Hi Claes,
That looks like a good cleanup and improvement.
Thanks for having looked into this!
best regards,
-- daniel
On 04/07/2019 21:20, Claes Redestad wrote:
Hi,
please review this patch that refactors native
Thanks, Michael!
/Claes
On 2019-07-05 10:02, Michael McMahon wrote:
Claes,
This is great work and long overdue.
Thanks for taking care of it.
- Michael.
On 04/07/2019, 20:20, Claes Redestad wrote:
Hi,
please review this patch that refactors native java.net.NetworkInterface
lookup logic in
Hi,
please review this patch that refactors native java.net.NetworkInterface
lookup logic in a few ways to address both pre-existing and recent
regressions:
Bug:https://bugs.openjdk.java.net/browse/JDK-8225239
Webrev: http://cr.openjdk.java.net/~redestad/8225239/open.01/
- adds a package-pr
On 2019-05-02 15:20, Seán Coffey wrote:
Hi Claes,
Yes - looks like a fine suggestion.
http://cr.openjdk.java.net/~coffeys/webrev.8217364.03/webrev/
Looks good to me.. ;-)
/Claes
Hi Seán,
wouldn't it be more straightforward then to keep the logic intact and
skip the custom factory invocation in both cases if the protocol is
non-overrideable?
I.e., something like this:
diff -r 290283590646 src/java.base/share/classes/java/net/URL.java
--- a/src/java.base/share/classes/ja
Hi,
On 2019-01-02 11:04, Alan Bateman wrote:
On 02/01/2019 09:02, Claes Redestad wrote:
Hi,
during bootstrap we load and use at least two of the jrt, file and jar
URLStreamHandlers via URL$DefaultFactory. Avoiding use of reflection to
instantiate these slightly speed up bootstrap by reducing
Hi,
during bootstrap we load and use at least two of the jrt, file and jar
URLStreamHandlers via URL$DefaultFactory. Avoiding use of reflection to
instantiate these slightly speed up bootstrap by reducing number of
classes loaded and doing fewer relatively expensive reflective
operations:
http:/
On 2018-12-13 14:06, Daniel Fuchs wrote:
Looks good Claes!
Thanks!
I eyeballed the rest of the patch and found
nothing wrong - but with a patch this size
it would be easy to miss something.
Yes, I've gone through it a couple of times now
to be sure.
Were you able to measure any improveme
On 2018-12-12 17:54, Daniel Fuchs wrote:
Hi Claes,
It might read even better if things like:
+ resultString = !specarg.isEmpty() ? specarg.intern(): opt;
were changed into:
+ resultString = specarg.isEmpty() ? opt : specarg.intern();
best regards,
I only found this pattern
On 2018-12-12 17:56, Alan Bateman wrote:
In Checks.java, the parameter change from CharSequence to String means
that "cs" needs to be renamed.
Changed to 'str'
/Claes
Hi,
please review this patch to use String.isEmpty when applicable:
Webrev: http://cr.openjdk.java.net/~redestad/8215281/jdk.00/
Bug: https://bugs.openjdk.java.net/browse/JDK-8215281
Why?
- It reads better :-)
- Better startup/warmup due fewer method invocations
- Better peak performance: Strin
Looks good to me.
/Claes
On 2018-03-14 15:30, Alan Bateman wrote:
Classic networking has some curious code to deal with connection
resets. I needed to dig into ancient history to find the issues and
original motivations.
When a connection reset is reported (usually ECONNRESET) then further
Thanks for reviewing, Roger
/Claes
On 2018-02-14 17:50, Roger Riggs wrote:
Hi Claes,
Looks fine,
Roger
On 2/14/2018 11:36 AM, Claes Redestad wrote:
Right, I expanded the range as much as possible given the constraint
provided by L_ENCODED minus '/'. I will think of a better
this would deserve some additional
>comment - though I'm not sure how it could be formulated.
>
>Given the sensitivity of the impacted code maybe it would
>be prudent to wait for a second review before pushing.
>
>best regards,
>
>-- daniel
>
>On 14/02/2018 15:30, Cl
Hi,
as a means to improve startup in some applications, please review this
set of small improvements to improve both interpreted and compiled
performance of creating and handling certain jar URLs. Some of the
changes in sun.net.www.ParseUtil::encodePath have a small, positive
effect when deal
On 2017-08-30 18:26, Alan Bateman wrote:
This looks good to me.
Thanks, Alan!
/Claes
On 2017-08-30 18:18, Chris Hegarty wrote:
Thanks for doing this Claes, this latest version looks good to me.
Thanks Chris!
/Claes
e the expected value?
This is just a suggestion, and it
could be done in a followup RFE...
best regards,
-- daniel
On 31/08/2017 16:26, Claes Redestad wrote:
On 2017-08-30 17:17, Alan Bateman wrote:
I think it could be useful as someone reading the code isn't going
to immediately know to j
On 2017-08-30 17:17, Alan Bateman wrote:
I think it could be useful as someone reading the code isn't going to
immediately know to jump to URI.
Done: http://cr.openjdk.java.net/~redestad/8186930/jdk.01/
/Claes
On 2017-08-30 16:10, Alan Bateman wrote:
On 29/08/2017 21:26, Claes Redestad wrote:
Webrev: http://cr.openjdk.java.net/~redestad/8186930/jdk.00/
This looks good to me.
Thanks!
I just wonder if ParseUtil should keep the lowMask/highMask methods in
comments so that further maintainers can
Hi,
please review this patch to pre-calculate constants in java.net.URI and
sun.net.www.ParseUtil, removing work from runtime (reduces bytecodes
executed in the interpreter on bootstrap by ~15K).
This also removes use of BitSet from ParseUtil, which apart from being a
startup improvement also yi
re will not be any overflow. If
you try to set very large number like "0x7fff" to int data
type you will get compile time error(integer number too large:
7fff).
Thanks,
Vyom
On Tuesday 09 May 2017 11:20 PM, Claes Redestad wrote:
Hi,
doesn't this need to
Hi,
doesn't this need to consider numerical overflows, e.g., what happens if
someone sets a timeout value near 0x7fffL before and after
this change?
/Claes
On 2017-05-09 11:55, Vyom Tewari wrote:
Hi ,
Please review the code change for below issue.
Webrev :
http://cr.openjdk.
Hi,
some users reports high allocation rates in ParseUtil.encodePath,
regardless of whether paths actually need to be encoded or not.
Since this is a commonly used utility it makes sense.
Webrev: http://cr.openjdk.java.net/~redestad/8170785/webrev.01
Bug: https://bugs.openjdk.java.net/browse/JDK
On 2016-06-17 16:26, Chris Hegarty wrote:
On 17/06/16 15:05, Claes Redestad wrote:
On 2016-06-17 16:04, Alan Bateman wrote:
On 17/06/2016 14:43, Claes Redestad wrote:
Hi,
URL.java defines a package-private class Parts, which can be
trivially inlined in the one place where it&#
On 2016-06-17 16:04, Alan Bateman wrote:
On 17/06/2016 14:43, Claes Redestad wrote:
Hi,
URL.java defines a package-private class Parts, which can be
trivially inlined in the one place where it's currently used.
Webrev: http://cr.openjdk.java.net/~redestad/8159745/webrev.01/
Bug:
Hi,
URL.java defines a package-private class Parts, which can be trivially
inlined in the one place where it's currently used.
Webrev: http://cr.openjdk.java.net/~redestad/8159745/webrev.01/
Bug: https://bugs.openjdk.java.net/browse/JDK-8159745
Thanks!
/Claes
Thanks for the quick review Chris,
I'll push as soon as JPRT runs look green.
/Claes
On 04/18/2016 04:45 PM, Chris Hegarty wrote:
Looks ok Claes.
-Chris.
On 18/04/16 15:38, Claes Redestad wrote:
Hi,
a small omission in JDK-8154238 cause Windows builds to fail. Sorry
about that, see
Hi,
a small omission in JDK-8154238 cause Windows builds to fail. Sorry
about that, see patch to fix this below (I was 100% certain I had run this
through JPRT last week)
Bug: https://bugs.openjdk.java.net/browse/JDK-8154454
Thanks!
/Claes
diff -r 3459ee432728
src/java.base/windows/classes
On 04/18/2016 12:06 PM, Chris Hegarty wrote:
On 18/04/16 11:01, Alan Bateman wrote:
On 18/04/2016 10:45, Chris Hegarty wrote:
The changes look fine.
Maybe the bug description should be updated a before pushing,
it looks like it affects only legacy networking code and not
NIO. Maybe "... and a
On 04/18/2016 12:01 PM, Alan Bateman wrote:
On 18/04/2016 10:45, Chris Hegarty wrote:
The changes look fine.
Maybe the bug description should be updated a before pushing,
it looks like it affects only legacy networking code and not
NIO. Maybe "... and async channels" ?
The changes to the NIO c
On 04/18/2016 11:45 AM, Chris Hegarty wrote:
On 14/04/16 13:49, Claes Redestad wrote:
Hi,
more code in the Windows socket implementation that can be dropped
Bug: https://bugs.openjdk.java.net/browse/JDK-8154238
Webrev: http://cr.openjdk.java.net/~redestad/8154238/webrev.01/
The changes look
Hi,
more code in the Windows socket implementation that can be dropped
Bug: https://bugs.openjdk.java.net/browse/JDK-8154238
Webrev: http://cr.openjdk.java.net/~redestad/8154238/webrev.01/
Thanks!
/Claes
On 04/13/2016 11:43 PM, Chris Hegarty wrote:
On 13 Apr 2016, at 22:31, Claes Redestad wrote:
Hi,
since we're dropping support for Windows XP in JDK 9, we can simplify
initialization of DefaultDatagramSocketImplFactory.
Bug: https://bugs.openjdk.java.net/browse/JDK-8154185
Webrev:
Hi,
since we're dropping support for Windows XP in JDK 9, we can simplify
initialization of DefaultDatagramSocketImplFactory.
Bug: https://bugs.openjdk.java.net/browse/JDK-8154185
Webrev: http://cr.openjdk.java.net/~redestad/8154185/webrev.01/
Thanks!
/Claes
On 2016-03-08 14:42, Michael McMahon wrote:
Iterator-based removal would work, or building a new list to replace
pending with might be more efficient. The synchronization scheme
seems a bit flaky as well?
The new code is always called from the same thread. So, I don't see an
issue?
Ri
Hi Michael,
On 2016-03-08 12:27, Michael McMahon wrote:
Could I get the following webrev reviewed please?
http://cr.openjdk.java.net/~michaelm/8151299/webrev.1/
get on LinkedList is O(n), so the for-loop in resetInterestOps sneakily
has quadratic complexity. One of many reasons ArrayList is
Joe, Chris,
thanks for reviewing. Pushed.
/Claes
On 2016-01-31 17:13, Chris Hegarty wrote:
On 31 Jan 2016, at 00:58, Claes Redestad wrote:
Hi,
On 2016-01-30 19:35, joe darcy wrote:
Hello,
The change looks okay in that the new code is limited to the jrt protocol. I
assume the failing
-libs-dev/2016-January/038459.html).
I'm ready push this, but might be good to get a second opinion from
net-dev to ensure they aren't caught unaware of this follow-up fix.
Thanks!
/Claes
Thanks,
-Joe
On 1/30/2016 6:30 AM, Claes Redestad wrote:
Hi,
it turns out trying to opti
On 2016-01-28 20:56, Alan Bateman wrote:
This looks okay. I think it would be good to put a javadoc comment on
this method, also maybe move it to below all the constructors rather
than in the middle.
-Alan.
Sure, as this is package-private API a short description and reference
to the UR
On 2016-01-28 16:52, Chris Hegarty wrote:
...
This looks fine Claes.
Thanks, Chris!
Maybe just a comment on the fact that character based comparison is
being used for perf reasons.
In an older version of the webrev, there was an updated to an existing test,
test/java/net/URI/URItoURLTest
On 2016-01-18 17:20, Claes Redestad wrote:
The ability for URLStreamHandler implementations to override the
parseURL method seem to prevent this improvement unless we only do
this for a subset of known, well-behaved URLStreamHandlers, which
likely defeat the optimization by adding
On 2016-01-22 14:38, Alan Bateman wrote:
On 22/01/2016 12:29, Claes Redestad wrote:
:
http://cr.openjdk.java.net/~redestad/8147962/webrev.02/
This looks good to me.
-Alan
Thanks!
/Claes
On 2016-01-22 12:29, Alan Bateman wrote:
On 21/01/2016 17:27, Claes Redestad wrote:
Hi,
using String.toLowerCase() in URL allows some strings to lower-case
to a string that'd be invalid, e.g. "FILE".toLowerCase() ->
"f\u0131le" in turkish locales.
This pat
Hi,
using String.toLowerCase() in URL allows some strings to lower-case to a
string that'd be invalid, e.g. "FILE".toLowerCase() -> "f\u0131le" in
turkish locales.
This patch suggests using the locale-independent
String.toLowerCase(Locale.ENGLISH) instead, since only a-z and A-Z are
legal a
On 2016-01-18 15:34, Chris Hegarty wrote:
On 18/01/16 14:09, Alan Bateman wrote:
On 17/01/2016 15:30, Claes Redestad wrote:
Hi,
please review this patch which might make URI.toURL more efficient
Webrev: http://cr.openjdk.java.net/~redestad/8147462
Bug: https://bugs.openjdk.java.net/browse
Hi,
please review this patch which might make URI.toURL more efficient
Webrev: http://cr.openjdk.java.net/~redestad/8147462
Bug: https://bugs.openjdk.java.net/browse/JDK-8147462
This patch exploits the fact that URI will apply the same validation to
the URI/URL specification for any valid non-
On 2016-01-10 10:39, Chris Hegarty wrote:
On 8 Jan 2016, at 14:41, Claes Redestad wrote:
Hi,
please review this patch to lazily create schemeSpecificPart for non-opaque
URIs. This change accounts for some improvement in footprint characteristics
and a 10-20% improvement on URI creation
On 2016-01-08 16:34, Alan Bateman wrote:
On 08/01/2016 14:41, Claes Redestad wrote:
Hi,
please review this patch to lazily create schemeSpecificPart for
non-opaque URIs. This change accounts for some improvement in
footprint characteristics and a 10-20% improvement on URI creation
Hi,
please review this patch to lazily create schemeSpecificPart for
non-opaque URIs. This change accounts for some improvement in footprint
characteristics and a 10-20% improvement on URI creation
microbenchmarks, while not regressing notably on a targetted
microbenchmark which explicitly ge
On 2016-01-06 08:43, Alan Bateman wrote:
On 05/01/2016 22:47, Claes Redestad wrote:
Hi,
please review this patch to cleanup URI$Parser to help URI
construction when run with the interpreter, mostly by inlining
wrapping methods:
Bug: https://bugs.openjdk.java.net/browse/JDK-8146526
Webrev
Hi,
please review this patch to cleanup URI$Parser to help URI construction
when run with the interpreter, mostly by inlining wrapping methods:
Bug: https://bugs.openjdk.java.net/browse/JDK-8146526
Webrev: http://cr.openjdk.java.net/~redestad/8146526/webrev.01
This is motivated by Jigsaw whe
Looks good to me.
/Claes (not a Reviewer)
On 2015-08-21 21:49, Rob McKenna wrote:
Hi folks, looking for a review for this simple change.
The change for https://bugs.openjdk.java.net/browse/JDK-8040747
initialised each octet to 0. This meant that ... was translated to
0.0.0.0 before checking
1 - 100 of 111 matches
Mail list logo
