RFR: 8231640: (prop) Canonical property storage [v7]
Magnus Ihse Bursie
magnus.ihse.bursie at oracle.com
Fri Sep 10 12:25:47 UTC 2021
On 2021-09-10 03:57, Jaikiran Pai wrote:
> Would this system property have a value that represents what
> SOURCE_DATE_EPOCH environment variable would have contained? i.e. it
> is the "A UNIX timestamp, defined as the number of seconds, excluding
> leap seconds, since 01 Jan 1970 00:00:00 UTC."? So users can
> potentially do -Djava.util.Properties.storeDate=${SOURCE_DATE_EPOCH}?
>
> Or would this system property be just some kind flag, which when
> having a value of "true" would expect the java.util.Properties code to
> lookup the SOURCE_DATE_EPOCH environment variable and use that value
> from the environment variable?
>
> I'm guessing it's the former where the value is the number of epoch
> seconds, but just wanted to be sure before I do this change.
Actually, why don't we define it as a free-form string instead? That way
the onus is on the user setting the property to get it formatted the way
they want. If they want a backwards-compatibly formatted string for
SOURCE_DATE_EPOCH, they'd have to call Java with an argument something
along the lines of:
-Djava.util.Properties.storeDate="$(date --date=@${SOURCE_DATE_EPOCH}
+"%a %b %d %H:%M:%S %Z %Y")"
which is not much more terrible than
-Djava.util.Properties.storeDate=${SOURCE_DATE_EPOCH}
given that we in any case won't be reading SOURCE_DATE_EPOCH directly.
This also allows for the user to just skip the date completely:
-Djava.util.Properties.storeDate=""
By changing this property from a epoch based long to a string, all
formatting and verification gets removed from your patch, and it is
greatly simplified.
/Magnus
More information about the core-libs-dev
mailing list