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