Variables created from properties should not be final

[Jacques Le Roux]

Hi,

We have roughly 3514 variables created from properties, either from properties files or from DB values.

Among them 53 are declared final, this does not make sense to me.

Because a variable which depends on a properties is cached and can be dynamically changed.

You simply change the value in the properties file and clear the cache in webtools (either all caches or only the properties cache).

So it's not a constant. We also  use EntityUtilProperties, but same can happen with DB values, just change it and clear cache.

Because of that, IMO those variables should never be final, it's contradictory.

What do you think?

Jacques

[taher]

-1

This is a perfect example of why mass-updates following a certain pattern
are a bad idea.

The properties files in the start component define critical startup
parameters that cannot be changed without critically corrupting or even
crashing the system.

Therefore, I believe you should study each variable separately before
deciding if you are going to change it.

On Jan 5, 2018 10:31 AM, "Jacques Le Roux" <[hidden email]>
wrote:

Hi,

We have roughly 3514 variables created from properties, either from
properties files or from DB values.

Among them 53 are declared final, this does not make sense to me.

Because a variable which depends on a properties is cached and can be
dynamically changed.

You simply change the value in the properties file and clear the cache in
webtools (either all caches or only the properties cache).

So it's not a constant. We also  use EntityUtilProperties, but same can
happen with DB values, just change it and clear cache.

Because of that, IMO those variables should never be final, it's
contradictory.

What do you think?

Jacques

[Michael Brohl-3]

Hi Jacques,

inline..

Am 05.01.18 um 08:31 schrieb Jacques Le Roux:
> Hi,
>
> We have roughly 3514 variables created from properties, either from
> properties files or from DB values.
>
> Among them 53 are declared final, this does not make sense to me.
It might make sense depending on the business logic...
>
> Because a variable which depends on a properties is cached and can be
> dynamically changed.
>
> You simply change the value in the properties file and clear the cache
> in webtools (either all caches or only the properties cache).
>
> So it's not a constant. We also  use EntityUtilProperties, but same
> can happen with DB values, just change it and clear cache.

 From the class view, this is wrong. If you declare a constant as a
class variable from property files (e.g. as a final class attribute) the
property is only read once and assigned to the final variable. You can
change the variable in the properties or on the db and clear the cache,
it will have no impact for the instantiated class.

If you want to freshly read the property value every time you need it
and you want the possibility to change it dynamically at runtime, you'll
have to read it in the respective code and cannot declare it once as a
class attribute.
>
> Because of that, IMO those variables should never be final, it's
> contradictory.
>
> What do you think?

I think that you cannot apply this as a general rule because it depends
on how you want to use the property/variable. Taher has given a good
example with the start component and there will be others.

So,

-1 for applying this as a general rule,
+1 for a thorough review of the 53 cases and changes where they make sense.

Thanks,
Michael

>
> Jacques
>

[Jacopo Cappellato-5]

On Fri, Jan 5, 2018 at 9:26 AM, Michael Brohl <[hidden email]>
wrote:

> [...]

So,
>
> -1 for applying this as a general rule,
> +1 for a thorough review of the 53 cases and changes where they make sense.
>

I agree with the reasoning and conclusions above; to them I would add my:
+1 for a thorough review of the 3461 other cases to see if among them there
are variables that should be declared final

Jacopo

[Jacques Le Roux]

Le 05/01/2018 à 08:45, Taher Alkhateeb a écrit :
> -1
>
> This is a perfect example of why mass-updates following a certain pattern
> are a bad idea.
I did not say that all should be done. Of course every case should be checked.

> The properties files in the start component define critical startup
> parameters that cannot be changed without critically corrupting or even
> crashing the system.
That's a good example where it should not be done

> Therefore, I believe you should study each variable separately before
> deciding if you are going to change it.
That was exactly my thoughts, I should have said it therefore. I have already quickly reviewed and in most cases they should be changed

Jacques

>
> On Jan 5, 2018 10:31 AM, "Jacques Le Roux" <[hidden email]>
> wrote:
>
> Hi,
>
> We have roughly 3514 variables created from properties, either from
> properties files or from DB values.
>
> Among them 53 are declared final, this does not make sense to me.
>
> Because a variable which depends on a properties is cached and can be
> dynamically changed.
>
> You simply change the value in the properties file and clear the cache in
> webtools (either all caches or only the properties cache).
>
> So it's not a constant. We also  use EntityUtilProperties, but same can
> happen with DB values, just change it and clear cache.
>
> Because of that, IMO those variables should never be final, it's
> contradictory.
>
> What do you think?
>
> Jacques
>

[Jacques Le Roux]

Le 05/01/2018 à 09:26, Michael Brohl a écrit :

> Hi Jacques,
>
> inline..
>
> Am 05.01.18 um 08:31 schrieb Jacques Le Roux:
>> Hi,
>>
>> We have roughly 3514 variables created from properties, either from properties files or from DB values.
>>
>> Among them 53 are declared final, this does not make sense to me.
> It might make sense depending on the business logic...

Agreed, see my answer to Taher

>>
>> Because a variable which depends on a properties is cached and can be dynamically changed.
>>
>> You simply change the value in the properties file and clear the cache in webtools (either all caches or only the properties cache).
>>
>> So it's not a constant. We also  use EntityUtilProperties, but same can happen with DB values, just change it and clear cache.
>
> From the class view, this is wrong. If you declare a constant as a class variable from property files (e.g. as a final class attribute) the property
> is only read once and assigned to the final variable. You can change the variable in the properties or on the db and clear the cache, it will have
> no impact for the instantiated class.
>
> If you want to freshly read the property value every time you need it and you want the possibility to change it dynamically at runtime, you'll have
> to read it in the respective code and cannot declare it once as a class attribute.
>>
>> Because of that, IMO those variables should never be final, it's contradictory.
>>
>> What do you think?
>
> I think that you cannot apply this as a general rule because it depends on how you want to use the property/variable. Taher has given a good example
> with the start component and there will be others.

Yes sure

> So,
>
> -1 for applying this as a general rule,
> +1 for a thorough review of the 53 cases and changes where they make sense.
Exactly what I intended to do. Jacopo suggests to review all case but then it's really a large task!

Jacques
>
> Thanks,
> Michael
>
>>
>> Jacques
>>
>
>

[Jacques Le Roux]

Le 05/01/2018 à 10:03, Jacopo Cappellato a écrit :

> On Fri, Jan 5, 2018 at 9:26 AM, Michael Brohl <[hidden email]>
> wrote:
>
>> [...]
> So,
>> -1 for applying this as a general rule,
>> +1 for a thorough review of the 53 cases and changes where they make sense.
>>
> I agree with the reasoning and conclusions above; to them I would add my:
> +1 for a thorough review of the 3461 other cases to see if among them there
> are variables that should be declared final
>
> Jacopo
>

Good point Jacopo, but a large task ;)

Jacques