There's another reason why using public constants is problematic: The Java compiler inlines constants into the class that uses them. So, if we change a constant and only recompile that class and not the referencing class, we can get inconsistent constant values.
This means that changes to public constants will create a new jar that is **not binary compatible**. I was caught by this feature in JMeter, which originally used public constants for version details. JMeter consists of multiple separately compiled plugin jars, and I could not work out why updated version info was not propagating. (The solution was to use a getter for the constant) Best to only expose constants that truly are constant, and also only to expose constants that need to be exposed. Sebb See for example: https://forums.oracle.com/ords/apexds/post/final-variable-inlining-why-2465 On Sun, 22 Oct 2023 at 07:12, sebb <seb...@gmail.com> wrote: > > A recent change to JexlFeatures made some flag combinations public. > Seems to me that this unnecessarily exposes the internal > representation, which makes it much harder to change it later. > > Making constants public can constrain future changes, whereas > providing access via methods is easier to maintain, so ideally don't > expose constants unnecessarily. > > Sebb --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
