On Thu, 4 Mar 2021 03:59:27 GMT, Alexander Matveev wrote:
> - Fixed by adding write permissions to .exe package.
Marked as reviewed by asemenyuk (Committer).
-
PR: https://git.openjdk.java.net/jdk/pull/2822
> Modify the `unmodifiable*` methods in `java.util.Collections` to be
> idempotent. That is, when given an immutable collection from
> `java.util.ImmutableCollections` or `java.util.Collections`, these methods
> will return the reference instead of creating a new immutable collection that
> wra
On Thu, 4 Mar 2021 03:57:35 GMT, Stuart Marks wrote:
>> The `@implNote` additions are good, and the test rewrite looks good too.
>
> Hm. I had thought of this previously but I was a bit suspicious, and it
> didn't seem like it would make much difference, so I didn't say anything. But
> thinking
- Fixed by adding write permissions to .exe package.
-
Commit messages:
- 8261845: File permissions of packages built by jpackage
Changes: https://git.openjdk.java.net/jdk/pull/2822/files
Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2822&range=00
Issue: https://bugs.open
On Fri, 26 Feb 2021 21:37:14 GMT, Stuart Marks wrote:
>> Ian Graves has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Test refactoring. Adding implNote to modified methods
>
> The `@implNote` additions are good, and the test rewrite looks
> Modify the `unmodifiable*` methods in `java.util.Collections` to be
> idempotent. That is, when given an immutable collection from
> `java.util.ImmutableCollections` or `java.util.Collections`, these methods
> will return the reference instead of creating a new immutable collection that
> wra
Hello Lance,
On 03/03/21 9:14 pm, Lance Andersen wrote:
Some other things needed to be defined and agreed upon in order to
move forward
* The behavior if the path does not exist
* If the option is specified more than once on the command line
* Clarify the behavior if any of the files
On Thu, 4 Mar 2021 02:01:02 GMT, Ian Graves wrote:
>> src/java.base/share/classes/java/util/Collections.java line 1168:
>>
>>> 1166: */
>>> 1167: public static SortedSet unmodifiableSortedSet(SortedSet
>>> s) {
>>> 1168: if (s.getClass() == UnmodifiableSortedSet.class) {
>>
>
On Wed, 3 Mar 2021 23:29:33 GMT, Joe Darcy wrote:
>> Ian Graves has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Test refactoring. Adding implNote to modified methods
>
> src/java.base/share/classes/java/util/Collections.java line 1168:
>
On Fri, 26 Feb 2021 20:15:19 GMT, Ian Graves wrote:
>> Modify the `unmodifiable*` methods in `java.util.Collections` to be
>> idempotent. That is, when given an immutable collection from
>> `java.util.ImmutableCollections` or `java.util.Collections`, these methods
>> will return the reference
On Wed, 3 Mar 2021 22:20:45 GMT, Joe Darcy wrote:
> The class BigDecimal can be and sometimes is subclassed. The spec of
> BigDecimal.hashCode is improved slightly by explicitly stating it is a
> function of the unscaled value and the scale of the BigDecimal, the same
> fields examined by equa
The hot path of VectorShuffle checkIndexes, wrapIndexes and laneIsValid methods
can be implemented using Vector API methods.
For the attached jmh TestSlice.java, performance improves as below.
Before:
Benchmark (size) Mode Cnt Score
Error Units
T
On Wed, 3 Mar 2021 22:20:45 GMT, Joe Darcy wrote:
> The class BigDecimal can be and sometimes is subclassed. The spec of
> BigDecimal.hashCode is improved slightly by explicitly stating it is a
> function of the unscaled value and the scale of the BigDecimal, the same
> fields examined by equa
The class BigDecimal can be and sometimes is subclassed. The spec of
BigDecimal.hashCode is improved slightly by explicitly stating it is a function
of the unscaled value and the scale of the BigDecimal, the same fields examined
by equals.
It is a conscious choice to *not* explicitly state what
Hello,
Please reply if anyone can be a sponsor.
Regards,
Masanori Yano
> -Original Message-
> From: Yano, Masanori
> Sent: Tuesday, January 12, 2021 4:32 PM
> To: 'core-libs-dev@openjdk.java.net'
> Subject: RE: [PING] RE: 8250678: ModuleDescriptor.Version parsing treats empty
> segment
On Wed, 3 Mar 2021 13:56:01 GMT, Andy Herrick wrote:
>> test/jdk/tools/jpackage/share/jdk/jpackage/tests/NoMPathRuntimeTest.java
>> line 125:
>>
>>> 123: .addArguments("-cvf", "junk.jar",
>>> 124: "-C", tmpdir.toString(), "Hello.class")
>>> 125:
On Wed, 3 Mar 2021 14:50:07 GMT, Andy Herrick wrote:
>> when the app modules have already been jlinked with the runtime, and there
>> is no need for module-path, jpackage was acting as if the module-path was
>> "." and picking up jars in the current directory.
>
> Andy Herrick has updated the p
Hi Alan,
thanks for the quick response. Please find my answers inline
On Wed, Mar 3, 2021 at 1:38 PM Alan Bateman wrote:
>
> On 03/03/2021 10:43, Volker Simonis wrote:
> > :
> >
> > My question now is if this is an inherent property of the module
> > system or merely an implementation detail? I.
On Wed, 2 Dec 2020 20:23:13 GMT, Ivan Šipka wrote:
> Refactor `test/jdk/java/lang/annotation/loaderLeak/LoaderLeak.sh` as java
> test.
This pull request has now been integrated.
Changeset: 75aa1546
Author:Ivan Šipka
Committer: Igor Ignatyev
URL: https://git.openjdk.java.net/jdk/com
On Wed, 3 Mar 2021 19:56:07 GMT, Ivan Šipka wrote:
>> Refactor `test/jdk/java/lang/annotation/loaderLeak/LoaderLeak.sh` as java
>> test.
>
> Ivan Šipka has updated the pull request incrementally with one additional
> commit since the last revision:
>
> 8166026: Refactor java/lang shell tests
> Refactor `test/jdk/java/lang/annotation/loaderLeak/LoaderLeak.sh` as java
> test.
Ivan Šipka has updated the pull request incrementally with one additional
commit since the last revision:
8166026: Refactor java/lang shell tests to java
-
Changes:
- all: https://git.openjdk.j
On Wed, 3 Mar 2021 18:26:19 GMT, Igor Ignatyev wrote:
>> Ivan Šipka has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> 8166026: Refactor java/lang shell tests to java
>
> test/jdk/java/lang/annotation/LoaderLeakTest.java line 74:
>
>> 72:
On Wed, 3 Mar 2021 07:20:03 GMT, Joe Darcy wrote:
> I considered @stuart-marks previous suggestion during the code review of
> JDK-8261123 to include a more explicit discussion of why, say, different
> representations of 2 should not be regarded as equivalent. After
> contemplating several alt
On Wed, 3 Mar 2021 18:19:33 GMT, Stuart Marks wrote:
>> Joe Darcy 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 three additional commits
>> si
On Wed, 3 Mar 2021 17:49:26 GMT, Brian Burkhalter wrote:
>> Joe Darcy 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 three additional commits
>
> I considered @stuart-marks previous suggestion during the code review of
> JDK-8261123 to include a more explicit discussion of why, say, different
> representations of 2 should not be regarded as equivalent. After
> contemplating several alternatives, I didn't find anything simpler than
> St
On Wed, 3 Mar 2021 17:46:41 GMT, Andrew Haley wrote:
> A list of the bugs that our internal testing revealed so far ...
Thank you! Some of them look like test issues, but a few need more serious
consideration. I want to resolve
https://bugs.openjdk.java.net/browse/JDK-8262903 at least, along w
On Wed, 3 Mar 2021 15:55:03 GMT, Ivan Šipka wrote:
>> Refactor `test/jdk/java/lang/annotation/loaderLeak/LoaderLeak.sh` as java
>> test.
>
> Ivan Šipka has updated the pull request incrementally with one additional
> commit since the last revision:
>
> 8166026: Refactor java/lang shell tests
On Wed, 3 Mar 2021 07:20:03 GMT, Joe Darcy wrote:
> I considered @stuart-marks previous suggestion during the code review of
> JDK-8261123 to include a more explicit discussion of why, say, different
> representations of 2 should not be regarded as equivalent. After
> contemplating several alt
On Wed, 3 Mar 2021 07:20:03 GMT, Joe Darcy wrote:
> I considered @stuart-marks previous suggestion during the code review of
> JDK-8261123 to include a more explicit discussion of why, say, different
> representations of 2 should not be regarded as equivalent. After
> contemplating several alt
On Wed, 3 Mar 2021 18:10:25 GMT, Brent Christian wrote:
>> This seems to be a long standing bug, maybe goes all the way back to JDK
>> 1.2. Are you planning to add a regression test?
>
> Hi, Craig
> The commented-out lines should be removed from the change.
>
> As Alan said, a regression test w
On Wed, 3 Mar 2021 14:28:00 GMT, Alan Bateman wrote:
>> _NOTE_: I've reported this issue at https://bugreport.java.com/ (internal
>> review ID : 9069151)
>>
>> `java.net.URLClassLoader.getResource` can throw an undocumented
>> `IllegalArgumentException`.
>>
>> According to the javadoc for the
> 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
> http://cr.openjdk.java.net/~jlaskey/prng/doc/a
On Wed, 3 Mar 2021 17:39:28 GMT, Gerard Ziemski wrote:
> A list of the bugs that our internal testing revealed so far:
Are any of these blockers for integration? Some of them are to do with things
like features that aren't yet supported, and we can't fix what we can't see.
-
PR: h
On Tue, 2 Mar 2021 11:05:20 GMT, Anton Kozlov wrote:
>> For platform files that were copied from other ports to this port, if the
>> file wasn't
>> changed I presume the copyright years are left alone. If the file required
>> changes
>> for this port, I expect the year to be updated to 2021. Ho
On Wed, 3 Mar 2021 07:20:03 GMT, Joe Darcy wrote:
> I considered @stuart-marks previous suggestion during the code review of
> JDK-8261123 to include a more explicit discussion of why, say, different
> representations of 2 should not be regarded as equivalent. After
> contemplating several alt
On Wed, 3 Mar 2021 15:55:03 GMT, Ivan Šipka wrote:
>> Refactor `test/jdk/java/lang/annotation/loaderLeak/LoaderLeak.sh` as java
>> test.
>
> Ivan Šipka has updated the pull request incrementally with one additional
> commit since the last revision:
>
> 8166026: Refactor java/lang shell tests
On Tue, 2 Mar 2021 23:21:28 GMT, David Holmes wrote:
> Note that `thread` can be NULL here if the signal handler is running in a
> non-attached thread. If we then perform:
> `ThreadWXEnable(WXMode new_mode, Thread* thread = NULL) : _thread(thread ?
> thread : Thread::current()),`
> we call Thre
> Refactor `test/jdk/java/lang/annotation/loaderLeak/LoaderLeak.sh` as java
> test.
Ivan Šipka has updated the pull request incrementally with one additional
commit since the last revision:
8166026: Refactor java/lang shell tests to java
-
Changes:
- all: https://git.openjdk.j
Hi Jaikiran,
It should not be too difficult to support the options listed below via
GNUStyleOptions.
Some other things needed to be defined and agreed upon in order to move forward
* The behavior if the path does not exist
* If the option is specified more than once on the command line
On Wed, 3 Mar 2021 00:32:24 GMT, Alexey Semenyuk wrote:
>> Andy Herrick has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> JDK-8261518: jpackage looks for main module in current dir when there is
>> no module-path
>
> test/jdk/tools/jpacka
> when the app modules have already been jlinked with the runtime, and there is
> no need for module-path, jpackage was acting as if the module-path was "."
> and picking up jars in the current directory.
Andy Herrick has updated the pull request incrementally with one additional
commit since t
> when the app modules have already been jlinked with the runtime, and there is
> no need for module-path, jpackage was acting as if the module-path was "."
> and picking up jars in the current directory.
Andy Herrick has updated the pull request incrementally with one additional
commit since t
On Sat, 20 Feb 2021 19:20:48 GMT, Craig Andrews
wrote:
> _NOTE_: I've reported this issue at https://bugreport.java.com/ (internal
> review ID : 9069151)
>
> `java.net.URLClassLoader.getResource` can throw an undocumented
> `IllegalArgumentException`.
>
> According to the javadoc for the `ge
> Refactor `test/jdk/java/lang/annotation/loaderLeak/LoaderLeak.sh` as java
> test.
Ivan Šipka has refreshed the contents of this pull request, and previous
commits have been removed. The incremental views will show differences compared
to the previous content of the PR. The pull request contai
On Sat, 20 Feb 2021 19:22:10 GMT, Craig Andrews
wrote:
>> _NOTE_: I've reported this issue at https://bugreport.java.com/ (internal
>> review ID : 9069151)
>>
>> `java.net.URLClassLoader.getResource` can throw an undocumented
>> `IllegalArgumentException`.
>>
>> According to the javadoc for
On Sat, 20 Feb 2021 19:20:48 GMT, Craig Andrews
wrote:
> _NOTE_: I've reported this issue at https://bugreport.java.com/ (internal
> review ID : 9069151)
>
> `java.net.URLClassLoader.getResource` can throw an undocumented
> `IllegalArgumentException`.
>
> According to the javadoc for the `ge
_NOTE_: I've reported this issue at https://bugreport.java.com/ (internal
review ID : 9069151)
`java.net.URLClassLoader.getResource` can throw an undocumented
`IllegalArgumentException`.
According to the javadoc for the `getResource` and `findResource` methods,
neither should be throwing `Ille
On Wed, 3 Mar 2021 00:31:34 GMT, Alexey Semenyuk wrote:
>> Andy Herrick has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> JDK-8261518: jpackage looks for main module in current dir when there is
>> no module-path
>
> test/jdk/tools/jpacka
On 03/03/2021 10:43, Volker Simonis wrote:
:
My question now is if this is an inherent property of the module
system or merely an implementation detail? I.e. would it be possible
to put the application module into its own layer and initialize that
only later when the custom system class loader w
Hi,
I have a question about how changing the system class loader by
setting "java.system.class.loader" interacts with the module system. I
couldn't find a lot of information on this topic but if it has been
discussed before please point me to the corresponding place.
Traditionally, setting "java.
Thank you Lance. So I think there's some level of agreement on using -C
and --dir (or --directory) for the option names.
Anymore opinion on the directory creation semantics and any other
aspects to consider?
-Jaikiran
On 28/02/21 5:38 pm, Lance Andersen wrote:
Hi Jaikiran,
Thank you for th
52 matches
Mail list logo
