Thank you both Martin and David for your inputs.
On 25/06/20 5:40 am, David Holmes wrote:
> Hi Jaikiran,
>
>
>> The patch is available as a webrev at
>> https://cr.openjdk.java.net/~jpai/webrev/8240148/1/
>>
>> The patch updates the ScheduledThreadPoolExecutor.execute(Runnable) to
>> wrap the
The java.io.File has a toURI() API which returns a (system dependent)
URI as per its javadoc. The java.io.File also has a toPath() API which
then exposes a toUri() API from the java.nio.file.Path. The javadoc of
the File class doesn't specify any semantics about the toUri() returned
by the
On Tue, 2 Feb 2021 02:25:04 GMT, Jaikiran Pai wrote:
> > The code change looks all right.
>
> Should I go ahead and integrate this?
Actually, I didn't notice that this PR wasn't marked as reviewed. I'll wait for
the review(s) then.
-
PR: https://git.openjdk.java.
On Mon, 1 Feb 2021 19:21:23 GMT, Brian Burkhalter wrote:
>> Can I please get a review for this change which proposes to fix the issue
>> reported in https://bugs.openjdk.java.net/browse/JDK-8260401?
>>
>> As noted in that issue, when the constructor of
>> `java.util.prefs.WindowsPreferences`
Can I please get a review for this change which proposes to fix the issue
reported in https://bugs.openjdk.java.net/browse/JDK-8260401?
As noted in that issue, when the constructor of
`java.util.prefs.WindowsPreferences` runs into an error while dealing with the
Windows registry, it logs a
Hello David,
On 11/06/21 11:41 am, David Holmes wrote:
Hi,
On 10/06/2021 8:58 pm, Сергей Цыпанов wrote:
Hello, in the pipeline of my JDK fork the mentioned build step
constantly fails even providing I modify only Java code
I see this message in the log
Compiling 2 files for
Hello Alan,
On 04/07/21 8:47 pm, Alan Bateman wrote:
On 03/07/2021 17:19, Jaikiran Pai wrote:
:
There are still some decisions to be made:
1. Should we introduce this new property or should we enhance the
existing "useTempFile" property to allow a size to be passed?
It's an impl
some smaller default
> value. However, I think that can be addressed separately while dealing with
> https://bugs.openjdk.java.net/browse/JDK-8011146
Jaikiran Pai has updated the pull request incrementally with one additional
commit since the last revision:
minor update to comme
some smaller default
> value. However, I think that can be addressed separately while dealing with
> https://bugs.openjdk.java.net/browse/JDK-8011146
Jaikiran Pai has updated the pull request incrementally with three additional
commits since the last revision:
- remove no longer us
some smaller default
> value. However, I think that can be addressed separately while dealing with
> https://bugs.openjdk.java.net/browse/JDK-8011146
Jaikiran Pai has updated the pull request incrementally with one additional
commit since the last revision:
reorganize the tests now t
age-private visibility, so this change shouldn't impact any other
> usage/expectations.
>
> A new jtreg test has been added to reproduce this issue and verify the fix.
> Local testing of the `test/jdk/jdk/nio/` (including this new test) went fine
> without any issues after this c
Hello Lance,
On 02/07/21 4:42 pm, Lance Andersen wrote:
Hi Jaikiran,
Consider:
try (var os = Files.newOutputStream(ZIPFILE);
ZipOutputStream zos = new ZipOutputStream(os)) {
zos.putNextEntry(new ZipEntry("../Hello.txt"));
zos.write("Hello
On Fri, 2 Jul 2021 10:25:29 GMT, Jaikiran Pai wrote:
>> Can I please get a review of this proposed fix for
>> https://bugs.openjdk.java.net/browse/JDK-8251329?
>>
>> As noted in that issue, if a zip filesystem created on top of a jar
>> containing
age-private visibility, so this change shouldn't impact any other
> usage/expectations.
>
> A new jtreg test has been added to reproduce this issue and verify the fix.
> Local testing of the `test/jdk/jdk/nio/` (including this new test) went fine
> without any issues aft
some smaller default
> value. However, I think that can be addressed separately while dealing with
> https://bugs.openjdk.java.net/browse/JDK-8011146
Jaikiran Pai has updated the pull request incrementally with one additional
commit since the last revision:
Introduce a way to allow outp
On Wed, 30 Jun 2021 16:05:40 GMT, Jaikiran Pai wrote:
>> Can I please get a review for this proposed fix for the issue reported in
>> https://bugs.openjdk.java.net/browse/JDK-8190753?
>>
>> The commit here checks for the size of the zip entry
Thank you Alan and Lance. I'll update this PR shortly with the proposed
approach.
-Jaikiran
On 01/07/21 2:13 pm, Alan Bateman wrote:
On 30/06/2021 17:15, Jaikiran Pai wrote:
I understand that Alan's suggestion holds good and we should have
some logic in place which switches to using a temp
age-private visibility, so this change shouldn't impact any other
> usage/expectations.
>
> A new jtreg test has been added to reproduce this issue and verify the fix.
> Local testing of the `test/jdk/jdk/nio/` (including this new test) went fine
> without any issues aft
some smaller default
> value. However, I think that can be addressed separately while dealing with
> https://bugs.openjdk.java.net/browse/JDK-8011146
Jaikiran Pai has updated the pull request incrementally with two additional
commits since the last revision:
- an initial proposed te
Hello Lance,
On 29/06/21 11:31 pm, Lance Andersen wrote:
I ran your current test 150 times and the max runtime was 25 seconds, most
cases were in the 18-20 second range on our slower test boxes.
Thank you for running those tests. Do you think those timings are good
enough to let that test
On Thu, 1 Jul 2021 13:05:26 GMT, Alan Bateman wrote:
>> Jaikiran Pai has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> implement review suggestion - move isSelfOrParent to ZipPath class
>
> src/jdk.zip
Hello Alan,
On 28/06/21 1:00 pm, Alan Bateman wrote:
I didn't study the test too closely but just to mention that tests with zip
entries > 2GB can be problematic to test. The test will probably need the
@requires tag to limit it to 64-bit systems and maybe some minimum memory size. It
may
some smaller default
> value. However, I think that can be addressed separately while dealing with
> https://bugs.openjdk.java.net/browse/JDK-8011146
Jaikiran Pai has updated the pull request incrementally with one additional
commit since the last revision:
add @requires to the
Hello Lance,
Please take your time.
-Jaikiran
On 29/06/21 4:17 am, Lance Andersen wrote:
Hi Jaikiran,
This is on my list to look at but did not get to today.
Best
Lance
On Jun 27, 2021, at 11:52 PM, Jaikiran Pai
mailto:j...@openjdk.java.net>> wrote:
Can I please get a
Can I please get a review of this proposed fix for
https://bugs.openjdk.java.net/browse/JDK-8251329?
As noted in that issue, if a zip filesystem created on top of a jar containing
a "./" entry is "walked" using the `Files.walkFileTree`, it leads to a infinite
never ending iteration (which
On 12/07/21 2:08 am, Lance Andersen wrote:
On Mon, 5 Jul 2021 07:42:26 GMT, Jaikiran Pai wrote:
Can I please get a review for this proposed fix for the issue reported in
https://bugs.openjdk.java.net/browse/JDK-8190753?
The commit here checks for the size of the zip entry before trying
On 05/07/21 10:52 am, Jaikiran Pai wrote:
4. I've never previously created a manual test case. The
`LargeCompressedEntrySizeTest` in this PR is expected to be a manual
test case (given how long it might take to run on various different
systems). The only difference between this test case
On Wed, 30 Jun 2021 15:45:25 GMT, Weijun Wang wrote:
>> Add a cache to record which sources have called `System::setSecurityManager`
>> and only print out warning lines once for each.
>
> Weijun Wang has updated the pull request incrementally with one additional
> commit since the last
Can I please get a review for this proposed fix for the issue reported in
https://bugs.openjdk.java.net/browse/JDK-8190753?
The commit here checks for the size of the zip entry before trying to create a
`ByteArrayOutputStream` for that entry's content. A new jtreg test has been
included in
some smaller default
> value. However, I think that can be addressed separately while dealing with
> https://bugs.openjdk.java.net/browse/JDK-8011146
Jaikiran Pai has updated the pull request incrementally with one additional
commit since the last revision:
propagate back the origina
On Thu, 1 Apr 2021 15:02:42 GMT, Jaikiran Pai wrote:
>> Can I please get a review for this patch which proposes to implement the
>> enhancement request noted in
>> https://bugs.openjdk.java.net/browse/JDK-8173970?
>>
>> The commit in this PR introduces the
Based on the inputs so far, I've updated the PR to include the provided
feedback. Since the PR code review hadn't yet started, I decided to do a
force push to the PR so that we can start it afresh.
Command option:
In this current discussion, we seem to have an agreement for using -C
and
alization files corresponding to this one
> (for example: `jar_de.properties`), because I don't know what process needs
> to be followed to have those files updated (if at all they need to be
> updated).
>
> The commit also includes a jtreg testcase which verifies the usage of t
ner (other than maybe code comments), but I wanted
to bring this up so that we can come to a decision and have the proposed
implementation work in that manner.
-Jaikiran
On 24/03/21 4:10 pm, Jaikiran Pai wrote:
Based on the inputs so far, I've updated the PR to include the
provided feedback. Since
alization files corresponding to this one
> (for example: `jar_de.properties`), because I don't know what process needs
> to be followed to have those files updated (if at all they need to be
> updated).
>
> The commit also includes a jtreg testcase which verifies the usage of this
On 28/03/21 9:52 pm, Lance Andersen wrote:
On Mar 28, 2021, at 9:24 AM, Jaikiran Pai <mailto:jai.forums2...@gmail.com>> wrote:
Now when the user explicitly specifies the new -C or --dir option
with the -P option for extract, something like:
jar -xfP foo.jar -C /tmp/hello
alization files corresponding to this one
> (for example: `jar_de.properties`), because I don't know what process needs
> to be followed to have those files updated (if at all they need to be
> updated).
>
> The commit also includes a jtreg testcase which verifies the usage of this
On Wed, 31 Mar 2021 17:22:55 GMT, Lance Andersen wrote:
>> Jaikiran Pai has updated the pull request incrementally with two additional
>> commits since the last revision:
>>
>> - Alan's review feedback for -C help text
>> - Keep -xfP backward compatible but
On Sat, 27 Mar 2021 16:02:55 GMT, Alan Bateman wrote:
>> Can I please get a review for this patch which proposes to implement the
>> enhancement request noted in
>> https://bugs.openjdk.java.net/browse/JDK-8173970?
>>
>> The commit in this PR introduces the `-o` and `--output-dir` option to
ludes a jtreg testcase which (consistently)
> reproduces the deadlock without the fix and passes when this fix is applied.
> Extra manual testing has been done to verify that the classes of interest
> (noted in that testcase) are indeed getting loaded in those concurrent
> t
On Mon, 15 Mar 2021 17:15:59 GMT, Chris Hegarty wrote:
>>> What you have is probably fine, but has any consideration been given to
>>> using the initialization-on-demand holder idiom? e.g.
>>>
>>> ```
>>> static private class CanonicalMapHolder {
>>> static final Map,
>>> ConstantDesc>>
On Tue, 16 Mar 2021 02:34:39 GMT, Jaikiran Pai wrote:
>>> If you and others think that we can ignore this case, then your proposed
>>> approach of using this lazy holder for initialization, IMO, is much cleaner
>>> and natural to read and I will go ahea
ludes a jtreg testcase which (consistently)
> reproduces the deadlock without the fix and passes when this fix is applied.
> Extra manual testing has been done to verify that the classes of interest
> (noted in that testcase) are indeed getting loaded in those concurrent
> t
On Fri, 12 Mar 2021 14:53:45 GMT, Chris Hegarty wrote:
> What you have is probably fine, but has any consideration been given to using
> the initialization-on-demand holder idiom? e.g.
>
> ```
> static private class CanonicalMapHolder {
> static final Map,
> ConstantDesc>> CANONICAL_MAP
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
ludes a jtreg testcase which (consistently)
> reproduces the deadlock without the fix and passes when this fix is applied.
> Extra manual testing has been done to verify that the classes of interest
> (noted in that testcase) are indeed getting loaded in those concurrent
> t
On Tue, 16 Mar 2021 12:19:11 GMT, Peter Levart wrote:
> Perhaps you could just add a warning to the DynamicConstantDesc.ofCanonical()
> method javadoc/comment about what NOT to do in order to not fall into the
> deadlock trap again... (like: don't call this method from static initializer
> of
On 17/03/21 8:51 am, Jaikiran Pai wrote:
Test results are from latest Java 16 release on a Windows setup.
Just gave a quick try against Java 8 (java.version=1.8.0_252) and it
fails on that version too with the same error:
Exception in thread "main" java.nio.file.InvalidPat
Please consider this trivial code:
import java.io.*;
import java.nio.file.*;
public class FileTest {
public static void main(final String[] args) throws Exception {
System.getProperties().list(System.out);
final File f = new File("NUL:");
try (final InputStream fis =
On 17/03/21 1:26 pm, Alan Bateman wrote:
On 17/03/2021 03:21, Jaikiran Pai wrote:
:
The code tries to read from NUL: on a Windows setup. This code runs
into the following exception on Windows when the
java.io.File#toPath() gets invoked:
Exception in thread "
On Wed, 17 Mar 2021 14:34:41 GMT, Peter Levart wrote:
>> Jaikiran Pai has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Add a comment to instruct future maintainers of the code to avoid calling
>> DynamicC
Hello Alan,
On 17/03/21 2:45 pm, Alan Bateman wrote:
On 17/03/2021 08:21, Jaikiran Pai wrote:
:
I can confirm that using "NUL" or "nul" work fine in the above code,
I don't know the context for your question
A while back Apache Ant switched to using the
On 17/03/21 3:10 pm, Jaikiran Pai wrote:
Hello Alan,
On 17/03/21 2:45 pm, Alan Bateman wrote:
On 17/03/2021 08:21, Jaikiran Pai wrote:
:
I can confirm that using "NUL" or "nul" work fine in the above code,
I don't know the context for your question
A while back
On Tue, 9 Mar 2021 13:46:04 GMT, Jaikiran Pai wrote:
> An alternate approach that I thought of was to completely get rid of this
> shared cache canonicalMap and instead just use method level map (that gets
> initialized each time) in the tryCanonicalize method (thus requiring no
Can I please get a review for this proposed patch for the issue reported in
https://bugs.openjdk.java.net/browse/JDK-8263108?
As noted in that issue, the `java.lang.constant.DynamicConstantDesc` and
`java.lang.constant.ConstantDescs` can end up in a classloading deadlock due to
the nature of
On 22/03/21 2:36 pm, Alan Bateman wrote:
On 20/03/2021 07:16, Jaikiran Pai wrote:
:
I received some inputs on that Ant bugzilla issue. Based on that, I
was able to reproduce the exception and IMO it's a bug in
Files.newOutputStream() API. I have opened
https://bugs.openjdk.java.net/browse
On 17/03/21 3:16 pm, Jaikiran Pai wrote:
On 17/03/21 3:10 pm, Jaikiran Pai wrote:
Hello Alan,
On 17/03/21 2:45 pm, Alan Bateman wrote:
On 17/03/2021 08:21, Jaikiran Pai wrote:
:
I can confirm that using "NUL" or "nul" work fine in the above code,
I don't know
On Wed, 10 Mar 2021 06:36:58 GMT, Jaikiran Pai wrote:
>> Your code change Looks reasonable to me. Although i am not export in this
>> area but what i observed is the test case which was attached by original
>> submitter passes null to DynamicConstantDesc as follows
>>
On Tue, 9 Mar 2021 13:46:04 GMT, Jaikiran Pai wrote:
> Can I please get a review for this proposed patch for the issue reported in
> https://bugs.openjdk.java.net/browse/JDK-8263108?
>
> As noted in that issue, the `java.lang.constant.Dynamic
ludes a jtreg testcase which (consistently)
> reproduces the deadlock without the fix and passes when this fix is applied.
> Extra manual testing has been done to verify that the classes of interest
> (noted in that testcase) are indeed getting loaded in those concurrent
> t
On Tue, 9 Mar 2021 17:50:26 GMT, Peter Levart wrote:
>>> An alternate approach that I thought of was to completely get rid of this
>>> shared cache canonicalMap and instead just use method level map (that gets
>>> initialized each time) in the tryCanonicalize method (thus requiring no
>>>
On Wed, 10 Mar 2021 05:23:51 GMT, Vyom Tewari wrote:
> but what i observed is the test case which was attached by original submitter
> passes null to DynamicConstantDesc as follows "DynamicConstantDesc.of(null)".
> If you pass valid argument like(ConstantDescs.BSM_INVOKE) no deadlock.
Hello
On Feb 24, 2021, at 10:56 PM, Jaikiran Pai <mailto:jai.forums2...@gmail.com>> wrote:
The javadoc of InputStream#readAllBytes() states[1] that it reads all
the remaining bytes of the stream. The java.util.zip.ZipInputStream
doesn't override this method and thus "inherits
On 27/02/21 1:17 am, Lance Andersen wrote:
I believe this would also warrant a CSR to be created as well as
updates to the jar man page.
I haven't created a CSR before, so I will need some guidance on that
part. Is it usually created after all the implementation details have
been
Hello Lance,
On 27/02/21 1:17 am, Lance Andersen wrote:
p.s. I think it would be useful in the future to start the discussion
on core-libs-dev prior to creating a PR (or leave it as a draft PR)
for a feature request.
Thank you for that input, I'll keep that in mind for any similar work in
I just created https://bugs.openjdk.java.net/browse/JDK-8262435 to track
this.
-Jaikiran
On 25/02/21 9:05 pm, Jaikiran Pai wrote:
Thank you Lance and Alan. I do have access to JBS, I'll file one
tomorrow with the details.
-Jaikiran
On 25/02/21 9:04 pm, Lance Andersen wrote:
Hi Jaikiran
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 Feb 27, 2021, at 11:19 PM, Jaikiran Pai <mailto:jai.forums2...@gmail.com>> wrote:
Hello Alan,
On 27/02/21 2:23 pm, Alan Bateman wrote:
Yes, the option name will need to be agreed. It would be useful to
enumerate the options that the other tools are using to specify the
locat
The javadoc of InputStream#readAllBytes() states[1] that it reads all
the remaining bytes of the stream. The java.util.zip.ZipInputStream
doesn't override this method and thus "inherits" this javadoc. The
implementation of InputStream#readAllBytes() ultimately ends up calling
Hello Alan,
On 27/02/21 2:23 pm, Alan Bateman wrote:
Yes, the option name will need to be agreed. It would be useful to
enumerate the options that the other tools are using to specify the
location where to extract. If you see JBS issues mentioning tar -C not
supporting chdir when extracting
Can I please get a review for this patch which proposes to implement the
enhancement request noted in https://bugs.openjdk.java.net/browse/JDK-8173970?
The commit in this PR introduces the `-o` and `--output-dir` option to the
`jar` command. The option takes a path to a destination directory as
and is probably what hid this
> issue in the first place? To fix this, I have added an additional commit
> which updates this test case to properly test the `AM_PM` field values.
Jaikiran Pai has updated the pull request incrementally with three additional
commits since the last revisio
On Wed, 14 Apr 2021 18:01:10 GMT, Naoto Sato wrote:
>> Jaikiran Pai has updated the pull request incrementally with two additional
>> commits since the last revision:
>>
>> - Update existing NarrowNamesTest to match expectations
>> - Naoto's review suggestion
&
On Thu, 15 Apr 2021 03:57:18 GMT, Naoto Sato wrote:
>> Jaikiran Pai has updated the pull request incrementally with three
>> additional commits since the last revision:
>>
>> - update existing testcase based on review comment
>> - Improve code comment to
On Tue, 13 Apr 2021 17:56:12 GMT, Naoto Sato wrote:
>Have you run regression tests in java.time? If I am not mistaken, your changes
>simply seem to nullify the day period support.
Hello @naotoj, my tier1 test run passed without issues locally with this change:
==
On Tue, 13 Apr 2021 11:42:41 GMT, Jaikiran Pai wrote:
> Can I please get a review for this proposed fix for
> https://bugs.openjdk.java.net/browse/JDK-8262108?
>
> As noted in a comment in that issue, the bug relates to the return value of
> `Calendar.getDisplayNames` for the
Can I please get a review for this proposed fix for
https://bugs.openjdk.java.net/browse/JDK-8262108?
As noted in a comment in that issue, the bug relates to the return value of
`Calendar.getDisplayNames` for the `Calendar.AM_PM` field. The implementation
has started returning invalid values
and is probably what hid this
> issue in the first place? To fix this, I have added an additional commit
> which updates this test case to properly test the `AM_PM` field values.
Jaikiran Pai has updated the pull request incrementally with two additional
commits since the last revisi
On Tue, 13 Apr 2021 11:42:41 GMT, Jaikiran Pai wrote:
> Can I please get a review for this proposed fix for
> https://bugs.openjdk.java.net/browse/JDK-8262108?
>
> As noted in a comment in that issue, the bug relates to the return value of
> `Calendar.getDisplayNames` for the
and is probably what hid this
> issue in the first place? To fix this, I have added an additional commit
> which updates this test case to properly test the `AM_PM` field values.
Jaikiran Pai has updated the pull request incrementally with two additional
commits since the last revisi
On Wed, 14 Apr 2021 17:14:55 GMT, Jaikiran Pai wrote:
>> Can I please get a review for this proposed fix for
>> https://bugs.openjdk.java.net/browse/JDK-8262108?
>>
>> As noted in a comment in that issue, the bug relates to the return value of
>
On Tue, 13 Apr 2021 11:42:41 GMT, Jaikiran Pai wrote:
> Can I please get a review for this proposed fix for
> https://bugs.openjdk.java.net/browse/JDK-8262108?
>
> As noted in a comment in that issue, the bug relates to the return value of
> `Calendar.getDisplayNames` for the
On Fri, 16 Apr 2021 04:06:54 GMT, Jaikiran Pai wrote:
>> Can I please get a review for this proposed fix for
>> https://bugs.openjdk.java.net/browse/JDK-8262108?
>>
>> As noted in a comment in that issue, the bug relates to the return value of
>
and is probably what hid this
> issue in the first place? To fix this, I have added an additional commit
> which updates this test case to properly test the `AM_PM` field values.
Jaikiran Pai has updated the pull request incrementally with one additional
commit since the last revision:
On Fri, 16 Apr 2021 03:51:22 GMT, Naoto Sato wrote:
>> Hello Naoto,
>>
>> As far as I can see, the testMap cannot be used to test the day period
>> strings. More specifically, consider this change (git diff) that I did as
>> you suggested (unless I misunderstood what you meant):
>>
>>
>> +
Hello Raffaello,
I have added this comment from you, to that JDK-8259896 issue.
-Jaikiran
On 02/02/21 12:43 am, Raffaello Giulietti wrote:
Hi,
in my opinion, the reporter of [1] is right in requiring that
extraneous characters be discarded, even inside the padding.
Indeed, the first full
On Fri, 12 Feb 2021 23:40:51 GMT, Brian Burkhalter wrote:
>> Can I please get a review for this change which proposes to fix the issue
>> reported in https://bugs.openjdk.java.net/browse/JDK-8260401?
>>
>> As noted in that issue, when the constructor of
>> `java.util.prefs.WindowsPreferences`
On Sat, 30 Jan 2021 14:35:50 GMT, Jaikiran Pai wrote:
> Can I please get a review for this change which proposes to fix the issue
> reported in https://bugs.openjdk.java.net/browse/JDK-8260401?
>
> As noted in that issue, when the constructor of
> `java.util.prefs.WindowsPr
On Fri, 12 Feb 2021 03:21:04 GMT, Brian Burkhalter wrote:
> Did you run this through the usual CI tests in all tiers?
Hello Brian,
Do you mean other than the ones that have been automatically run and passed in
the GitHub actions against this PR? I don't have a Windows box, but if there's
On Tue, 2 Feb 2021 02:41:10 GMT, Brian Burkhalter wrote:
>>> > The code change looks all right.
>>>
>>> Should I go ahead and integrate this?
>>
>> Actually, I didn't notice that this PR wasn't marked as reviewed. I'll wait
>> for the review(s) then.
>
> I'd let it sit for a bit in case
On Fri, 20 Aug 2021 22:44:34 GMT, Weijun Wang wrote:
> This change modifies the default value of the `java.security.manager` system
> property from "allow" to "disallow". This means unless it's explicitly set to
> "allow", any call to `System.setSecurityManager()` would throw an UOE.
>
> The
On Fri, 20 Aug 2021 22:44:34 GMT, Weijun Wang wrote:
> This change modifies the default value of the `java.security.manager` system
> property from "allow" to "disallow". This means unless it's explicitly set to
> "allow", any call to `System.setSecurityManager()` would throw an UOE.
>
> The
On Mon, 23 Aug 2021 12:09:42 GMT, Weijun Wang wrote:
> > Would this then allow the security manager to be used? In other words, can
> > the value of `java.security.manager` be changed dynamically at runtime or
> > is it restricted to be set only at launch time (via command line arugment
> >
The java.util.Properties class allows the properties to be written out
to a stream or through a writer. In its current form, the specification
of these APIs state that a comment comprising of the current date is
always written out. The spec doesn't make any guarantees about the order
of the
Hello Daniel,
On 27/08/21 8:05 pm, Daniel Fuchs wrote:
Hi Jaikiran,
What about writing the keys in natural ordering?
Has that been abandoned, or will the implementation silently do it,
or will it require a new API?
In the discussion so far, there has been no opposition to changing the
On 27/08/21 8:12 pm, Jaikiran Pai wrote:
Hello Daniel,
On 27/08/21 8:05 pm, Daniel Fuchs wrote:
Hi Jaikiran,
What about writing the keys in natural ordering?
Has that been abandoned, or will the implementation silently do it,
or will it require a new API?
In the discussion so far
On 26/08/21 5:06 pm, Alan Bateman wrote:
On 25/08/2021 15:57, Jaikiran Pai wrote:
:
Introducing an overloaded "store" which takes the timestamp or
implicitly using the SOURCE_DATE_EPOCH environment variable would
mean that the Properties.store(...) APIs will continue to always
Hello Magnus,
On 30/08/21 5:29 pm, Magnus Ihse Bursie wrote:
On 2021-08-28 17:16, Alan Bateman wrote:
On 28/08/2021 05:45, Jaikiran Pai wrote:
I hadn't considered the system property approach to switch to old
behaviour in my proposals, so this is a very good input and I
personally think
Hello Roger,
On 24/08/21 8:14 pm, Roger Riggs wrote:
Hi Jaikiran,
Thanks for taking this on and getting it started.
One use case of canonical storage is repeatable builds.
It would be useful to identify the uses in the JDK that would need to
be changed to use the new function.
On 25/08/21 5:33 pm, Magnus Ihse Bursie wrote:
...
The problem is with the time stamp, which the spec states should be
present. I understand why changing this might need a new method. But I
think we should try to steer users to this new method. Otherwise it is
likely not to be used by
101 - 200 of 584 matches
Mail list logo
