Re: Variables created from properties should not be final

2018-01-05 Thread Jacques Le Roux

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

On Fri, Jan 5, 2018 at 9:26 AM, Michael Brohl 
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



Re: Variables created from properties should not be final

2018-01-05 Thread 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








Re: Variables created from properties should not be final

2018-01-05 Thread 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" 
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





Re: Variables created from properties should not be final

2018-01-05 Thread Jacopo Cappellato
On Fri, Jan 5, 2018 at 9:26 AM, Michael Brohl 
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


Re: Variables created from properties should not be final

2018-01-05 Thread Michael Brohl

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






smime.p7s
Description: S/MIME Cryptographic Signature


Re: Variables created from properties should not be final

2018-01-04 Thread Taher Alkhateeb
-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" 
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