On Thu, 18 Jul 2024 20:51:48 GMT, Naoto Sato wrote:
>> Proposing a new overload method for `Process#waitFor()` which takes a
>> `Duration` for the timeout value. This will reduce the possibility for
>> making mistakes with the `TimeUnit` in the other overload method. A
>> corresponding CSR
On Fri, 12 Jul 2024 23:38:31 GMT, Chen Liang wrote:
> Please review the backport of #20145 onto jdk23, fixing 2 unnecessary and
> erroneous links in the doc files.
Marked as reviewed by prappo (Reviewer).
-
PR Review:
On Thu, 11 Jul 2024 09:36:02 GMT, Pavel Rappo wrote:
> Was reading Process' documentation the other day and spotted a markup typo.
> Please review this utmost trivial fix.
This pull request has now been integrated.
Changeset: 6fcd49f9
Author: Pavel Rappo
URL:
Was reading Process' documentation the other day and spotted a markup typo.
Please review this utmost trivial fix.
-
Commit messages:
- Initial commit
Changes: https://git.openjdk.org/jdk/pull/20133/files
Webrev: https://webrevs.openjdk.org/?repo=jdk=20133=00
Issue:
On Mon, 8 Jul 2024 19:12:37 GMT, Joe Darcy wrote:
> PS There are cases where cyclic structures are not supported, such as in
> java.util.Set:
There are algorithms that also don't support that:
/**
* Returns a hash code based on the "deep contents" of the specified
* array. If
On Mon, 8 Jul 2024 19:01:04 GMT, Joe Darcy wrote:
> One tricky part of the implementation was making sure the stack trace output
> did cycle detection since there were various ways exceptions could end up
> referring to each other.
Yes, the tricky part was to "Guard against malicious
On Mon, 8 Jul 2024 09:33:54 GMT, Jaikiran Pai wrote:
>> Make well-behaved implementation expectations of Object.{toString, hashCode}
>> explicit.
>
> src/java.base/share/classes/java/lang/Object.java line 101:
>
>> 99: * implementation should not use excessive memory or time for its
>>
On Sun, 7 Jul 2024 20:20:30 GMT, Joe Darcy wrote:
> Make well-behaved implementation expectations of Object.{toString, hashCode}
> explicit.
Looks good.
-
Marked as reviewed by prappo (Reviewer).
PR Review: https://git.openjdk.org/jdk/pull/20063#pullrequestreview-2162781503
> The commit being backported was authored by Pavel Rappo on 20 Jun 2024 and
> was reviewed by Naoto Sato.
>
> Thanks!
Marked as reviewed by prappo (Reviewer).
-
PR Review: https://git.openjdk.org/jdk/pull/19847#pullrequestreview-2135235884
On Mon, 10 Jun 2024 12:29:32 GMT, Pavel Rappo wrote:
> Please review this fix for an intermittent test failure.
>
> On some configurations, the default `expect` timeout of 10 seconds is
> insufficient. It is increased to 20; it's hard to imagine a configuration for
> which
that test timeouts should be scaled with
> `test.timeout.factor`. I propose to integrate this PR first and then
> separately update all the affected tests to scale their `expect` timeouts.
Pavel Rappo has updated the pull request with a new target base due to a merge
or a rebase. The
that test timeouts should be scaled with
> `test.timeout.factor`. I propose to integrate this PR first and then
> separately update all the affected tests to scale their `expect` timeouts.
Pavel Rappo has updated the pull request with a new target base due to a merge
or a rebase. The
On Thu, 13 Jun 2024 06:47:07 GMT, Jaikiran Pai wrote:
> in the past on systems that Matthias has run into similar issues, it was
> observed that those systems run with a very high `-concurrency` value (which
> implies too many test processes running at the same time) which could cause
>
On Tue, 11 Jun 2024 09:01:49 GMT, Pavel Rappo wrote:
>> Please review this fix for an intermittent test failure.
>>
>> On some configurations, the default `expect` timeout of 10 seconds is
>> insufficient. It is increased to 20; it's hard to imagine a configuration
>
that test timeouts should be scaled with
> `test.timeout.factor`. I propose to integrate this PR first and then
> separately update all the affected tests to scale their `expect` timeouts.
Pavel Rappo has updated the pull request incrementally with one additional
commit since the l
On Mon, 10 Jun 2024 21:58:29 GMT, Damon Nguyen wrote:
>> This issue is responsible for updating the translations of all the
>> localize(able) resources in the JDK. Primarily, the changes between JDK 22
>> RDP 1 and the integration of the JDK 23 RDP 1 L10n drop will be translated.
>>
>> The
that test timeouts should be scaled with
> `test.timeout.factor`. I propose to integrate this PR first and then
> separately update all the affected tests to scale their `expect` timeouts.
Pavel Rappo has updated the pull request incrementally with one additional
commit since the
Please review this fix for an intermittent test failure.
On some configurations, the default `expect` timeout of 10 seconds is
insufficient. It is increased to 20; it's hard to imagine a configuration for
which that new value would still be insufficient, but we'll see.
Aside from that,
On Thu, 6 Jun 2024 21:49:35 GMT, Naoto Sato wrote:
>> This test intends to verify the behavior of JdkConsole for the java.base
>> module, wrt restoring the echo. The test assumes the internal methods that
>> sets/gets the echo status of the platform.
>
> Naoto Sato has updated the pull request
On Thu, 6 Jun 2024 17:08:50 GMT, Naoto Sato wrote:
>> test/jdk/java/io/Console/restoreEcho.exp line 57:
>>
>>> 55: test "$rpprompt" "$rpinput" "-echo" "$rpexpected"
>>> 56: # See if the initialEcho is restored with `stty -a`
>>> 57: expect " $initialEcho "
>>
>> If you leave out those
On Thu, 6 Jun 2024 17:51:50 GMT, Naoto Sato wrote:
> Turned out that removing the classpath ends up not finding the test class:
>
> ```
> Error: Could not find or load main class RestoreEchoTest
> Caused by: java.lang.ClassNotFoundException: RestoreEchoTest
> ];
> ```
Hm... this is surprising.
On Wed, 5 Jun 2024 17:48:25 GMT, Naoto Sato wrote:
>> This test intends to verify the behavior of JdkConsole for the java.base
>> module, wrt restoring the echo. The test assumes the internal methods that
>> sets/gets the echo status of the platform.
>
> Naoto Sato has updated the pull request
On Thu, 30 May 2024 18:10:14 GMT, Naoto Sato wrote:
>> Claes has described the issue well. Like I said, `break` short-circuits the
>> search. If a module can provide more than one console provider, the
>> suggested stream-less replacement is **not** equivalent.
>>
>> If a module can provide
On Mon, 27 May 2024 16:28:31 GMT, Pavel Rappo wrote:
> Please review this PR, which supersedes a now withdrawn
> https://github.com/openjdk/jdk/pull/14831.
>
> This PR replaces `ArraysSupport.vectorizedHashCode` with a set of more
> user-friendly methods. Here's a summa
On Thu, 30 May 2024 08:34:59 GMT, Claes Redestad wrote:
>> @cl4es, do you want me to delete that test file altogether?
>
> I thought you verified that the non-constant type test still provoke a crash
> (on x86) if you back out the code changes in
>
On Thu, 30 May 2024 07:44:24 GMT, Claes Redestad wrote:
>> Right. Since `findAny` is after the module name matching, there is at most 1
>> match. In the case we didn't find any, the final `orElse(null)` eventually
>> returns null. So the refactored code is semantically the same.
>
> It's only
On Wed, 29 May 2024 21:27:30 GMT, Chen Liang wrote:
>> There is an initialization code in `Console` class that searches for the
>> Console implementations. Refactoring the init code not to use lambda/stream
>> would reduce the (initial) number of loaded classes by about 100 for
>> java.base
On Wed, 29 May 2024 15:50:05 GMT, Pavel Rappo wrote:
>> @cl4es, here are some results from my machine (macosx-aarch64):
>>
>> Name (size) Cnt BaseError TestError
>> Unit Change
>> ArraysHashCode.bytes1
On Wed, 29 May 2024 12:53:42 GMT, Pavel Rappo wrote:
>> src/java.base/share/classes/jdk/internal/util/ArraysSupport.java line 252:
>>
>>> 250: return switch (length) {
>>> 251: case 0 -> initialValue;
>>> 252: case
On Wed, 29 May 2024 12:44:45 GMT, Pavel Rappo wrote:
>> I don't care as long as microbenchmarks don't get a hiccup.
>
> @cl4es, here are some results from my machine (macosx-aarch64):
>
> Name (size) Cnt BaseError TestErro
e the method
> is now private, it's no longer callable by clients of `ArraysSupport`, thus a
> problem of an inaccurate name is less severe.
>
> - Made the `ArraysSupport.utf16HashCode` method private
>
> - Moved tiny cases (i.e. 0, 1, 2) to `ArraysSupport`
Pavel Rappo has update
On Tue, 28 May 2024 16:56:18 GMT, Naoto Sato wrote:
>> This test intends to verify the behavior of JdkConsole for the java.base
>> module, wrt restoring the echo. The test assumes the internal methods that
>> sets/gets the echo status of the platform.
>
> Naoto Sato has updated the pull
On Tue, 28 May 2024 19:13:50 GMT, Jorn Vernee wrote:
>> Pavel Rappo has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Fix incorrect utf16 hashCode adaptation
>
> src/java.base/share/classes/jdk/internal/ut
On Tue, 28 May 2024 20:40:30 GMT, Claes Redestad wrote:
>> src/java.base/share/classes/jdk/internal/util/ArraysSupport.java line 275:
>>
>>> 273: return switch (length) {
>>> 274: case 0 -> initialValue;
>>> 275: case 1 -> 31 * initialValue + (a[fromIndex] &
On Wed, 29 May 2024 03:21:27 GMT, Chen Liang wrote:
>> Pavel Rappo has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Fix incorrect utf16 hashCode adaptation
>
> src/java.base/share/classes/jdk/internal/ut
On Tue, 28 May 2024 20:21:34 GMT, Claes Redestad wrote:
>> test/hotspot/jtreg/compiler/intrinsics/TestArraysHashCode.java line 88:
>>
>>> 86: private static int testIntrinsic(byte[] bytes, int type)
>>> 87: throws InvocationTargetException, IllegalAccessException {
>>> 88:
On Tue, 28 May 2024 22:08:06 GMT, Pavel Rappo wrote:
>> Yes, should be `2` (`a` is semantically a `char[]`). This typo likely pass
>> functional testing since `1` can never happen in practice, and the default
>> case should work for any value. There might be a String
On Tue, 28 May 2024 20:38:21 GMT, Claes Redestad wrote:
>> src/java.base/share/classes/jdk/internal/util/ArraysSupport.java line 301:
>>
>>> 299: return switch (length) {
>>> 300: case 0 -> initialValue;
>>> 301: case 1 -> 31 * initialValue + JLA.getUTF16Char(a,
e the method
> is now private, it's no longer callable by clients of `ArraysSupport`, thus a
> problem of an inaccurate name is less severe.
>
> - Made the `ArraysSupport.utf16HashCode` method private
>
> - Moved tiny cases (i.e. 0, 1, 2) to `ArraysSupport`
Pavel Rappo has updated the
Please review this PR, which supersedes a now withdrawn
https://github.com/openjdk/jdk/pull/14831.
This PR replaces `ArraysSupport.vectorizedHashCode` with a set of more
user-friendly methods. Here's a summary:
- Made the operand constants (i.e. `T_BOOLEAN` and friends) and the
On Tue, 11 Jul 2023 16:35:51 GMT, Pavel Rappo wrote:
> This PR adds an internal method to calculate hash code from the provided
> integer array, offset and length into that array, and the initial hash code
> value.
>
> Current options for calculating a hash code for int[] are i
On Sun, 26 May 2024 07:24:16 GMT, SendaoYan wrote:
>> Hi all,
>> When there is no `/usr/bin/expect` in system, `throw new SkippedException`
>> will not make the jvm exit in `@BeforeAll` junit stage, thus this will cause
>> this testcase run failed. So I make change from `throw new
On Mon, 6 May 2024 21:45:12 GMT, Pavel Rappo wrote:
> Please review this PR which introduces the `java.io.IO` top-level class and
> three methods to `java.io.Console` for [Implicitly Declared Classes and
> Instance Main Methods (Third Preview)].
>
> This PR has been obtaine
te [draft
> PR].
>
> [Implicitly Declared Classes and Instance Main Methods (Third Preview)]:
> https://bugs.openjdk.org/browse/JDK-8323335
> [draft PR]: https://github.com/openjdk/jdk/pull/18921
Pavel Rappo has updated the pull request with a new target base due to a merge
or a rebase. Th
te [draft
> PR].
>
> [Implicitly Declared Classes and Instance Main Methods (Third Preview)]:
> https://bugs.openjdk.org/browse/JDK-8323335
> [draft PR]: https://github.com/openjdk/jdk/pull/18921
Pavel Rappo has updated the pull request with a new target base due to a merge
or a rebase. Th
On Wed, 22 May 2024 19:32:07 GMT, Naoto Sato wrote:
> > I might be confused, but what if the shutdown hook completes and then some
> > application thread enters `readPassword`. If that thread manages to turn
> > off echo before all other shutdown hooks complete, it might never execute
> >
On Wed, 22 May 2024 17:20:02 GMT, Naoto Sato wrote:
> Hi Pavel,
>
> > If I read
> > [this](https://docs.oracle.com/en/java/javase/22/docs/api/java.base/java/lang/Runtime.html#shutdown)
> > correctly, due to the mechanics of JVM exit, we simply don't know which
> > thread finishes first: a
On Tue, 21 May 2024 22:51:14 GMT, Naoto Sato wrote:
>> Making sure `restoreEcho` correctly reflects the state in the shutdown
>> thread, which differs from the application's thread that issues the
>> `readPassword()` method.
>
> Naoto Sato has updated the pull request incrementally with one
te [draft
> PR].
>
> [Implicitly Declared Classes and Instance Main Methods (Third Preview)]:
> https://bugs.openjdk.org/browse/JDK-8323335
> [draft PR]: https://github.com/openjdk/jdk/pull/18921
Pavel Rappo has updated the pull request incrementally with one additional
commit since the last
te [draft
> PR].
>
> [Implicitly Declared Classes and Instance Main Methods (Third Preview)]:
> https://bugs.openjdk.org/browse/JDK-8323335
> [draft PR]: https://github.com/openjdk/jdk/pull/18921
Pavel Rappo has updated the pull request incrementally with one additional
commit since the last rev
On Tue, 21 May 2024 19:55:22 GMT, Andrey Turbanov wrote:
>> Pavel Rappo has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains 20 commits:
>>
>> - Add diagnostic output
>> - Use "expect" t
te [draft
> PR].
>
> [Implicitly Declared Classes and Instance Main Methods (Third Preview)]:
> https://bugs.openjdk.org/browse/JDK-8323335
> [draft PR]: https://github.com/openjdk/jdk/pull/18921
Pavel Rappo has updated the pull request with a new target base due to a merge
or a rebase. Th
> One can easily write an ad-hoc *local* adapter extending
> `java.util.AbstractList`..
> .. and immediately invoke existing `java.util.Collections::binarySearch`
> method.
>
> Cheers,
> MR
>
> On Thu, Apr 25, 2024 at 9:09 PM Pavel Rappo wrote:
>
>
On Tue, 14 May 2024 21:30:16 GMT, Naoto Sato wrote:
>> Making sure `restoreEcho` correctly reflects the state in the shutdown
>> thread, which differs from the application's thread that issues the
>> `readPassword()` method.
>
> Naoto Sato has updated the pull request with a new target base
On Tue, 7 May 2024 11:53:19 GMT, Pavel Rappo wrote:
> Please review this mechanical change to man pages. This PR should be
> integrated after https://github.com/openjdk/jdk/pull/18787.
This pull request has been closed without being integrated.
-
PR: https://git.openjdk.o
On Tue, 7 May 2024 11:53:19 GMT, Pavel Rappo wrote:
> Please review this mechanical change to man pages. This PR should be
> integrated after https://github.com/openjdk/jdk/pull/18787.
Withdrawing this, as a different approach is required.
-
PR Comment: https://git.openj
On Tue, 14 May 2024 14:27:35 GMT, Per Minborg wrote:
>> Pavel Rappo has updated the pull request with a new target base due to a
>> merge or a rebase. The incremental webrev excludes the unrelated changes
>> brought in by the merge/rebase. The pull request contains 17 addi
On Tue, 14 May 2024 13:32:39 GMT, Naoto Sato wrote:
> I thought of the same scenario that is certainly possible. Now I am tempted
> to avoid this race condition altogether by removing checking restoreEcho and
> always issue echo(true). What do you guys think?
It should be possible to provide
On Mon, 13 May 2024 21:14:26 GMT, Stuart Marks wrote:
> Hm, I don't think we want to add any synchronized blocks within a shutdown
> hook. If a thread is blocked reading from the console, it will hold readLock;
> if the JVM is then shut down using a signal, it will run shutdown hooks, and
>
On Mon, 13 May 2024 17:06:32 GMT, Naoto Sato wrote:
>> Making sure `restoreEcho` correctly reflects the state in the shutdown
>> thread, which differs from the application's thread that issues the
>> `readPassword()` method.
>
> Naoto Sato has updated the pull request incrementally with one
On Thu, 9 May 2024 08:18:41 GMT, David Holmes wrote:
>> Please review this mechanical change to man pages. This PR should be
>> integrated after https://github.com/openjdk/jdk/pull/18787.
>
> src/java.base/share/man/java.1 line 3856:
>
>> 3854: .SH REMOVED JAVA OPTIONS
>> 3855: .PP
>> 3856:
On Fri, 10 May 2024 21:55:26 GMT, Naoto Sato wrote:
> Making sure `restoreEcho` correctly reflects the state in the shutdown
> thread, which differs from the application's thread that issues the
> `readPassword()` method.
Generally looks good.
It's hard to imagine that this shutdown hook
te [draft
> PR].
>
> [Implicitly Declared Classes and Instance Main Methods (Third Preview)]:
> https://bugs.openjdk.org/browse/JDK-8323335
> [draft PR]: https://github.com/openjdk/jdk/pull/18921
Pavel Rappo has updated the pull request with a new target base due to a merge
or a rebase. T
.base/share/classes/java/util/concurrent/locks/ReentrantReadWriteLock.java
>
> Co-authored-by: Pavel Rappo <32523691+pavelra...@users.noreply.github.com>
Marked as reviewed by prappo (Reviewer).
-
PR Review: https://git.openjdk.org/jdk/pull/18974#pullrequestreview-2050367663
On Wed, 1 May 2024 10:03:25 GMT, Pavel Rappo wrote:
>> The grammar rules prefer "that" because it is a restrictive clause, even
>> though "which" might sound better. See for example:
>> https://owl.purdue.edu/owl/general_writing/grammar/that_vs_wh
On Fri, 10 May 2024 07:45:02 GMT, Jaikiran Pai wrote:
>> Pavel Rappo has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Fix System.console().readln(null) in jshell
>>
>> Without it, jshell hangs
On Fri, 10 May 2024 07:23:38 GMT, Per Minborg wrote:
>> Pavel Rappo has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Fix System.console().readln(null) in jshell
>>
>> Without it, jshell hangs
te [draft
> PR].
>
> [Implicitly Declared Classes and Instance Main Methods (Third Preview)]:
> https://bugs.openjdk.org/browse/JDK-8323335
> [draft PR]: https://github.com/openjdk/jdk/pull/18921
Pavel Rappo has updated the pull request incrementally with two additional
commits since the la
On Fri, 10 May 2024 07:29:42 GMT, Per Minborg wrote:
>> If the sole constructor of a class is private, not only does it preclude the
>> class from being instantiated, but it also precludes the class from being
>> extended. Mind you, even with the sole private constructor, both
>>
te [draft
> PR].
>
> [Implicitly Declared Classes and Instance Main Methods (Third Preview)]:
> https://bugs.openjdk.org/browse/JDK-8323335
> [draft PR]: https://github.com/openjdk/jdk/pull/18921
Pavel Rappo has updated the pull request incrementally with one additional
commit since the last r
te [draft
> PR].
>
> [Implicitly Declared Classes and Instance Main Methods (Third Preview)]:
> https://bugs.openjdk.org/browse/JDK-8323335
> [draft PR]: https://github.com/openjdk/jdk/pull/18921
Pavel Rappo has updated the pull request with a new target base due to a merge
or a rebase. T
On Thu, 9 May 2024 14:41:13 GMT, Jonathan Gibbons wrote:
> (Minor). at least within the context of this PR, tags like `@param` and
> `@throws` are stylistically inconsistent as to whether they begin with a
> capital letter and end with a period. (I have not checked for local
> consistency
te [draft
> PR].
>
> [Implicitly Declared Classes and Instance Main Methods (Third Preview)]:
> https://bugs.openjdk.org/browse/JDK-8323335
> [draft PR]: https://github.com/openjdk/jdk/pull/18921
Pavel Rappo has updated the pull request incrementally with five additional
commits since t
On Tue, 7 May 2024 07:13:23 GMT, Jan Lahoda wrote:
>> When JLine reads a line, there may be a prompt provided. However, JLine will
>> not interpret the prompt literally, it will handle `%` specially. As a
>> consequence, doing:
>>
>> System.console().readLine("%%s");
>>
>>
>> will not print
PKCS10.java#L356-L362
>
> This PR adds such a method and provides tests for it. Additionally, this PR
> adds tests for `null` passed to `java.util.Arrays.hashCode` overloads,
> behaviour which was specified but untested.
Pavel Rappo has updated the pull request with a new target base due
On Wed, 8 May 2024 19:40:44 GMT, Stuart Marks wrote:
>>> Most of these are defined in terms of `String.valueOf(Object)` which if
>>> passed a null reference will return the String object containing `null`. So
>>> no, I don't think NPE should be thrown. It might be worth mentioning this
>>>
te [draft
> PR].
>
> [Implicitly Declared Classes and Instance Main Methods (Third Preview)]:
> https://bugs.openjdk.org/browse/JDK-8323335
> [draft PR]: https://github.com/openjdk/jdk/pull/18921
Pavel Rappo has updated the pull request incrementally with two additional
commits since the last
On Wed, 8 May 2024 16:06:29 GMT, Stuart Marks wrote:
> Most of these are defined in terms of `String.valueOf(Object)` which if
> passed a null reference will return the String object containing `null`. So
> no, I don't think NPE should be thrown. It might be worth mentioning this
> explicitly
ass, maybe readKey() or simple read() should also be
> considered?
>
> On Wed, May 8, 2024 at 4:16 PM Pavel Rappo wrote:
> On Wed, 8 May 2024 10:31:59 GMT, Jaikiran Pai wrote:
>
> >> If we specify that, it would be very much unlike all other `Console`
> >> meth
On Wed, 8 May 2024 10:31:59 GMT, Jaikiran Pai wrote:
>> If we specify that, it would be very much unlike all other `Console` methods
>> that are covered by this:
>>
>> * Unless otherwise specified, passing a {@code null} argument to any
>> method
>> * in this class will cause a {@link
On Wed, 8 May 2024 05:53:25 GMT, Jaikiran Pai wrote:
>> Pavel Rappo has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Strengthen tests after 8330998
>>
>> https://github.com/openjdk/jdk/pull/1899
On Wed, 8 May 2024 05:59:14 GMT, Jaikiran Pai wrote:
>> Pavel Rappo has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Strengthen tests after 8330998
>>
>> https://github.com/openjdk/jdk/pull/1899
On Wed, 8 May 2024 05:41:52 GMT, Jaikiran Pai wrote:
>> Pavel Rappo has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Strengthen tests after 8330998
>>
>> https://github.com/openjdk/jdk/pull/1899
On Tue, 7 May 2024 21:19:59 GMT, Stuart Marks wrote:
>> Pavel Rappo has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Strengthen tests after 8330998
>>
>> https://github.com/openjdk/jdk/pull/1899
On Tue, 7 May 2024 11:53:19 GMT, Pavel Rappo wrote:
> Please review this mechanical change to man pages. This PR should be
> integrated after https://github.com/openjdk/jdk/pull/18787.
Thanks for reviewing it Joe, I'm now delegating integration of this PR to
@JesperIRL, you, or anyo
On Tue, 7 May 2024 02:54:39 GMT, Joe Darcy wrote:
>> src/java.base/share/classes/java/io/IO.java line 41:
>>
>>> 39: */
>>> 40: @PreviewFeature(feature = PreviewFeature.Feature.IMPLICIT_CLASSES)
>>> 41: public class IO {
>>
>> Should this be final?
>
>> Should this be final?
>
> With only
te [draft
> PR].
>
> [Implicitly Declared Classes and Instance Main Methods (Third Preview)]:
> https://bugs.openjdk.org/browse/JDK-8323335
> [draft PR]: https://github.com/openjdk/jdk/pull/18921
Pavel Rappo has updated the pull request incrementally with one additional
commit since the last
te [draft
> PR].
>
> [Implicitly Declared Classes and Instance Main Methods (Third Preview)]:
> https://bugs.openjdk.org/browse/JDK-8323335
> [draft PR]: https://github.com/openjdk/jdk/pull/18921
Pavel Rappo has updated the pull request incrementally with one additional
commit since the last re
On Tue, 7 May 2024 17:30:46 GMT, Naoto Sato wrote:
> Sorry, I read it wrong. Your comment is clear so no need for rewording
Still, I think that your misreading is a symptom of a problem with my wording.
Let me try to rephrase it; let's see if you like it more.
-
PR Review
On Tue, 7 May 2024 16:24:52 GMT, Naoto Sato wrote:
>> Please review this PR which introduces the `java.io.IO` top-level class and
>> three methods to `java.io.Console` for [Implicitly Declared Classes and
>> Instance Main Methods (Third Preview)].
>>
>> This PR has been obtained as `git merge
On Tue, 7 May 2024 16:32:46 GMT, Naoto Sato wrote:
>> Please review this PR which introduces the `java.io.IO` top-level class and
>> three methods to `java.io.Console` for [Implicitly Declared Classes and
>> Instance Main Methods (Third Preview)].
>>
>> This PR has been obtained as `git merge
On Tue, 7 May 2024 01:20:39 GMT, Naoto Sato wrote:
>> Please review this PR which introduces the `java.io.IO` top-level class and
>> three methods to `java.io.Console` for [Implicitly Declared Classes and
>> Instance Main Methods (Third Preview)].
>>
>> This PR has been obtained as `git merge
On Tue, 7 May 2024 12:17:36 GMT, Rémi Forax wrote:
> I do not think the step to "standardise" a preview feature exists ? When a
> preview feature becomes a released feature, the code is very lightly edited,
> at least it this is my experience.
We may call it differently, but I think both you
On Tue, 7 May 2024 11:53:19 GMT, Pavel Rappo wrote:
> Please review this mechanical change to man pages. This PR should be
> integrated after https://github.com/openjdk/jdk/pull/18787.
This PR is standalone as opposed to dependent because the
https://github.com/openjdk/jdk/pull
Please review this mechanical change to man pages. This PR should be integrated
after https://github.com/openjdk/jdk/pull/18787.
-
Commit messages:
- Initial commit
Changes: https://git.openjdk.org/jdk/pull/19119/files
Webrev: https://webrevs.openjdk.org/?repo=jdk=19119=00
On Tue, 7 May 2024 05:52:12 GMT, Rémi Forax wrote:
>> Please review this PR which introduces the `java.io.IO` top-level class and
>> three methods to `java.io.Console` for [Implicitly Declared Classes and
>> Instance Main Methods (Third Preview)].
>>
>> This PR has been obtained as `git merge
On Tue, 7 May 2024 05:49:58 GMT, Rémi Forax wrote:
>> Please review this PR which introduces the `java.io.IO` top-level class and
>> three methods to `java.io.Console` for [Implicitly Declared Classes and
>> Instance Main Methods (Third Preview)].
>>
>> This PR has been obtained as `git merge
Please review this PR which introduces the `java.io.IO` top-level class and
three methods to `java.io.Console` for [Implicitly Declared Classes and
Instance Main Methods (Third Preview)].
This PR has been obtained as `git merge --squash` of a now obsolete [draft PR].
[Implicitly Declared
On Mon, 6 May 2024 16:59:40 GMT, Naoto Sato wrote:
> For the latter, since you are already at it, I just reassigned the bug to you
>
@lahodaj, since a test for 8331681 is added to this PR, I'd suggest you do
this: `/issue add 8331681`.
-
PR Review Comment:
On Mon, 29 Apr 2024 17:46:24 GMT, Nizar Benalla wrote:
> Pavel, can I simply change the PR/issue title to be more descriptive? As I
> want to include the the inherit doc because of the unchecked exceptions,
> rather than clean this up in a different PR
I suggest dropping all the changes that
1 - 100 of 408 matches
Mail list logo
