groovy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thibault Kruse <>
Subject Re: About the enhanced version of `Properties`, i.e. `GProperties`
Date Sat, 03 Nov 2018 14:30:24 GMT
Hi all,

thanks Daniel for making the suggestion and PR.

BTW there already  is an extension in
including a syntax to include other properties files, to be considered
(though that one allows duplicate keys, apparently), also it uses the
${} syntax to load environment variables, also considered a useful
concept for property files by some people. See

I am also sceptical about adding this to groovy core to handle properties files.

First let's document the specification of the idea: What you suggest
is a solution that loads a property file using the JVM Properties
class, and then on lookup of keys, loads the value as usual, but then
applies some interpolations of marked substrings.

I feel as a specification this is not precise enough, and I am not
sure which behaviors of the PR are intended and which ones are
accidental (see my review comments below).

For usability my concern is that when wrapping value lookup by
GProperties, a human reader cannot see that in the properties file,
and so users are left confused as to what happens to any given
properties file. A program could use Properties for one
file, GProperties for file, and users of an application
or library can only find out by trial and error which one is used for
If any application or library replaced Properties with GProperties, I
believe the results may be disastrous, because upgrading users would
face any number of runtime exceptions due to new semantics of their
values. It seems there is no backwards compatible upgrade path that
guarantees to users that whatever values they have in the properties
ile, switching to GProperties will maintain those values. Just as a
brainstroming example: if only properties written such as "foo ~= {x}"
would be interpolated, that would be a safe upgrade path (but I
realize the coding would not be as simple as the current PR).

There are also several edge and error cases currently not considered
in the PR, not sure if the PR is just meant as a prototype, but let me
list what I can think of so far:
* infinite cycles in the importing of other properties
* if a properties file imports another one, should the other one be
loaded as Properties file or as GProperties file? Can the user decide?
(the other file may come from a different jar outside the control of
the user).
* infinite cycles in the interpolation of variables
* multiple interpolation when the substitution of a substring contains
a pattern to be interpolated by itself: a=1; b={a}; c=${'{b}'}
* nested interpolations "{foo${key}}"
* unbalanced parentheses '{{key}'
* if we have


Which value will get(takeOther) in produce, and which
should it produce? What if we involve more files with import
relationships? Suddenly invisible links start creeping up between all

Some of the problems with the PR may be solvable (such as by using a
single Regex instead of three consecutive ones), but a lot more
test-cases are required, and the semantics of the import statement
remain quite complicated to maintain, and for users to debug. Before
including, I feel much more edge and error case testing should be done
and a more precise specification should be written first.

I don't want to generally discourage the idea, I hope my comments can
help others come up with more concerns, ideas or alternatives.

View raw message