There's one important to keep in mind: escaping.
To ensure we're reading the properties correctly, we want to write them
using Properties.
Although the /META-INF/maven/<groupId>/<artifactId>/pom.properties is
very predictable, others are not.
For example the maven-shade-plugin can rewrite properties files for
class relocation.
(off-topic: this could use a per-line reader, so comments are preserved)
These are just examples I know of, there are much more out there other
more complex usage of properties.
The Maven Project has several places where Properties is extended for
reproducibility, whereas this ticket is about making it part of the API
itself, so not everybody needs to write their own extended class for the
same purpose.
thanks,
Robert
------ Origineel bericht ------
Van: "Bernd Eckenfels" <e...@zusammenkunft.net>
Aan: "core-libs-dev@openjdk.java.net" <core-libs-dev@openjdk.java.net>
Verzonden: 31-8-2021 16:02:50
Onderwerp: Re: Proposal: JDK-8231640 - (prop) Canonical property storage
BTW it is probably not a good idea to overwrite Properties (for example to get
a defined store order). Especially since changes in the past already broke
this. However the attached discussion shows that people do need insert-order
and/or alphabetical ordered properties — maybe a more general solution would
help (and also make sure that existing implementations which subtype Properties
and overwrite entrySet() would continue to work? After all properties is/was
not final.
https://stackoverflow.com/questions/17011108/how-can-i-write-java-properties-in-a-defined-order
On a somewhat related note, I think if the Properties class is not
deterministic, preserves order and comments, it’s maybe not a good
file,creation APi for Maven anyway. What Plug-ins are affected for which
operation?
Gruss
Bernd
--
http://bernd.eckenfels.net
________________________________
Von: core-libs-dev <core-libs-dev-r...@openjdk.java.net> im Auftrag von Roger Riggs
<roger.ri...@oracle.com>
Gesendet: Monday, August 30, 2021 5:00:14 PM
An: Jaikiran Pai <jai.forums2...@gmail.com>; core-libs-dev@openjdk.java.net
<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 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 are still being
used or by whom. The technique using system properties to revert to
previous behavior has
been used when API changes are unavoidable and the impact on existing
applications is not known.
It isn't a good solution but does provide a workaround when an issue is
discovered.
Better to not introduce them in the first place.
The use of SOURCE_DATE_EPOCH as proposed seems better than most, as its
definition
has a wider scope and longer expected life than most properties.
Since SOURCE_DATE_EPOCH is an environment variable, not a system
property, it will be
less visible to developers, but is already read-once at first use of any
environment variable
as per System.getenv().
$.02, Roger
On 8/28/21 12:45 AM, Jaikiran Pai wrote:
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 timestamp to the comment by the caller of store() is
already possible)
It will reveal where the timestamp is needed (via some kind of
failure, though perhaps not a timely one)
and includes a fallback mechanism when needed.
It will generally cleanup up the behavior of an old API.
The other approaches make new work for developers based on unclear
requirements.
So this is essentially the proposal 1d that I listed in one of my
mails, with the added advantage of allowing users to switch back to
the old behaviour with a system property setting. 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. One question that however remains is,
how long (how many releases) do we support this new system property?
The --illegal-access option (although not a system property) seems to
be one such example where after a few releases, that option will no
longer be supported and won't play any role. Perhaps this system
property too will follow a similar lifetime?
One other thing - I believe this new system property must be "set once
at launch time" kind of property, whose value can be set at launch
time and cannot be changed dynamically in the runtime. That would
provide consistency in how the Properties class behaves globally
within that runtime, instead of potentially behaving differently in
different parts of the code, depending on how the callers set/reset
the system property value before calling the "store(...)" APIs.
-Jaikiran
