Hi all,
could you please review this trivial cleanup?
from JBS:
> jtreg `@modules X` directive does two things:
> - exclude a test from execution if JDK under test doesn't have module X
> - if JDK under test has module X, make sure it's resolved
>
> both these things have no sense for
On 14/03/21 6:21 pm, Alan Bateman wrote:
On 12/03/2021 12:18, Lance Andersen wrote:
:
I don’t have a strong preference but lean slightly towards
‘-directory’ as it is more descriptive, similar to the other
GNU-style commands jar currently supports . Tar supports ‘—cd’,
‘—directory’ in
Hi Henry,
On 15/03/2021 9:40 am, Henry Jen wrote:
This patch ensure launcher won't crash JVM for the new static Methods from
local/anonymous class on MacOS.
As @dholmes-ora pointed out in the analysis, this is a MacOS specific bug when
the launcher trying to grab class name to be displayed
This patch ensure launcher won't crash JVM for the new static Methods from
local/anonymous class on MacOS.
As @dholmes-ora pointed out in the analysis, this is a MacOS specific bug when
the launcher trying to grab class name to be displayed as the Application name
on the menu.
The fix is to
On Sun, 14 Mar 2021 19:35:25 GMT, Сергей Цыпанов
wrote:
>> In some cases wrapping of `InputStream` with `BufferedInputStream` is
>> redundant, e.g. in case the wrapped one is `ByteArrayOutputStream` which
>> does not require any buffer having one within.
>>
>> Other cases are related to
On Sun, 14 Mar 2021 19:35:25 GMT, Сергей Цыпанов
wrote:
>> In some cases wrapping of `InputStream` with `BufferedInputStream` is
>> redundant, e.g. in case the wrapped one is `ByteArrayOutputStream` which
>> does not require any buffer having one within.
>>
>> Other cases are related to
> In some cases wrapping of `InputStream` with `BufferedInputStream` is
> redundant, e.g. in case the wrapped one is `ByteArrayOutputStream` which does
> not require any buffer having one within.
>
> Other cases are related to reading either a byte or short `byte[]`: in both
> cases
On Sun, 14 Mar 2021 17:40:27 GMT, Alan Bateman wrote:
>> It turned out, that with this latest update some of tier2_tools tests are
>> failing, e.g. `JLinkNegativeTest`:
>> test JLinkNegativeTest.testMalformedJmod(): failure
>> java.lang.AssertionError: Output does not fit regexp: Error:
>>
This converts jpackage to use `Stream.toList()` instead of
`Stream.collect(Collectors.toList())`. One piece of code was modified to not
mutate a list in addition to one test that used a mutating sort on a list. The
rest of the changes are simple substitutions.
-
Commit messages:
On Sun, 14 Mar 2021 17:26:07 GMT, Alan Bateman wrote:
>> Looks like it's never specified in JavaDoc which particular implementation
>> of List is used in fields of affected classes, so it's quite odd to me that
>> someone would rely on that when using reflection. But your point about
>>
On Sat, 20 Feb 2021 12:17:32 GMT, Сергей Цыпанов
wrote:
> This is a very simple and trivial improvement about getting rid of pointless
> char wrapping into array
LGTM
-
Marked as reviewed by vtewari (Committer).
PR: https://git.openjdk.java.net/jdk/pull/2660
On Sun, 14 Mar 2021 17:34:12 GMT, Сергей Цыпанов
wrote:
>> src/java.base/share/classes/jdk/internal/jmod/JmodFile.java line 58:
>>
>>> 56: byte[] magic = in.readNBytes(4);
>>> 57: if (magic.length != 4) {
>>> 58: throw new IOException("Header expected to
> In some cases wrapping of `InputStream` with `BufferedInputStream` is
> redundant, e.g. in case the wrapped one is `ByteArrayOutputStream` which does
> not require any buffer having one within.
>
> Other cases are related to reading either a byte or short `byte[]`: in both
> cases
On Sun, 14 Mar 2021 11:16:13 GMT, Alan Bateman wrote:
>> Сергей Цыпанов has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Revert usage of InputStream.readNBytes()
>
> src/java.base/share/classes/jdk/internal/jmod/JmodFile.java line 58:
>
On Sun, 14 Mar 2021 17:18:11 GMT, Сергей Цыпанов
wrote:
>> If that's the only use case, I recommend changing the return type to a
>> deque, and replace the linked list with an array deque instead (as done
>> elsewhere in this pr)
>
> Looks like it's never specified in JavaDoc which particular
On Sun, 14 Mar 2021 15:02:03 GMT, liach
wrote:
>> src/java.base/share/classes/jdk/internal/loader/URLClassPath.java line 220:
>>
>>> 218: return Collections.emptyList();
>>> 219: }
>>> 220: List result = new ArrayList<>();
>>
>> We'd better be cautious about this
On Sun, 14 Mar 2021 14:58:11 GMT, Yi Yang wrote:
>> The usage of `LinkedList` is senseless and can be replaced with either
>> `ArrayList` or `ArrayDeque` which are both more compact and effective.
>>
>> jdk:tier1 and jdk:tier2 are both ok
>
>
On Fri, 26 Feb 2021 15:32:57 GMT, liach
wrote:
> Are linked lists worse for addition even in cases where addition to array
> list or deque requires resize and copying? i thought that's the advantage of
> linked list.
As far as I know `LinkedList` is always worse than `ArrayList` and
On Fri, 26 Feb 2021 10:48:33 GMT, Сергей Цыпанов
wrote:
> The usage of `LinkedList` is senseless and can be replaced with either
> `ArrayList` or `ArrayDeque` which are both more compact and effective.
>
> jdk:tier1 and jdk:tier2 are both ok
On Fri, 26 Feb 2021 10:48:33 GMT, Сергей Цыпанов
wrote:
> The usage of `LinkedList` is senseless and can be replaced with either
> `ArrayList` or `ArrayDeque` which are both more compact and effective.
>
> jdk:tier1 and jdk:tier2 are both ok
Are linked lists worse for addition even in cases
The usage of `LinkedList` is senseless and can be replaced with either
`ArrayList` or `ArrayDeque` which are both more compact and effective.
jdk:tier1 and jdk:tier2 are both ok
-
Commit messages:
- Remove remaining usages of LinkedList in java.base
Changes:
On Sun, 14 Mar 2021 07:51:24 GMT, Alan Bateman wrote:
>> In some cases wrapping of `InputStream` with `BufferedInputStream` is
>> redundant, e.g. in case the wrapped one is `ByteArrayOutputStream` which
>> does not require any buffer having one within.
>>
>> Other cases are related to reading
In some cases wrapping of `InputStream` with `BufferedInputStream` is
redundant, e.g. in case the wrapped one is `ByteArrayOutputStream` which does
not require any buffer having one within.
Other cases are related to reading either a byte or short `byte[]`: in both
cases
On Sat, 13 Mar 2021 22:29:23 GMT, Сергей Цыпанов
wrote:
> In some cases wrapping of `InputStream` with `BufferedInputStream` is
> redundant, e.g. in case the wrapped one is `ByteArrayOutputStream` which does
> not require any buffer having one within.
>
> Other cases are related to reading
Hi all,
the JEP generally paints the picture that using the OS charset would be
incorrect or useless, it is however the right and perfectly valid choice for
communicating with other local programs where no other charset was specified.
It is the same as UTF-8 most of the time, but not always
> This PR is to introduce a new random number API for the JDK. The primary API
> is found in RandomGenerator and RandomGeneratorFactory. Further description
> can be found in the JEP https://openjdk.java.net/jeps/356 .
>
> javadoc can be found at
>
On Sat, 13 Mar 2021 14:28:25 GMT, Philippe Marschall
wrote:
>> Implement three optimiztations for Reader.read(CharBuffer)
>>
>> * Add a code path for heap buffers in Reader#read to use the backing array
>> instead of allocating a new one.
>> * Change the code path for direct buffers in
On 12/03/2021 12:18, Lance Andersen wrote:
:
I don’t have a strong preference but lean slightly towards
‘-directory’ as it is more descriptive, similar to the other GNU-style
commands jar currently supports . Tar supports ‘—cd’, ‘—directory’ in
addition to ‘-C’ which is why I suggested
On Sat, 13 Mar 2021 00:43:33 GMT, Alexander Matveev
wrote:
>> implementation of
>> JDK-8256145: JEP 398: Deprecate the Applet API for Removal
>
> Marked as reviewed by almatvee (Committer).
Have you looked at narrowing the use of the SuppressWarnings to local variable
declarations to avoid
Thanks
> On Mar 13, 2021, at 8:45 AM, Andy Herrick wrote:
>
> JDK-8263154: [macos] DMG builds have finder errors
>
> -
>
> Commit messages:
> - JDK-8263154: [macos] DMG builds have finder errors
>
> Changes: https://git.openjdk.java.net/jdk/pull/2987/files
> Webrev:
On 14/03/2021 11:00, Marco wrote:
:
IMO Charset should provide standardized getters for the OS charset and the
console charset. The latter being different has been a long standing issue on
Windows where the codepage differs between its CLI and regular environments.
OpenJDK has the necessary
31 matches
Mail list logo
