On Mon, 26 Jun 2023 14:58:56 GMT, Tingjun Yuan wrote:
> This PR changes the implementation of `Long.toUnsignedString(long, int)` for
> "default" radices, which avoids creating a `BigInteger` and makes use of
> `Long.divideUnsigned` and `Long.remainderUnsigned`.
>
> I
Longs.toUnsignedStringNegative 500 avgt 15 3823.655 ± 146.171 us/op
>
>
> I've submitted a bug report for this to the [Java Bug
> Database](https://bugs.java.com/bugdatabase/). No CSR needed since the
> behavior is not changed.
Tingjun Yuan has updated
On Mon, 26 Jun 2023 14:58:56 GMT, Tingjun Yuan wrote:
> This PR changes the implementation of `Long.toUnsignedString(long, int)` for
> "default" radices, which avoids creating a `BigInteger` and makes use of
> `Long.divideUnsigned` and `Long.remainderUnsigned`.
>
> I
This PR changes the implementation of `Long.toUnsignedString(long, int)` for
"default" radices, which avoids creating a `BigInteger` and makes use of
`Long.divideUnsigned` and `Long.remainderUnsigned`.
I've run the test on `test/jdk/java/lang/Long/Unsigned.java` and it works
correctly. I believ
On Sun, 9 Apr 2023 02:28:37 GMT, Tingjun Yuan wrote:
>> In the current implementation of `String.join(CharSequence, Iterable)`, the
>> temp array `elems` is always initialized with a length of 8. It will cause
>> many array recreations when the `Iterable` contains mo
er this change requires a CSR request.
Tingjun Yuan has updated the pull request incrementally with one additional
commit since the last revision:
use spliterator().estimateSize()
-
Changes:
- all: https://git.openjdk.org/jdk/pull/13383/files
- new: https://git.openjdk.org/jd
On Sun, 9 Apr 2023 02:28:37 GMT, Tingjun Yuan wrote:
>> In the current implementation of `String.join(CharSequence, Iterable)`, the
>> temp array `elems` is always initialized with a length of 8. It will cause
>> many array recreations when the `Iterable` contains mo
On Sun, 9 Apr 2023 02:28:37 GMT, Tingjun Yuan wrote:
>> In the current implementation of `String.join(CharSequence, Iterable)`, the
>> temp array `elems` is always initialized with a length of 8. It will cause
>> many array recreations when the `Iterable` contains mo
On Mon, 10 Apr 2023 04:57:09 GMT, Glavo wrote:
>> Tingjun Yuan has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Add benchmark
>
> If you really don't trust a collection, then we can't do anything.
On Mon, 10 Apr 2023 04:28:34 GMT, Chen Liang wrote:
>> Nah. I mean like:
>>
>> public static String join(CharSequence delimiter,
>> Iterable elements) {
>> Objects.requireNonNull(delimiter);
>> Objects.requireNonNull(elements);
>> var delim = delimiter.toS
On Mon, 10 Apr 2023 03:36:44 GMT, Chen Liang wrote:
>> Tingjun Yuan has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Add benchmark
>
> Nah. I mean like:
>
> public static String join(CharSequen
On Sun, 9 Apr 2023 02:28:37 GMT, Tingjun Yuan wrote:
>> In the current implementation of `String.join(CharSequence, Iterable)`, the
>> temp array `elems` is always initialized with a length of 8. It will cause
>> many array recreations when the `Iterable` contains mo
On Mon, 10 Apr 2023 03:04:20 GMT, Chen Liang wrote:
>> @liach Working on that.
>
> @yuantj Alternatively, you can probably try working on the `toArray` result
> of a collection than to allocate a new String array. This might be more
> efficient for some implementations like ArrayList as well, i
On Sun, 9 Apr 2023 02:37:45 GMT, Tingjun Yuan wrote:
>> This appears to be a 4% improvement for non-concurrent structures like
>> ArrayList or LinkedHashSet, if we ignore the baseline difference (for
>> Iterable). This is anticipated as the growth of array size is exponential
On Sun, 9 Apr 2023 02:33:07 GMT, Chen Liang wrote:
>> Tingjun Yuan has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Add benchmark
>
> This appears to be a 4% improvement for non-concurrent structures like
On Sun, 9 Apr 2023 02:11:44 GMT, jmehrens wrote:
>> In the current implementation of `String.join(CharSequence, Iterable)`, the
>> temp array `elems` is always initialized with a length of 8. It will cause
>> many array recreations when the `Iterable` contains more than 8 elements.
>> Furtherm
On Fri, 7 Apr 2023 08:27:18 GMT, Tingjun Yuan wrote:
> In the current implementation of `String.join(CharSequence, Iterable)`, the
> temp array `elems` is always initialized with a length of 8. It will cause
> many array recreations when the `Iterable` contains more than 8
er this change requires a CSR request.
Tingjun Yuan has updated the pull request incrementally with one additional
commit since the last revision:
Add benchmark
-
Changes:
- all: https://git.openjdk.org/jdk/pull/13383/files
- new: https://git.openjdk.org/jdk/pull/13383/files
On Sat, 8 Apr 2023 23:18:04 GMT, Chen Liang wrote:
>> In the current implementation of `String.join(CharSequence, Iterable)`, the
>> temp array `elems` is always initialized with a length of 8. It will cause
>> many array recreations when the `Iterable` contains more than 8 elements.
>> Furthe
In the current implementation of `String.join(CharSequence, Iterable)`, the
temp array `elems` is always initialized with a length of 8. It will cause many
array recreations when the `Iterable` contains more than 8 elements.
Furthermore, it's very common that an `Iterable` is also a `Collection`
On Thu, 6 Apr 2023 00:49:33 GMT, Tingjun Yuan wrote:
> Fix a typo in the specification of
> `java.util.LinkedHashMap.removeEldestEntry(Map.Entry)`.
>
>> This is the entry that will be removed **it** this method returns `true`.
>
> will become:
>
>> This is the e
Fix a typo in the specification of
`java.util.LinkedHashMap.removeEldestEntry(Map.Entry)`.
> This is the entry that will be removed **it** this method returns `true`.
will become:
> This is the entry that will be removed **if** this method returns `true`.
-
Commit messages:
- Fix
On Mon, 3 Apr 2023 10:23:03 GMT, Alan Bateman wrote:
> > Are there more places where we "accidentally" expose interfaces via
> > non-public (or even public) super classes?
>
> Appendable was added as part of the scanning/formatting update in Java 5.
> It's intentional that SB implements Append
On Sat, 1 Apr 2023 17:34:37 GMT, Joe Darcy wrote:
> The StringBuilder and StringBuffer classes are Appendable by virtue of from
> subclasses their non-public superclass AbstractStringBuilder.
>
> It is slightly clearer to declare StringBuilder and StringBuffer to directly
> implement Appendabl
On Sun, 29 Jan 2023 01:54:02 GMT, Tingjun Yuan wrote:
> Add `java.io.PrintOutput` to represent print operations, and modify
> `java.io.PrintStream` and `java.io.PrintWriter` to implement it.
This pull request has been closed without being integrated.
-
PR: https://git.openj
On Tue, 21 Mar 2023 23:41:44 GMT, Claes Redestad wrote:
>> Tingjun Yuan has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Set.copyOf: need defensive copy
>
> If this level of complexity is indeed need
On Tue, 21 Feb 2023 03:39:46 GMT, Tingjun Yuan wrote:
>> Currently, the two subclasses of `java.util.EnumSet` optimize bulk
>> operations when the argument is also a `EnumSet`, but there is no such
>> optimization for wrapper sets (returned by `Collectio
(returned by `Set.of`
> methods) of `Enum`s.
>
> This PR introduces optimization classes for these situations. No public APIs
> are changed.
Tingjun Yuan has updated the pull request incrementally with one additional
commit since the last revision:
Fix a whitespace error
---
(returned by `Set.of`
> methods) of `Enum`s.
>
> This PR introduces optimization classes for these situations. No public APIs
> are changed.
Tingjun Yuan has updated the pull request incrementally with one additional
commit since the last revision:
Delete compatible interfaces an
On Tue, 21 Feb 2023 03:39:46 GMT, Tingjun Yuan wrote:
>> Currently, the two subclasses of `java.util.EnumSet` optimize bulk
>> operations when the argument is also a `EnumSet`, but there is no such
>> optimization for wrapper sets (returned by `Collectio
(returned by `Set.of`
> methods) of `Enum`s.
>
> This PR introduces optimization classes for these situations. No public APIs
> are changed.
Tingjun Yuan has updated the pull request incrementally with one additional
commit since the last revision:
Set.copyOf: need defensive copy
(returned by `Set.of`
> methods) of `Enum`s.
>
> This PR introduces optimization classes for these situations. No public APIs
> are changed.
Tingjun Yuan has updated the pull request incrementally with one additional
commit since the last revision:
Fix `Set.copyOf`
-
On Mon, 20 Feb 2023 13:58:01 GMT, liach wrote:
> no, Set.copyOf explicitly allows duplications, unlike Set.of. You need to
> read the specs so you know what you are doing.
Sorry, my bad. I've fixed that.
-
PR: https://git.openjdk.org/jdk/pull/12498
On Mon, 20 Feb 2023 13:29:52 GMT, Tingjun Yuan wrote:
> I wonder why the original code didn't use `addAll`, so I didn't change it. 😂
It seems to be okay to use `addAll` in all cases. Do we need extra test cases
for this?
-
PR: https://git.openjdk.org/jdk/pull/12498
(returned by `Set.of`
> methods) of `Enum`s.
>
> This PR introduces optimization classes for these situations. No public APIs
> are changed.
Tingjun Yuan has updated the pull request incrementally with one additional
commit since the last revision:
Use `addAll` in `EnumSet.copyOf`
On Mon, 20 Feb 2023 13:16:09 GMT, liach wrote:
>> Tingjun Yuan has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Optimize `EnumSet.copyOf` and `Set.copyOf`
>
> src/java.base/share/classes/java/util/En
On Mon, 20 Feb 2023 13:15:20 GMT, liach wrote:
> Bad change, doesn't handle e0.equals(e1), and this is getting beyond the
> original issue
`Set.of(E, E)` handles duplication. If `coll` is
`{Jumbo,Regular}EnumSetCompatible`, then we don't have to create the `HashSet`.
-
PR: https:
(returned by `Set.of`
> methods) of `Enum`s.
>
> This PR introduces optimization classes for these situations. No public APIs
> are changed.
Tingjun Yuan has updated the pull request incrementally with one additional
commit since the last revision:
Optimize `EnumSet
On Thu, 9 Feb 2023 16:20:31 GMT, Tingjun Yuan wrote:
> Currently, the two subclasses of `java.util.EnumSet` optimize bulk operations
> when the argument is also a `EnumSet`, but there is no such optimization for
> wrapper sets (returned by `Collections.unmodi
On Thu, 9 Feb 2023 19:37:03 GMT, liach wrote:
> Just curious, how does this enum set change affect the performance of
> construction of regular sets via Set.of calls?
See `ImmutableCollections.setFromArray`, it relies on the fact that
`EnumSet.copyOf` will throw a `ClassCastException` if the e
Currently, the two subclasses of `java.util.EnumSet` optimize bulk operations
when the argument is also a `EnumSet`, but there is no such optimization for
wrapper sets (returned by `Collections.unmodifiableSet`,
`Collections.synchronizedSet`, etc.) and immutable sets (returned by `Set.of`
metho
On Mon, 23 Jan 2023 02:35:19 GMT, Tingjun Yuan wrote:
> Document `java.util.Arrays.asList` that the list will throw an
> `ArrayStoreException` when attempting to set an element with a wrong type.
This pull request has been closed without being integrated.
-
PR:
On Thu, 16 Feb 2023 04:39:20 GMT, Stuart Marks wrote:
>> I've written a CSR report for this PR as below. Could someone please help
>> me to submit it to the JBS if it looks okay? Thank you!
>>
>> ---
>>
>> **Compatibility Risk:** minimum
>>
>> **Compatibility Risk Description:** No implement
On Wed, 8 Feb 2023 23:33:20 GMT, Tingjun Yuan wrote:
>> Document `java.util.Arrays.asList` that the list will throw an
>> `ArrayStoreException` when attempting to set an element with a wrong type.
>
> Tingjun Yuan has updated the pull request incrementally with one addition
> Document `java.util.Arrays.asList` that the list will throw an
> `ArrayStoreException` when attempting to set an element with a wrong type.
Tingjun Yuan has updated the pull request incrementally with one additional
commit since the last revision:
Update Arrays.java
-
C
On Mon, 23 Jan 2023 07:33:21 GMT, Tingjun Yuan wrote:
>> Document `java.util.Arrays.asList` that the list will throw an
>> `ArrayStoreException` when attempting to set an element with a wrong type.
>
> Tingjun Yuan has updated the pull request incrementally with one addition
On Tue, 31 Jan 2023 18:28:59 GMT, Alan Bateman wrote:
> A PR may be a bit premature as this probably needs discussion first on
> whether this is worth doing. Yes, there are common methods between the two
> but at the same time, the byte and character hierarchies have always been
> distinct. Ha
On Mon, 30 Jan 2023 03:02:33 GMT, Glavo wrote:
> > Why not use set of classes?
>
> Because some classes are not visible here (such as `Arrays.ArrayList`).
>
> I'm not sure what the best choice is, so I'm trying to explore the
> implementation plan.
Only `Arrays.ArrayList` is not visible here.
On Mon, 30 Jan 2023 02:55:24 GMT, Glavo wrote:
>> I checked the `java.base` module, and all the `Collection#toArray()` method
>> of collections be implemented correctly.
>>
>> Their return values can be trusted, so many unnecessary array duplication
>> can be eliminated.
>
> Glavo has updated
On Sun, 29 Jan 2023 07:11:26 GMT, Tingjun Yuan wrote:
>> Add `java.io.PrintOutput` to represent print operations, and modify
>> `java.io.PrintStream` and `java.io.PrintWriter` to implement it.
>
> Tingjun Yuan has updated the pull request incrementally with one additional
messageSupplier)
> public static > L requireNoNulls(L list,
> IntFunction messageGenerator)
> public static > L requireNoNullsElseReplace(L
> list, IntFunction replaceFunction)
Tingjun Yuan has updated the pull request incrementally with one additional
commit since the last revisio
> Add `java.io.PrintOutput` to represent print operations, and modify
> `java.io.PrintStream` and `java.io.PrintWriter` to implement it.
Tingjun Yuan has updated the pull request incrementally with one additional
commit since the last revision:
Fix grammar mistakes in t
Add `java.io.PrintOutput` to represent print operations, and modify
`java.io.PrintStream` and `java.io.PrintWriter` to implement it.
-
Commit messages:
- remove `@since 1.5`
- Make PrintWriter implement PrintOutput
- Make PrintStream implement PrintOutput
- Create PrintOutput.jav
> Supplier messageSupplier)
> public static > M requireNoNulls(M map, Supplier
> messageSupplier)
> public static > L requireNoNulls(L list,
> IntFunction messageGenerator)
Tingjun Yuan has updated the pull request incrementally with two additional
commits since the last revis
> Supplier messageSupplier)
> public static > M requireNoNulls(M map, Supplier
> messageSupplier)
> public static > L requireNoNulls(L list,
> IntFunction messageGenerator)
Tingjun Yuan has updated the pull request incrementally with one additional
commit since the last revision
> Supplier messageSupplier)
> public static > M requireNoNulls(M map, Supplier
> messageSupplier)
> public static > L requireNoNulls(L list,
> IntFunction messageGenerator)
Tingjun Yuan has updated the pull request incrementally with one additional
commit since the last
Adding the following methods to check the nullity of elements of an array or a
collection:
java.util.Arrays:
public static E[] requireNoNulls(E[] array)
public static E[] requireNoNulls(E[] array, String message)
public static E[] requireNoNulls(E[] array, IntFunction
messageGenerator)
publi
On Fri, 27 Jan 2023 12:15:34 GMT, Glavo wrote:
> > What about Collections.synchronizedCollection and other methods that may
> > wrap/delagete to collections from other modules?
>
> Good question, I missed this point. I think I should provide a helper method
> to check whether the collection is
> Document `java.util.Arrays.asList` that the list will throw an
> `ArrayStoreException` when attempting to set an element with a wrong type.
Tingjun Yuan has updated the pull request incrementally with one additional
commit since the last revision:
Update `implSpec` and remove the d
> Document `java.util.Arrays.asList` that the list will throw an
> `ArrayStoreException` when attempting to set an element with a wrong type.
Tingjun Yuan has updated the pull request incrementally with two additional
commits since the last revision:
- Restore List.java
- Fix whit
> Modify `java.util.Arrays.ArrayList.{set,replaceAll}` to throw a
> `ClassCastException` (as documented in `java.util.List`) when attempting to
> set an element with a wrong type.
Tingjun Yuan has updated the pull request incrementally with one additional
commit since the last
> Modify `java.util.Arrays.ArrayList.{set,replaceAll}` to throw a
> `ClassCastException` (as documented in `java.util.List`) when attempting to
> set an element with a wrong type.
Tingjun Yuan has updated the pull request incrementally with one additional
commit since the last revisio
On Mon, 23 Jan 2023 06:29:47 GMT, Stuart Marks wrote:
> We don't want to change long-standing exception-throwing behavior for these
> cases. See my comments in
> [JDK-8296935](https://bugs.openjdk.org/browse/JDK-8296935).
Understand that, so I restored the current behavior and documented about
> Modify `java.util.Arrays.ArrayList.{set,replaceAll}` to throw a
> `ClassCastException` (as documented in `java.util.List`) when attempting to
> set an element with a wrong type.
Tingjun Yuan has updated the pull request incrementally with one additional
commit since the last
> Modify `java.util.Arrays.ArrayList.{set,replaceAll}` to throw a
> `ClassCastException` (as documented in `java.util.List`) when attempting to
> set an element with a wrong type.
Tingjun Yuan has updated the pull request incrementally with one additional
commit since the last
Modify `java.util.Arrays.ArrayList.{set,replaceAll}` to throw a
`ClassCastException` (as documented in `java.util.List`) when attempting to set
an element with a wrong type.
-
Commit messages:
- Modify Arrays.java
Changes: https://git.openjdk.org/jdk/pull/12135/files
Webrev: http
66 matches
Mail list logo
