On Tue, 30 Nov 2021 11:25:48 GMT, Roman Kennke wrote:
>> The caches in ObjectStreamClass basically map WeakReference to
>> SoftReference, where the ObjectStreamClass also
>> references the same Class. That means that the cache entry, and thus the
>> class and its class-loader, will not get rec
> Hi all,
>
> Please review this fix for Infinite loop in ZipOutputStream.close().
> The main issue here is when ever there is an exception during close
> operations on GZip we are not setting the deflator to a finished state which
> is leading to an infinite loop when we try writing on the same
On Tue, 5 Oct 2021 19:11:57 GMT, Ian Graves wrote:
> Specification update to clarify Matcher behavior to include a null return
> value.
This pull request has been closed without being integrated.
-
PR: https://git.openjdk.java.net/jdk/pull/5827
On Tue, 30 Nov 2021 18:48:15 GMT, Aleksey Shipilev wrote:
> OpenJDK tiered tests definitions have the catch-all `tier4` that runs all
> tests not defined in the lower tiers. `hotspot:tier4` has lots of them,
> mostly long-running vmTestbase tests, which take many hours even on a very
> paralle
>> It is almost impossible to write any non-trivial code that is
>> async-exception-safe and no JDK library code is written to be
>> async-exception-safe including thread tear-down. So while you can say
>> "stop() is the only way to disrupt this piece of code", you cannot ensure
>> that it is d
On Tue, 30 Nov 2021 14:52:37 GMT, Alan Bateman wrote:
> Thread.stop is inherently unsafe and has been deprecated since Java 1.2
> (1998). It's time to terminally deprecate this method so it can be degraded
> and removed in the future.
>
> This PR does not propose any changes to the JVM TI Stop
On 1/12/2021 3:13 am, Alan Snyder wrote:
Although I understand the potential dangers of using Thread.stop, it seems to
me there are cases where its use is legitimate and valuable.
No there really aren't. :) The perceived utility of stop() is an
illusion. It is almost impossible to write any n
On Tue, 30 Nov 2021 21:56:51 GMT, Andrew Leonard wrote:
>> Add a new --source-date (epoch seconds) option to jar and jmod
>> to allow specification of time to use for created/updated jar/jmod entries.
>> This then allows the ability to make the content deterministic.
>>
>> Signed-off-by: Andr
On Tue, 30 Nov 2021 14:28:05 GMT, Jaikiran Pai wrote:
> Can I please get a review for this change which fixes a typo in the javadoc
> of `java.util.zip.ZipEntry.setTime()` method?
Thank you everyone for the reviews.
-
PR: https://git.openjdk.java.net/jdk/pull/6615
On Tue, 30 Nov 2021 14:28:05 GMT, Jaikiran Pai wrote:
> Can I please get a review for this change which fixes a typo in the javadoc
> of `java.util.zip.ZipEntry.setTime()` method?
This pull request has now been integrated.
Changeset: 0a01baaf
Author:Jaikiran Pai
URL:
https://git.op
On Tue, 30 Nov 2021 21:56:51 GMT, Andrew Leonard wrote:
>> Add a new --source-date (epoch seconds) option to jar and jmod
>> to allow specification of time to use for created/updated jar/jmod entries.
>> This then allows the ability to make the content deterministic.
>>
>> Signed-off-by: Andr
On Wed, 24 Nov 2021 15:20:42 GMT, kabutz wrote:
>> BigInteger currently uses three different algorithms for multiply. The
>> simple quadratic algorithm, then the slightly better Karatsuba if we exceed
>> a bit count and then Toom Cook 3 once we go into the several thousands of
>> bits. Since T
> Remove Vector API scripts for building and running tests. `jtreg` should be
> used instead.
>
> Also updated the test generation script to remove options that assume
> mercurial as the code repository.
Paul Sandoz has updated the pull request incrementally with one additional
commit since th
On Tue, 30 Nov 2021 23:24:24 GMT, Jie Fu wrote:
> Shall we also update the copyright year?
Doh! of course, updated.
-
PR: https://git.openjdk.java.net/jdk/pull/6621
On Tue, 30 Nov 2021 23:31:21 GMT, Paul Sandoz wrote:
>> Remove Vector API scripts for building and running tests. `jtreg` should be
>> used instead.
>>
>> Also updated the test generation script to remove options that assume
>> mercurial as the code repository.
>
> Paul Sandoz has updated the
On Tue, 30 Nov 2021 19:22:53 GMT, Paul Sandoz wrote:
> Remove Vector API scripts for building and running tests. `jtreg` should be
> used instead.
>
> Also updated the test generation script to remove options that assume
> mercurial as the code repository.
Shall we also update the copyright y
On Mon, 29 Nov 2021 18:48:45 GMT, Naoto Sato wrote:
> Fixing tests that fail at DST->STD offset transition. Simply skipping the
> tests on that occasion.
This pull request has now been integrated.
Changeset: f1c20e91
Author:Naoto Sato
URL:
https://git.openjdk.java.net/jdk/commit/f1
> Following integration of the second incubator of the foreign function and
> memory API [1], we detected few divergences between the contents of the jdk
> repo and the panama repo:
>
> * the name of some of the `FunctionDescriptor` wither methods is different
> (e.g. `withAppendedLayoutArgumen
On Thu, 11 Nov 2021 13:59:51 GMT, Jim Laskey wrote:
> The modified ziggurat algorithm is not correctly implemented in
> `java.base/jdk/internal/util/random/RandomSupport.java`.
>
> Create a histogram of a million samples using 2000 uniform bins with the
> following range:
> Exponential range
> The time to get JDK 19 underway draws nigh, please review this usual set of
> start-of-release updates, including CSRs for the javac and javax.lang.model
> updates:
>
> JDK-8277512: Add SourceVersion.RELEASE_19
> https://bugs.openjdk.java.net/browse/JDK-8277512
>
> JDK-8277514: Add source 19
> Add a new --source-date (epoch seconds) option to jar and jmod to
> allow specification of time to use for created/updated jar/jmod entries. This
> then allows the ability to make the content deterministic.
>
> Signed-off-by: Andrew Leonard
Andrew Leonard has updated the pull request increm
On Thu, 11 Nov 2021 13:59:51 GMT, Jim Laskey wrote:
> The modified ziggurat algorithm is not correctly implemented in
> `java.base/jdk/internal/util/random/RandomSupport.java`.
>
> Create a histogram of a million samples using 2000 uniform bins with the
> following range:
> Exponential range
> Add a new --source-date (epoch seconds) option to jar and jmod to
> allow specification of time to use for created/updated jar/jmod entries. This
> then allows the ability to make the content deterministic.
>
> Signed-off-by: Andrew Leonard
Andrew Leonard has updated the pull request increm
On Mon, 29 Nov 2021 21:59:31 GMT, Naoto Sato wrote:
>> Fixing tests that fail at DST->STD offset transition. Simply skipping the
>> tests on that occasion.
>
> Naoto Sato has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Changed to not skipp
> Add a new --source-date (epoch seconds) option to jar and jmod to
> allow specification of time to use for created/updated jar/jmod entries. This
> then allows the ability to make the content deterministic.
>
> Signed-off-by: Andrew Leonard
Andrew Leonard has updated the pull request with a
On Tue, 30 Nov 2021 19:22:53 GMT, Paul Sandoz wrote:
> Remove Vector API scripts for building and running tests. `jtreg` should be
> used instead.
>
> Also updated the test generation script to remove options that assume
> mercurial as the code repository.
Looks good to me.
-
Ma
On Mon, 29 Nov 2021 08:18:47 GMT, Сергей Цыпанов wrote:
>> Instead of something like
>>
>> long x;
>> long y;
>> return (x < y) ? -1 : ((x == y) ? 0 : 1);
>>
>> we can use `return Long.compare(x, y);`
>>
>> All replacements are done with IDE.
>
> Сергей Цыпанов has updated the pull request inc
On Mon, 22 Nov 2021 22:59:21 GMT, PROgrm_JARvis wrote:
> This is a trivial fix to make `String(String)` constructor copy the value of
> `hashIsZero` field.
Marked as reviewed by rriggs (Reviewer).
-
PR: https://git.openjdk.java.net/jdk/pull/6511
On Mon, 22 Nov 2021 22:59:21 GMT, PROgrm_JARvis wrote:
> This is a trivial fix to make `String(String)` constructor copy the value of
> `hashIsZero` field.
This pull request has now been integrated.
Changeset: e30e6767
Author:Petr Portnov
Committer: Roger Riggs
URL:
https://git.op
I think you are saying that to kill a thread running native code I would need
to use native code. Is that right?
> On Nov 30, 2021, at 10:17 AM, Alan Bateman wrote:
>
> On 30/11/2021 17:13, Alan Snyder wrote:
>> Although I understand the potential dangers of using Thread.stop, it seems
>> to m
On Wed, 24 Nov 2021 15:39:13 GMT, Roger Riggs wrote:
>> If the intent is to disable serialization entirely, then this state should
>> be represented explicitly. Having things throw `NoClassDefFoundError` looks
>> like a mistake and a bug that needs to be fixed. In addition, it requires
>> that
On Tue, 30 Nov 2021 18:53:26 GMT, Joe Wang wrote:
> The result of Util.baseName(systemId) can be empty, causing the compiler to
> set an empty classname. Add a check to make sure it will not set the empty
> classname.
>
> Alternatively, it may report an error, but that would be disruptive. As
> The result of Util.baseName(systemId) can be empty, causing the compiler to
> set an empty classname. Add a check to make sure it will not set the empty
> classname.
>
> Alternatively, it may report an error, but that would be disruptive. As the
> transform can proceed without the provided cl
On Tue, 30 Nov 2021 20:00:19 GMT, John Neffenger wrote:
> > Whichever we use, we have to use e.setTimeLocal(), so can't see what the
> > difference is?
>
> Okay, here's a brief command-line example before posting the code example. In
> my experience, most people trying to set up a common, proj
On Tue, 30 Nov 2021 19:37:23 GMT, Andrew Leonard wrote:
> Whichever we use, we have to use e.setTimeLocal(), so can't see what the
> difference is?
Okay, here's a brief command-line example before posting the code example. In
my experience, most people trying to set up a common, project-wide b
On Tue, 30 Nov 2021 18:57:55 GMT, Andrew Leonard wrote:
> I'm also adding --date validation of 1980->2099
I am only now catching up with you on that issue. 😄 I wrote a very short
program that illustrates that problem (and all the other ones) very clearly for
anyone to see. I'll post it shortl
On Tue, 30 Nov 2021 19:31:37 GMT, John Neffenger wrote:
> > Both basically truncate the timezone.
>
> There's a difference. The first option saves a DOS date and time that depends
> on the time zone of the build machine due to the ISO 8601 string returned by
> default from the `git` and `date`
Remove Vector API scripts for building and running tests. `jtreg` should be
used instead.
Also updated the test generation script to remove options that assume mercurial
as the code repository.
-
Commit messages:
- JDK-8278014: [vectorapi] Remove test run script
Changes: https://
On Tue, 30 Nov 2021 18:52:56 GMT, Andrew Leonard wrote:
> Both basically truncate the timezone.
There's a difference. The first option saves a DOS date and time that depends
on the time zone of the build machine due to the ISO 8601 string returned by
default from the `git` and `date` commands,
On Tue, 30 Nov 2021 18:53:26 GMT, Joe Wang wrote:
> The result of Util.baseName(systemId) can be empty, causing the compiler to
> set an empty classname. Add a check to make sure it will not set the empty
> classname.
>
> Alternatively, it may report an error, but that would be disruptive. As
On Mon, 22 Nov 2021 22:59:21 GMT, PROgrm_JARvis wrote:
> This is a trivial fix to make `String(String)` constructor copy the value of
> `hashIsZero` field.
Hi there, could anyone please sponsor this change if it is still applicable?
Thanks in advance!
-
PR: https://git.openjdk.ja
OpenJDK tiered tests definitions have the catch-all `tier4` that runs all tests
not defined in the lower tiers. `hotspot:tier4` has lots of them, mostly
long-running vmTestbase tests, which take many hours even on a very parallel
machines.
This, unfortunately, has a chilling effect on `jdk:tier
The result of Util.baseName(systemId) can be empty, causing the compiler to set
an empty classname. Add a check to make sure it will not set the empty
classname.
Alternatively, it may report an error, but that would be disruptive. As the
transform can proceed without the provided classname (by
On Thu, 11 Nov 2021 13:59:51 GMT, Jim Laskey wrote:
> The modified ziggurat algorithm is not correctly implemented in
> `java.base/jdk/internal/util/random/RandomSupport.java`.
>
> Create a histogram of a million samples using 2000 uniform bins with the
> following range:
> Exponential range
On Mon, 29 Nov 2021 16:22:30 GMT, Andrew Leonard wrote:
>> Add a new --source-date (epoch seconds) option to jar and jmod
>> to allow specification of time to use for created/updated jar/jmod entries.
>> This then allows the ability to make the content deterministic.
>>
>> Signed-off-by: Andr
On Tue, 30 Nov 2021 13:20:32 GMT, Maurizio Cimadamore
wrote:
>> Following integration of the second incubator of the foreign function and
>> memory API [1], we detected few divergences between the contents of the jdk
>> repo and the panama repo:
>>
>> * the name of some of the `FunctionDescri
On Tue, 30 Nov 2021 16:26:28 GMT, John Neffenger wrote:
> > So what you suggest sounds reasonable, although it would be a "behaviour
> > change" in that whereas now if the date is between 1980->2106 only a
> > xdostime is stored, we would now always be storing the additional "mtime"
> > field
On Thu, 25 Nov 2021 00:31:46 GMT, Pavel Rappo wrote:
>> JDK-8276674 : Malformed Javadoc inline tags in JDK source in java/util/stream
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/util/RawDiagnosticFormatter.java
> line 63:
>
>> 61: * Helper class to generate stable positions for
On Tue, 30 Nov 2021 14:28:05 GMT, Jaikiran Pai wrote:
> Can I please get a review for this change which fixes a typo in the javadoc
> of `java.util.zip.ZipEntry.setTime()` method?
Marked as reviewed by lancea (Reviewer).
-
PR: https://git.openjdk.java.net/jdk/pull/6615
On Tue, 30 Nov 2021 14:52:37 GMT, Alan Bateman wrote:
> Thread.stop is inherently unsafe and has been deprecated since Java 1.2
> (1998). It's time to terminally deprecate this method so it can be degraded
> and removed in the future.
>
> This PR does not propose any changes to the JVM TI Stop
On 30/11/2021 17:13, Alan Snyder wrote:
Although I understand the potential dangers of using Thread.stop, it seems to
me there are cases where its use is legitimate and valuable.
The examples I am thinking of involve a potentially long running computation
whose result is no longer needed.
In p
On Tue, 30 Nov 2021 18:00:38 GMT, Joe Wang wrote:
>> Add setProperty/getProperty methods to the XPath API so that properties can
>> be supported in the future.
>
> Joe Wang has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Add a statement to
> Add setProperty/getProperty methods to the XPath API so that properties can
> be supported in the future.
Joe Wang has updated the pull request incrementally with one additional commit
since the last revision:
Add a statement to clarify the space of the properties
-
Changes:
On Tue, 30 Nov 2021 14:52:37 GMT, Alan Bateman wrote:
> Thread.stop is inherently unsafe and has been deprecated since Java 1.2
> (1998). It's time to terminally deprecate this method so it can be degraded
> and removed in the future.
>
> This PR does not propose any changes to the JVM TI Stop
On Tue, 30 Nov 2021 14:28:05 GMT, Jaikiran Pai wrote:
> Can I please get a review for this change which fixes a typo in the javadoc
> of `java.util.zip.ZipEntry.setTime()` method?
Marked as reviewed by iris (Reviewer).
-
PR: https://git.openjdk.java.net/jdk/pull/6615
Although I understand the potential dangers of using Thread.stop, it seems to
me there are cases where its use is legitimate and valuable.
The examples I am thinking of involve a potentially long running computation
whose result is no longer needed.
In particular, I am thinking of pure computati
On Thu, 18 Nov 2021 19:09:18 GMT, Ravi Reddy wrote:
>> Hi all,
>>
>> Please review this fix for Infinite loop in ZipOutputStream.close().
>> The main issue here is when ever there is an exception during close
>> operations on GZip we are not setting the deflator to a finished state which
>> is
On Tue, 30 Nov 2021 12:00:59 GMT, Andrew Leonard wrote:
> So what you suggest sounds reasonable, although it would be a "behaviour
> change" in that whereas now if the date is between 1980->2106 only a xdostime
> is stored, we would now always be storing the additional "mtime" field ...
No, so
On Tue, 30 Nov 2021 14:52:37 GMT, Alan Bateman wrote:
> Thread.stop is inherently unsafe and has been deprecated since Java 1.2
> (1998). It's time to terminally deprecate this method so it can be degraded
> and removed in the future.
>
> This PR does not propose any changes to the JVM TI Stop
I don’t see how a restricted reference by itself is useful, if you cannot
depend upon the object not being mutated via other references.
Agree; this may help you do local proofs of correctness, and may conceivably
help the JIT (though, its pretty smart about figuring this stuff out on its
own),
Thread.stop is inherently unsafe and has been deprecated since Java 1.2 (1998).
It's time to terminally deprecate this method so it can be degraded and removed
in the future.
This PR does not propose any changes to the JVM TI StopThread function (or the
corresponding JDWP command or JDI method)
On Mon, 29 Nov 2021 16:22:30 GMT, Andrew Leonard wrote:
>> Add a new --source-date (epoch seconds) option to jar and jmod
>> to allow specification of time to use for created/updated jar/jmod entries.
>> This then allows the ability to make the content deterministic.
>>
>> Signed-off-by: Andr
On Tue, 30 Nov 2021 08:53:03 GMT, John Neffenger wrote:
>> @andrew-m-leonard Thank you, Andrew, for your bold solution to Mark's
>> request -- one that even solves the problem with the current `ZipEntry` API!
>>
>> Would you be willing to consider a minor change to your implementation?
>>
>> A
Hello Andrew,
On 30/11/21 7:32 pm, Andrew Leonard wrote:
On Mon, 29 Nov 2021 16:22:30 GMT, Andrew Leonard wrote:
Add a new --source-date (epoch seconds) option to jar and jmod to
allow specification of time to use for created/updated jar/jmod entries. This then
allows the ability to make t
Ah, I suspect the getTime() for xdostime performance issue relates to this:
https://bugs.openjdk.java.net/browse/JDK-4981560
which is not relevant any more since dosToJavaTime() is now implemented
differently
On Tue, Nov 30, 2021 at 2:44 PM Andrew Leonard wrote:
> Thanks Alan,
> Having tried
Thanks Alan,
Having tried implementing a Zoned option, I agree it does seem to bloat
ZipEntry a bit.
As JohnN's suggestion pointed out we could at some point move to always
setting the extended
mtime(FileTime), but we have 78years until we really need to worry about
that! (xdostime covers to 2099)
On Tue, 30 Nov 2021 14:28:05 GMT, Jaikiran Pai wrote:
> Can I please get a review for this change which fixes a typo in the javadoc
> of `java.util.zip.ZipEntry.setTime()` method?
Marked as reviewed by alanb (Reviewer).
-
PR: https://git.openjdk.java.net/jdk/pull/6615
Can I please get a review for this change which fixes a typo in the javadoc of
`java.util.zip.ZipEntry.setTime()` method?
-
Commit messages:
- 8277986: Typo in javadoc of java.util.zip.ZipEntry#setTime
Changes: https://git.openjdk.java.net/jdk/pull/6615/files
Webrev: https://webre
On Mon, 29 Nov 2021 16:22:30 GMT, Andrew Leonard wrote:
>> Add a new --source-date (epoch seconds) option to jar and jmod
>> to allow specification of time to use for created/updated jar/jmod entries.
>> This then allows the ability to make the content deterministic.
>>
>> Signed-off-by: Andr
On Mon, 29 Nov 2021 18:32:30 GMT, Maurizio Cimadamore
wrote:
>> Following integration of the second incubator of the foreign function and
>> memory API [1], we detected few divergences between the contents of the jdk
>> repo and the panama repo:
>>
>> * the name of some of the `FunctionDescri
> Following integration of the second incubator of the foreign function and
> memory API [1], we detected few divergences between the contents of the jdk
> repo and the panama repo:
>
> * the name of some of the `FunctionDescriptor` wither methods is different
> (e.g. `withAppendedLayoutArgumen
On 29/11/2021 19:25, Andrew Leonard wrote:
*Problem:*
PRhttps://github.com/openjdk/jdk/pull/6481
addresses the main problems with deterministic timestamping of Zip entries,
with
the introduction of a new --date option for jar & jmod.
However, the ZipEntry timestamp is constructed from a combinat
On Mon, 29 Nov 2021 16:22:30 GMT, Andrew Leonard wrote:
>> Add a new --source-date (epoch seconds) option to jar and jmod
>> to allow specification of time to use for created/updated jar/jmod entries.
>> This then allows the ability to make the content deterministic.
>>
>> Signed-off-by: Andr
On Tue, 30 Nov 2021 08:53:03 GMT, John Neffenger wrote:
>> @andrew-m-leonard Thank you, Andrew, for your bold solution to Mark's
>> request -- one that even solves the problem with the current `ZipEntry` API!
>>
>> Would you be willing to consider a minor change to your implementation?
>>
>> A
On Mon, 15 Nov 2021 21:35:06 GMT, Roman Kennke wrote:
>> The caches in ObjectStreamClass basically map WeakReference to
>> SoftReference, where the ObjectStreamClass also
>> references the same Class. That means that the cache entry, and thus the
>> class and its class-loader, will not get rec
> The caches in ObjectStreamClass basically map WeakReference to
> SoftReference, where the ObjectStreamClass also references
> the same Class. That means that the cache entry, and thus the class and its
> class-loader, will not get reclaimed, unless the GC determines that memory
> pressure is
On Tue, 30 Nov 2021 08:31:54 GMT, John Neffenger wrote:
> Would you be willing to consider a minor change to your implementation?
Just to be clear, this change should let us postpone any additions to the
`ZipEntry` API for another day, if at all, and maybe even get this pull request
integrated
On Mon, 29 Nov 2021 19:27:57 GMT, Andrew Leonard wrote:
>>> @AlanBateman yes, see above comment, thanks
>>
>> This is a significant change to the ZipEntry API that will require
>> discussion and agreement. Can you start a discussion on core-libs-dev about
>> the topic? You could start with a s
78 matches
Mail list logo
