nternationalization 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 th
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 th
nternationalization 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 th
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
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 fo
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 revision:
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:
==
T
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
>> `Cal
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 revision:
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 suggest
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 be
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):
>>
>>
>> +
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
>> `Cal
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 `-o
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 BUILD_JVMTI_TOOL
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 ultim
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 this
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 al
s better to just use 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 @
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 review fo
s better to just use 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
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 s
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 revision
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 us
package-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
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
package-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
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 a &q
package-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 af
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 World
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 befor
s better to just use 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
s better to just use 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:
propag
s better to just use 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:
- re
s better to just use 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:
m
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
s better to just use 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:
reorga
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
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 to
On Wed, 21 Jul 2021 04:09:23 GMT, Jaikiran Pai wrote:
> > > For some context - the new `FileRolloverOutputStream` extends
> > > `ByteArrayOutputStream` and hence cannot have a `throws IOException` in
> > > its overridden `write` methods.
> >
> >
> &g
Hello Bernd,
On 22/07/21 8:54 pm, Bernd Eckenfels wrote:
Hello,
So although you can transfer the contents to the file without requiring the
access
to the byte array, you end up creating a new copy of that array (through the use
of `baos.toByteArray()`)
You can avoid the copy and the addition
s better to just use 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:
- remo
Can I please get a review for this change which fixes the typo noted in
https://bugs.openjdk.java.net/browse/JDK-8271147? `make docs-image` worked fine
and the generated javadoc looks fine.
-
Commit messages:
- 8271147: java/nio/file/Path.java javadoc typo
Changes: https://git.ope
On Fri, 23 Jul 2021 03:37:44 GMT, Jaikiran Pai wrote:
> Can I please get a review for this change which fixes the typo noted in
> https://bugs.openjdk.java.net/browse/JDK-8271147? `make docs-image` worked
> fine and the generated javadoc looks fine.
This pull request has now been i
On Fri, 23 Jul 2021 03:37:44 GMT, Jaikiran Pai wrote:
> Can I please get a review for this change which fixes the typo noted in
> https://bugs.openjdk.java.net/browse/JDK-8271147? `make docs-image` worked
> fine and the generated javadoc looks fine.
Thank you for the rev
On Fri, 2 Jul 2021 11:06:40 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 a &q
On Fri, 2 Jul 2021 11:06:40 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 a &q
On Sun, 27 Jun 2021 13:13:42 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 a "./" en
s better to just use 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:
On Fri, 23 Jul 2021 10:28:02 GMT, Alan Bateman wrote:
> So I think the approach looks good but I think the synchronization needs to
> be re-checked it is not obvious that is correct or needed. Are there any
> cases where FileRolloverOutputStream is returned to user code? I don't think
> so, in
On Fri, 23 Jul 2021 10:36:51 GMT, Alan Bateman wrote:
> I wasn't suggesting there is a patch attached to that issue. Rather I was
> just pointing out that JDK-8251329 was being worked on already before this PR
> was created.
Ok, that makes sense. Thank you for the details.
-
PR:
s better to just use 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 with a new target base due to a merge
or a rebase. The incremental webrev
On Fri, 23 Jul 2021 14:58:01 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 befor
On Sun, 25 Jul 2021 21:56:10 GMT, Lance Andersen wrote:
> Hi,
>
> As discussed in the
> https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-July/079621.html
> thread, this is the revised patch to address the use of '.' and '..' within
> Zip FS
>
> Zip FS needs to use "." and ".." as l
On Fri, 23 Jul 2021 14:58:01 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 befor
On Mon, 28 Jun 2021 03:41:20 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 to create
> a `ByteAr
On Thu, 29 Jul 2021 18:21:07 GMT, Lance Andersen wrote:
>> Hi,
>>
>> As discussed in the
>> https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-July/079621.html
>> thread, this is the revised patch to address the use of '.' and '..' within
>> Zip FS
>>
>> Zip FS needs to use "." and "
Can I please get a review of this trivial fix which fixes the typo noted in
https://bugs.openjdk.java.net/browse/JDK-8271208?
Ran `make docs-image` locally and generated the new javadocs and the change
looks fine.
-
Commit messages:
- 8271208: Typo in ModuleDescriptor.read javadoc
On Thu, 5 Aug 2021 14:28:30 GMT, Jaikiran Pai wrote:
> Can I please get a review of this trivial fix which fixes the typo noted in
> https://bugs.openjdk.java.net/browse/JDK-8271208?
>
> Ran `make docs-image` locally and generated the new javadocs and the change
> looks fine.
On Thu, 5 Aug 2021 14:28:30 GMT, Jaikiran Pai wrote:
> Can I please get a review of this trivial fix which fixes the typo noted in
> https://bugs.openjdk.java.net/browse/JDK-8271208?
>
> Ran `make docs-image` locally and generated the new javadocs and the change
> looks f
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 pro
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.
Surprisingly,
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 those
On 25/08/21 6:21 pm, Alan Bateman wrote:
On 24/08/2021 15:07, Jaikiran Pai wrote:
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
Hello Magnus,
On 25/08/21 5:33 pm, Magnus Ihse Bursie wrote:
...
One thing I do remember is the JDK build (through the make files)
would have certain Java code it would call to do some build steps. Is
there a easy way to find all such build related Java files within the
JDK? I would like to
nical 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 8/24/21 10:07 AM, Jaikiran Pai wrote:
The java.util.Properties class allows the properties to be written
out to a stream or through a writer. In its cu
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
w
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
impleme
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, there
Hello Roger,
On 28/08/21 12:16 am, Roger Riggs wrote:
Hi,
I'm finding the idea of removing the hardcoded timestamp and adding a
property to restore compatibility
strangely attractive. I don't think we've yet found a case where the
timestamp was needed (but need to keep looking).
(Adding a ti
On 28/08/21 8:46 pm, 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 the most logical proposals so far.
Roger may be right tha
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
On 29/08/21 6:41 pm, Jaikiran Pai wrote:
On 28/08/21 8:46 pm, 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 the most lo
On Sat, 4 Sep 2021 15:25:59 GMT, Jaikiran Pai wrote:
> The commit in this PR implements the proposal for enhancement that was
> discussed in the core-libs-dev mailing list recently[1], for
> https://bugs.openjdk.java.net/browse/JDK-8231640
>
> At a high level - the `s
The commit in this PR implements the proposal for enhancement that was
discussed in the core-libs-dev mailing list recently[1], for
https://bugs.openjdk.java.net/browse/JDK-8231640
At a high level - the `store()` APIs in `Properties` have been modified to now
look for the `SOURCE_DATE_EPOCH` en
Hello Alan,
On 05/09/21 1:46 pm, Alan Bateman wrote:
On 04/09/2021 16:50, Jaikiran Pai wrote:
The commit in this PR implements the proposal for enhancement that
was discussed in the core-libs-dev mailing list recently[1], for
https://bugs.openjdk.java.net/browse/JDK-8231640
At a high level
Hello Andrey,
On 05/09/21 12:02 am, Andrey Turbanov wrote:
src/java.base/share/classes/java/util/Properties.java line 924:
922: writeDateComment(bw);
923: synchronized (this) {
924: for (Map.Entry e : new
TreeMap<>(map).entrySet()) {
Is this sorting intentionally
On Sat, 4 Sep 2021 15:25:59 GMT, Jaikiran Pai wrote:
> The commit in this PR implements the proposal for enhancement that was
> discussed in the core-libs-dev mailing list recently[1], for
> https://bugs.openjdk.java.net/browse/JDK-8231640
>
> At a high level - the `s
On Sun, 5 Sep 2021 12:56:46 GMT, Jaikiran Pai wrote:
> The failure is consistently in a single test InfoOptsTest and it fails with
> the following error when running the testUniqueInfoOpts test case. Looks like
> a recent issue in some commit. I'll sort that out separately.
On 05/09/21 6:01 pm, Jaikiran Pai wrote:
Hello Alan,
On 05/09/21 1:46 pm, Alan Bateman wrote:
On 04/09/2021 16:50, Jaikiran Pai wrote:
The commit in this PR implements the proposal for enhancement that
was discussed in the core-libs-dev mailing list recently[1], for
https
where the caller is granted
> the requisite permission and in other case not granted that permission.
>
> These new tests and existing tests under `test/jdk/java/util/Properties/`
> pass with these changes.
>
> [1]
> https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-Au
On 07/09/21 8:35 pm, Roger Riggs wrote:
Hi,
The value of SOURCE_DATE_EPOCH is not so sensitive that it needs the
protections you are applying.
The doPriv only exposes the value of that specific environment
variable and in the usual case, it is undefined.
The complexity in the specification
Hello Robert,
On 07/09/21 11:24 pm, Robert Scholte wrote:
On Sat, 4 Sep 2021 18:30:06 GMT, Andrey Turbanov
wrote:
Jaikiran Pai has updated the pull request incrementally with one additional
commit since the last revision:
use @implNote to explain the use of the environment variable
Hello Stuart,
On 08/09/21 6:49 am, Stuart Marks wrote:
On 9/7/21 8:27 AM, Jaikiran Pai wrote:
On 07/09/21 8:35 pm, Roger Riggs wrote:
Though java.util.Date is used in the current implementation, its use
is discouraged in new code
in favor of java.time.ZonedDateTime.
Consider if
where the caller is granted
> the requisite permission and in other case not granted that permission.
>
> These new tests and existing tests under `test/jdk/java/util/Properties/`
> pass with these changes.
>
> [1]
> https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-Au
On 07/09/21 9:02 pm, Alan Bateman wrote:
On 07/09/2021 16:05, Roger Riggs wrote:
Hi,
The value of SOURCE_DATE_EPOCH is not so sensitive that it needs the
protections you are applying.
The doPriv only exposes the value of that specific environment
variable and in the usual case, it is undefi
On Wed, 8 Sep 2021 09:26:33 GMT, Jaikiran Pai wrote:
>> The commit in this PR implements the proposal for enhancement that was
>> discussed in the core-libs-dev mailing list recently[1], for
>> https://bugs.openjdk.java.net/browse/JDK-8231640
>>
>> At a high
Hello Andrey,
On 07/09/21 7:50 pm, Andrey Turbanov wrote:
On Sun, 5 Sep 2021 12:38:20 GMT, Jaikiran Pai wrote:
Do you mean that converting the keySet() of an
existing Map into an array and then sorting that array and then using
that sorted array to iterate and using these keys to do an
where the caller is granted
> the requisite permission and in other case not granted that permission.
>
> These new tests and existing tests under `test/jdk/java/util/Properties/`
> pass with these changes.
>
> [1]
> https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-A
where the caller is granted
> the requisite permission and in other case not granted that permission.
>
> These new tests and existing tests under `test/jdk/java/util/Properties/`
> pass with these changes.
>
> [1]
> https://mail.openjdk.java.net/pipermail/core-libs-dev/2
where the caller is granted
> the requisite permission and in other case not granted that permission.
>
> These new tests and existing tests under `test/jdk/java/util/Properties/`
> pass with these changes.
>
> [1]
> https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-Augu
Hello Stuart,
On 09/09/21 12:35 am, Stuart Marks wrote:
Unless there's an overriding reason, it might be nice to have the
output format match the format used in the Debian patch that adds
SOURCE_DATE_EPOCH:
https://salsa.debian.org/openjdk-team/openjdk/-/blob/master/debian/patches/reproduc
101 - 200 of 584 matches
Mail list logo
