Hi Jaikiran,
I agree with separating out the discussion of a new store method and
(mostly) with the list of objectives below.
And I'd propose doing it in a separate RFE[1] and PR.
As to support for comments, I think we can omit them entirely from the
new method.
Since the caller has access to
On 2021-09-09 12:04, Magnus Ihse Bursie wrote:
Let me be more concrete: I suggest adding a new overloaded method,
publicvoidstore(Writerout, Stringcomments, boolean includeTimestamp)
And somehow my email program managed to mess up the code formatting. :-(
The signature I meant was of course:
On 2021-09-09 10:27, Jaikiran Pai wrote:
On 31/08/21 7:09 pm, Jaikiran Pai wrote:
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 ol
On 31/08/21 7:09 pm, Jaikiran Pai wrote:
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
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 logical propos
--
http://bernd.eckenfels.net
Von: core-libs-dev im Auftrag von Roger Riggs
Gesendet: Monday, August 30, 2021 5:00:14 PM
An: Jaikiran Pai ; core-libs-dev@openjdk.java.net
Betreff: Re: Proposal: JDK-8231640 - (prop) Canonical property storage
Hi Jaikiran,
System p
im Auftrag von Roger
Riggs
Gesendet: Monday, August 30, 2021 5:00:14 PM
An: Jaikiran Pai ; core-libs-dev@openjdk.java.net
Betreff: Re: Proposal: JDK-8231640 - (prop) Canonical property storage
Hi Jaikiran,
System properties, especially new ones, should be only settable on the
command line and
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 the
Hi Jaikiran,
System properties, especially new ones, should be only settable on the
command line and read once.
It makes them visible to developers and avoids state-full dependencies
and concurrency issues.
Retiring system properties is quite difficult because there's no way to
know if they
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 the most logical proposals so far.
Roger may be right that few
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 that few w
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 that few would care but it would be changing behavior
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
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 timestamp to the comment by the caller of store() is alrea
I've dropped this topic on the Maven Dev mailinglist as well[1].
The responses are mixed, so I'd prefer to refer to the mailinglist
instead of summarizing the responses here.
This will prevent that those opinions are considered my opinions.
Thanks,
Robert
[1]
https://lists.apache.org/thread.h
Hi,
It would seem useful in the long term to move the inclusion of the date
to be part of the comment
and it would be up to the caller of store() to include a date (as a
string) where ever appropriate.
And drop the writing hardcoded date; but its not clear how to get there
given compatibility
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 has
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
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?
AFAIU there are two problems that are hostile to reproducible builds:
- date comments differ from store to store
- property ordering
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
write out a
Hello Roger,
Sorry, I just read the top part of your reply the last time and didn't
realize there were inline comments. I just noticed them. Replying inline.
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 stor
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
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 write out
a Date representation into the outputstream. T
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 i
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
Hi,
Not all properties file might benefit from being sorted in key ordering.
Think for instance about the logging.properties file - where you would
certainly want to keep the original ordering.
That said - we rarely store() a logging properties file, and if
we stored it, key might appear in ran
Hi,
For the occasional human reader of a property file, a deterministic
order would make them
easier to use as well. The natural sort order of the keys as String
would be suitable.
I'd support changing the order written without changing the API. Load
and other readers
of property files have
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 is always written out. The spec doesn't make
On 2021-08-25 14:03, Magnus Ihse Bursie wrote:
Hi Jaikiran,
I'm glad to see this issue finally getting some love and attention! :)
I don't fully support those "inclinations" that say that the old API
should not change. I think keeping the old random order of store()
would mean a missed cha
Hi Jaikiran,
I'm glad to see this issue finally getting some love and attention! :)
I don't fully support those "inclinations" that say that the old API
should not change. I think keeping the old random order of store() would
mean a missed chance to do good, otherwise a lot of Java programs wi
On 25/08/2021 11:51, Jaikiran Pai wrote:
:
1. jdk.internal.vm.VMSupport#serializePropertiesToByteArray - Looking
at the implementation in this method and as the name suggests, the
Properties is being written out a byte array. This method gets called
from native code, from what I can see. I
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,
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 8/24/21 10:07 AM, Jaikiran Pai wrote:
The java.util.Properties cl
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
34 matches
Mail list logo
