You are viewing a plain text version of this content. The canonical link for it is here.

Posted to dev@commons.apache.org by Oliver Heger <ol...@oliver-heger.de> on 2014/10/24 21:23:11 UTC

Re: svn commit: r1632171 [1/20] - in /commons/proper/beanutils/trunk/src: main/java/org/apache/commons/beanutils/ main/java/org/apache/commons/beanutils/converters/ main/java/org/apache/commons/beanutils/expression/ main/java/org/apache/commons/beanutils/l...


Am 23.10.2014 um 22:58 schrieb Gary Gregory:
> Patches go stale no matter what...

Right, this can happen during normal development, but not necessarily
because of a big bang change for which there is no technical reason, but
which is just a matter of personal taste.

Oliver

> 
> Gary
> 
> <div>-------- Original message --------</div><div>From: Oliver Heger <ol...@oliver-heger.de> </div><div>Date:10/23/2014  15:34  (GMT-05:00) </div><div>To: dev@commons.apache.org </div><div>Subject: Re: svn commit: r1632171 [1/20] - in /commons/proper/beanutils/trunk/src:
>   main/java/org/apache/commons/beanutils/ main/java/org/apache/commons/beanutils/converters/
>   main/java/org/apache/commons/beanutils/expression/ main/java/org/apache/commons/beanutils/l... </div><div>
> </div>There was no reaction on my comment so far.
> 
> I am tempted to -1 this commit. There is already a report about a patch
> which cannot be applied (comment to [1]).
> 
> Oliver
> 
> [1] https://issues.apache.org/jira/browse/BEANUTILS-417
> 
> Am 16.10.2014 um 21:22 schrieb Oliver Heger:
>> To be honest, I really don't like this commit. My personal sense for
>> aesthetics put aside, you modified almost the whole code base. Patches
>> assigned to Jira tickets will probably no longer apply cleanly.
>>
>> Oliver
>>
>> Am 15.10.2014 um 22:15 schrieb ggregory@apache.org:
>>> Author: ggregory
>>> Date: Wed Oct 15 20:15:17 2014
>>> New Revision: 1632171
>>>
>>> URL: http://svn.apache.org/r1632171
>>> Log:
>>> Add final modifier to method parameters.
>>> Add final modifier to local variables.
>>>
>>> Modified:
>>>     commons/proper/beanutils/trunk/src/main/java/org/apache/commons/beanutils/BaseDynaBeanMapDecorator.java
>>>     commons/proper/beanutils/trunk/src/main/java/org/apache/commons/beanutils/BasicDynaBean.java
>>>     commons/proper/beanutils/trunk/src/main/java/org/apache/commons/beanutils/BasicDynaClass.java
>>>     commons/proper/beanutils/trunk/src/main/java/org/apache/commons/beanutils/BeanAccessLanguageException.java
>>>     commons/proper/beanutils/trunk/src/main/java/org/apache/commons/beanutils/BeanComparator.java
>>>     commons/proper/beanutils/trunk/src/main/java/org/apache/commons/beanutils/BeanIntrospectionData.java
>>>     commons/proper/beanutils/trunk/src/main/java/org/apache/commons/beanutils/BeanMap.java
>>>     commons/proper/beanutils/trunk/src/main/java/org/apache/commons/beanutils/BeanPredicate.java
>>>     commons/proper/beanutils/trunk/src/main/java/org/apache/commons/beanutils/BeanPropertyValueChangeClosure.java
>>>     commons/proper/beanutils/trunk/src/main/java/org/apache/commons/beanutils/BeanPropertyValueEqualsPredicate.java
>>>     commons/proper/beanutils/trunk/src/main/java/org/apache/commons/beanutils/BeanToPropertyValueTransformer.java
>>>     commons/proper/beanutils/trunk/src/main/java/org/apache/commons/beanutils/BeanUtils.java
>>>     commons/proper/beanutils/trunk/src/main/java/org/apache/commons/beanutils/BeanUtilsBean.java
>>>     commons/proper/beanutils/trunk/src/main/java/org/apache/commons/beanutils/BeanUtilsBean2.java
>>>     commons/proper/beanutils/trunk/src/main/java/org/apache/commons/beanutils/ConstructorUtils.java
>>>     commons/proper/beanutils/trunk/src/main/java/org/apache/commons/beanutils/ContextClassLoaderLocal.java
>>>     commons/proper/beanutils/trunk/src/main/java/org/apache/commons/beanutils/ConversionException.java
>>>     commons/proper/beanutils/trunk/src/main/java/org/apache/commons/beanutils/ConvertUtils.java
>>>     commons/proper/beanutils/trunk/src/main/java/org/apache/commons/beanutils/ConvertUtilsBean.java
>>>     commons/proper/beanutils/trunk/src/main/java/org/apache/commons/beanutils/ConvertUtilsBean2.java
>>>     commons/proper/beanutils/trunk/src/main/java/org/apache/commons/beanutils/ConvertingWrapDynaBean.java
>>>     commons/proper/beanutils/trunk/src/main/java/org/apache/commons/beanutils/DefaultBeanIntrospector.java
>>>     commons/proper/beanutils/trunk/src/main/java/org/apache/commons/beanutils/DefaultIntrospectionContext.java
>>>     commons/proper/beanutils/trunk/src/main/java/org/apache/commons/beanutils/DynaBeanMapDecorator.java
>>>     commons/proper/beanutils/trunk/src/main/java/org/apache/commons/beanutils/DynaBeanPropertyMapDecorator.java
>>>     commons/proper/beanutils/trunk/src/main/java/org/apache/commons/beanutils/DynaProperty.java
>>>     commons/proper/beanutils/trunk/src/main/java/org/apache/commons/beanutils/FluentPropertyBeanIntrospector.java
>>>     commons/proper/beanutils/trunk/src/main/java/org/apache/commons/beanutils/JDBCDynaClass.java
>>>     commons/proper/beanutils/trunk/src/main/java/org/apache/commons/beanutils/LazyDynaBean.java
>>>     commons/proper/beanutils/trunk/src/main/java/org/apache/commons/beanutils/LazyDynaClass.java
>>>     commons/proper/beanutils/trunk/src/main/java/org/apache/commons/beanutils/LazyDynaList.java
>>>     commons/proper/beanutils/trunk/src/main/java/org/apache/commons/beanutils/LazyDynaMap.java
>>>     commons/proper/beanutils/trunk/src/main/java/org/apache/commons/beanutils/MappedPropertyDescriptor.java
>>>     commons/proper/beanutils/trunk/src/main/java/org/apache/commons/beanutils/MethodUtils.java
>>>     commons/proper/beanutils/trunk/src/main/java/org/apache/commons/beanutils/NestedNullException.java
>>>     commons/proper/beanutils/trunk/src/main/java/org/apache/commons/beanutils/PropertyUtils.java
>>>     commons/proper/beanutils/trunk/src/main/java/org/apache/commons/beanutils/PropertyUtilsBean.java
>>>     commons/proper/beanutils/trunk/src/main/java/org/apache/commons/beanutils/ResultSetDynaClass.java
>>>     commons/proper/beanutils/trunk/src/main/java/org/apache/commons/beanutils/ResultSetIterator.java
>>>     commons/proper/beanutils/trunk/src/main/java/org/apache/commons/beanutils/RowSetDynaClass.java
>>>     commons/proper/beanutils/trunk/src/main/java/org/apache/commons/beanutils/SuppressPropertiesBeanIntrospector.java
>>>     commons/proper/beanutils/trunk/src/main/java/org/apache/commons/beanutils/WeakFastHashMap.java
>>>     commons/proper/beanutils/trunk/src/main/java/org/apache/commons/beanutils/WrapDynaBean.java
>>>     commons/proper/beanutils/trunk/src/main/java/org/apache/commons/beanutils/WrapDynaClass.java
>>>     commons/proper/beanutils/trunk/src/main/java/org/apache/commons/beanutils/converters/AbstractArrayConverter.java
>>>     commons/proper/beanutils/trunk/src/main/java/org/apache/commons/beanutils/converters/AbstractConverter.java
>>>     commons/proper/beanutils/trunk/src/main/java/org/apache/commons/beanutils/converters/ArrayConverter.java
>>>     commons/proper/beanutils/trunk/src/main/java/org/apache/commons/beanutils/converters/BigDecimalConverter.java
>>>     commons/proper/beanutils/trunk/src/main/java/org/apache/commons/beanutils/converters/BigIntegerConverter.java
>>>     commons/proper/beanutils/trunk/src/main/java/org/apache/commons/beanutils/converters/BooleanArrayConverter.java
>>>     commons/proper/beanutils/trunk/src/main/java/org/apache/commons/beanutils/converters/BooleanConverter.java
>>>     commons/proper/beanutils/trunk/src/main/java/org/apache/commons/beanutils/converters/ByteArrayConverter.java
>>>     commons/proper/beanutils/trunk/src/main/java/org/apache/commons/beanutils/converters/ByteConverter.java
>>>     commons/proper/beanutils/trunk/src/main/java/org/apache/commons/beanutils/converters/CalendarConverter.java
>>>     commons/proper/beanutils/trunk/src/main/java/org/apache/commons/beanutils/converters/CharacterArrayConverter.java
>>>     commons/proper/beanutils/trunk/src/main/java/org/apache/commons/beanutils/converters/CharacterConverter.java
>>>     commons/proper/beanutils/trunk/src/main/java/org/apache/commons/beanutils/converters/ClassConverter.java
>>>     commons/proper/beanutils/trunk/src/main/java/org/apache/commons/beanutils/converters/ConverterFacade.java
>>>     commons/proper/beanutils/trunk/src/main/java/org/apache/commons/beanutils/converters/DateConverter.java
>>>     commons/proper/beanutils/trunk/src/main/java/org/apache/commons/beanutils/converters/DateTimeConverter.java
>>>     commons/proper/beanutils/trunk/src/main/java/org/apache/commons/beanutils/converters/DoubleArrayConverter.java
>>>     commons/proper/beanutils/trunk/src/main/java/org/apache/commons/beanutils/converters/DoubleConverter.java
>>>     commons/proper/beanutils/trunk/src/main/java/org/apache/commons/beanutils/converters/FileConverter.java
>>>     commons/proper/beanutils/trunk/src/main/java/org/apache/commons/beanutils/converters/FloatArrayConverter.java
>>>     commons/proper/beanutils/trunk/src/main/java/org/apache/commons/beanutils/converters/FloatConverter.java
>>>     commons/proper/beanutils/trunk/src/main/java/org/apache/commons/beanutils/converters/IntegerArrayConverter.java
>>>     commons/proper/beanutils/trunk/src/main/java/org/apache/commons/beanutils/converters/IntegerConverter.java
>>>     commons/proper/beanutils/trunk/src/main/java/org/apache/commons/beanutils/converters/LongArrayConverter.java
>>>     commons/proper/beanutils/trunk/src/main/java/org/apache/commons/beanutils/converters/LongConverter.java
>>>     commons/proper/beanutils/trunk/src/main/java/org/apache/commons/beanutils/converters/NumberConverter.java
>>>     commons/proper/beanutils/trunk/src/main/java/org/apache/commons/beanutils/converters/ShortArrayConverter.java
>>>     commons/proper/beanutils/trunk/src/main/java/org/apache/commons/beanutils/converters/ShortConverter.java
>>>     commons/proper/beanutils/trunk/src/main/java/org/apache/commons/beanutils/converters/SqlDateConverter.java
>>>     commons/proper/beanutils/trunk/src/main/java/org/apache/commons/beanutils/converters/SqlTimeConverter.java
>>>     commons/proper/beanutils/trunk/src/main/java/org/apache/commons/beanutils/converters/SqlTimestampConverter.java
>>>     commons/proper/beanutils/trunk/src/main/java/org/apache/commons/beanutils/converters/StringArrayConverter.java
>>>     commons/proper/beanutils/trunk/src/main/java/org/apache/commons/beanutils/converters/StringConverter.java
>>>     commons/proper/beanutils/trunk/src/main/java/org/apache/commons/beanutils/converters/URLConverter.java
>>>     commons/proper/beanutils/trunk/src/main/java/org/apache/commons/beanutils/expression/DefaultResolver.java
>>>     commons/proper/beanutils/trunk/src/main/java/org/apache/commons/beanutils/locale/BaseLocaleConverter.java
>>>     commons/proper/beanutils/trunk/src/main/java/org/apache/commons/beanutils/locale/LocaleBeanUtils.java
>>>     commons/proper/beanutils/trunk/src/main/java/org/apache/commons/beanutils/locale/LocaleBeanUtilsBean.java
>>>     commons/proper/beanutils/trunk/src/main/java/org/apache/commons/beanutils/locale/LocaleConvertUtils.java
>>>     commons/proper/beanutils/trunk/src/main/java/org/apache/commons/beanutils/locale/LocaleConvertUtilsBean.java
>>>     commons/proper/beanutils/trunk/src/main/java/org/apache/commons/beanutils/locale/converters/BigDecimalLocaleConverter.java
>>>     commons/proper/beanutils/trunk/src/main/java/org/apache/commons/beanutils/locale/converters/BigIntegerLocaleConverter.java
>>>     commons/proper/beanutils/trunk/src/main/java/org/apache/commons/beanutils/locale/converters/ByteLocaleConverter.java
>>>     commons/proper/beanutils/trunk/src/main/java/org/apache/commons/beanutils/locale/converters/DateLocaleConverter.java
>>>     commons/proper/beanutils/trunk/src/main/java/org/apache/commons/beanutils/locale/converters/DecimalLocaleConverter.java
>>>     commons/proper/beanutils/trunk/src/main/java/org/apache/commons/beanutils/locale/converters/DoubleLocaleConverter.java
>>>     commons/proper/beanutils/trunk/src/main/java/org/apache/commons/beanutils/locale/converters/FloatLocaleConverter.java
>>>     commons/proper/beanutils/trunk/src/main/java/org/apache/commons/beanutils/locale/converters/IntegerLocaleConverter.java
>>>     commons/proper/beanutils/trunk/src/main/java/org/apache/commons/beanutils/locale/converters/LongLocaleConverter.java
>>>     commons/proper/beanutils/trunk/src/main/java/org/apache/commons/beanutils/locale/converters/ShortLocaleConverter.java
>>>     commons/proper/beanutils/trunk/src/main/java/org/apache/commons/beanutils/locale/converters/SqlDateLocaleConverter.java
>>>     commons/proper/beanutils/trunk/src/main/java/org/apache/commons/beanutils/locale/converters/SqlTimeLocaleConverter.java
>>>     commons/proper/beanutils/trunk/src/main/java/org/apache/commons/beanutils/locale/converters/SqlTimestampLocaleConverter.java
>>>     commons/proper/beanutils/trunk/src/main/java/org/apache/commons/beanutils/locale/converters/StringLocaleConverter.java
>>>     commons/proper/beanutils/trunk/src/test/java/org/apache/commons/beanutils/A.java
>>>     commons/proper/beanutils/trunk/src/test/java/org/apache/commons/beanutils/AbstractChild.java
>>>     commons/proper/beanutils/trunk/src/test/java/org/apache/commons/beanutils/AbstractParent.java
>>>     commons/proper/beanutils/trunk/src/test/java/org/apache/commons/beanutils/AlphaBean.java
>>>     commons/proper/beanutils/trunk/src/test/java/org/apache/commons/beanutils/BasicDynaBeanTestCase.java
>>>     commons/proper/beanutils/trunk/src/test/java/org/apache/commons/beanutils/BeanComparatorTestCase.java
>>>     commons/proper/beanutils/trunk/src/test/java/org/apache/commons/beanutils/BeanIntrospectionDataTestCase.java
>>>     commons/proper/beanutils/trunk/src/test/java/org/apache/commons/beanutils/BeanMapTestCase.java
>>>     commons/proper/beanutils/trunk/src/test/java/org/apache/commons/beanutils/BeanPredicateTestCase.java
>>>     commons/proper/beanutils/trunk/src/test/java/org/apache/commons/beanutils/BeanPropertyValueChangeClosureTestCase.java
>>>     commons/proper/beanutils/trunk/src/test/java/org/apache/commons/beanutils/BeanPropertyValueEqualsPredicateTestCase.java
>>>     commons/proper/beanutils/trunk/src/test/java/org/apache/commons/beanutils/BeanToPropertyValueTransformerTestCase.java
>>>     commons/proper/beanutils/trunk/src/test/java/org/apache/commons/beanutils/BeanUtils2TestCase.java
>>>     commons/proper/beanutils/trunk/src/test/java/org/apache/commons/beanutils/BeanUtilsBenchCase.java
>>>     commons/proper/beanutils/trunk/src/test/java/org/apache/commons/beanutils/BeanUtilsTestCase.java
>>>     commons/proper/beanutils/trunk/src/test/java/org/apache/commons/beanutils/BeanWithInnerBean.java
>>>     commons/proper/beanutils/trunk/src/test/java/org/apache/commons/beanutils/BeanificationTestCase.java
>>>     commons/proper/beanutils/trunk/src/test/java/org/apache/commons/beanutils/BenchBean.java
>>>     commons/proper/beanutils/trunk/src/test/java/org/apache/commons/beanutils/BetaBean.java
>>>     commons/proper/beanutils/trunk/src/test/java/org/apache/commons/beanutils/ConstructorUtilsTestCase.java
>>>     commons/proper/beanutils/trunk/src/test/java/org/apache/commons/beanutils/ConvertUtilsTestCase.java
>>>     commons/proper/beanutils/trunk/src/test/java/org/apache/commons/beanutils/DefaultIntrospectionContextTestCase.java
>>>     commons/proper/beanutils/trunk/src/test/java/org/apache/commons/beanutils/DynaBeanMapDecoratorTestCase.java
>>>     commons/proper/beanutils/trunk/src/test/java/org/apache/commons/beanutils/DynaBeanUtilsTestCase.java
>>>     commons/proper/beanutils/trunk/src/test/java/org/apache/commons/beanutils/DynaPropertyTestCase.java
>>>     commons/proper/beanutils/trunk/src/test/java/org/apache/commons/beanutils/DynaPropertyUtilsTestCase.java
>>>     commons/proper/beanutils/trunk/src/test/java/org/apache/commons/beanutils/DynaResultSetTestCase.java
>>>     commons/proper/beanutils/trunk/src/test/java/org/apache/commons/beanutils/DynaRowSetTestCase.java
>>>     commons/proper/beanutils/trunk/src/test/java/org/apache/commons/beanutils/ExtendMapBean.java
>>>     commons/proper/beanutils/trunk/src/test/java/org/apache/commons/beanutils/FluentIntrospectionTestBean.java
>>>     commons/proper/beanutils/trunk/src/test/java/org/apache/commons/beanutils/FluentPropertyBeanIntrospectorTestCase.java
>>>     commons/proper/beanutils/trunk/src/test/java/org/apache/commons/beanutils/IndexedPropertyTestCase.java
>>>     commons/proper/beanutils/trunk/src/test/java/org/apache/commons/beanutils/IndexedTestBean.java
>>>     commons/proper/beanutils/trunk/src/test/java/org/apache/commons/beanutils/LazyDynaBeanTestCase.java
>>>     commons/proper/beanutils/trunk/src/test/java/org/apache/commons/beanutils/LazyDynaClassTestCase.java
>>>     commons/proper/beanutils/trunk/src/test/java/org/apache/commons/beanutils/LazyDynaListTestCase.java
>>>     commons/proper/beanutils/trunk/src/test/java/org/apache/commons/beanutils/LazyDynaMapTestCase.java
>>>     commons/proper/beanutils/trunk/src/test/java/org/apache/commons/beanutils/MappedPropertyTestBean.java
>>>     commons/proper/beanutils/trunk/src/test/java/org/apache/commons/beanutils/MappedPropertyTestCase.java
>>>     commons/proper/beanutils/trunk/src/test/java/org/apache/commons/beanutils/MethodUtilsTestCase.java
>>>     commons/proper/beanutils/trunk/src/test/java/org/apache/commons/beanutils/NestedTestBean.java
>>>     commons/proper/beanutils/trunk/src/test/java/org/apache/commons/beanutils/PrimitiveBean.java
>>>     commons/proper/beanutils/trunk/src/test/java/org/apache/commons/beanutils/PropertyUtilsBenchCase.java
>>>     commons/proper/beanutils/trunk/src/test/java/org/apache/commons/beanutils/PropertyUtilsTestCase.java
>>>     commons/proper/beanutils/trunk/src/test/java/org/apache/commons/beanutils/PropsFirstPropertyUtilsBean.java
>>>     commons/proper/beanutils/trunk/src/test/java/org/apache/commons/beanutils/SonOfAlphaBean.java
>>>     commons/proper/beanutils/trunk/src/test/java/org/apache/commons/beanutils/SuppressPropertiesBeanIntrospectorTestCase.java
>>>     commons/proper/beanutils/trunk/src/test/java/org/apache/commons/beanutils/TestBean.java
>>>     commons/proper/beanutils/trunk/src/test/java/org/apache/commons/beanutils/TestResultSet.java
>>>     commons/proper/beanutils/trunk/src/test/java/org/apache/commons/beanutils/TestResultSetMetaData.java
>>>     commons/proper/beanutils/trunk/src/test/java/org/apache/commons/beanutils/ThrowExceptionConverter.java
>>>     commons/proper/beanutils/trunk/src/test/java/org/apache/commons/beanutils/WrapDynaBeanTestCase.java
>>>     commons/proper/beanutils/trunk/src/test/java/org/apache/commons/beanutils/bugs/Jira157TestCase.java
>>>     commons/proper/beanutils/trunk/src/test/java/org/apache/commons/beanutils/bugs/Jira18TestCase.java
>>>     commons/proper/beanutils/trunk/src/test/java/org/apache/commons/beanutils/bugs/Jira273TestCase.java
>>>     commons/proper/beanutils/trunk/src/test/java/org/apache/commons/beanutils/bugs/Jira298TestCase.java
>>>     commons/proper/beanutils/trunk/src/test/java/org/apache/commons/beanutils/bugs/Jira339TestCase.java
>>>     commons/proper/beanutils/trunk/src/test/java/org/apache/commons/beanutils/bugs/Jira345TestCase.java
>>>     commons/proper/beanutils/trunk/src/test/java/org/apache/commons/beanutils/bugs/Jira347TestCase.java
>>>     commons/proper/beanutils/trunk/src/test/java/org/apache/commons/beanutils/bugs/Jira349TestCase.java
>>>     commons/proper/beanutils/trunk/src/test/java/org/apache/commons/beanutils/bugs/Jira357TestCase.java
>>>     commons/proper/beanutils/trunk/src/test/java/org/apache/commons/beanutils/bugs/Jira358TestCase.java
>>>     commons/proper/beanutils/trunk/src/test/java/org/apache/commons/beanutils/bugs/Jira359TestCase.java
>>>     commons/proper/beanutils/trunk/src/test/java/org/apache/commons/beanutils/bugs/Jira368TestCase.java
>>>     commons/proper/beanutils/trunk/src/test/java/org/apache/commons/beanutils/bugs/Jira369TestCase.java
>>>     commons/proper/beanutils/trunk/src/test/java/org/apache/commons/beanutils/bugs/Jira381TestCase.java
>>>     commons/proper/beanutils/trunk/src/test/java/org/apache/commons/beanutils/bugs/Jira411TestCase.java
>>>     commons/proper/beanutils/trunk/src/test/java/org/apache/commons/beanutils/bugs/Jira422TestCase.java
>>>     commons/proper/beanutils/trunk/src/test/java/org/apache/commons/beanutils/bugs/Jira454TestCase.java
>>>     commons/proper/beanutils/trunk/src/test/java/org/apache/commons/beanutils/bugs/Jira456TestCase.java
>>>     commons/proper/beanutils/trunk/src/test/java/org/apache/commons/beanutils/bugs/Jira458TestCase.java
>>>     commons/proper/beanutils/trunk/src/test/java/org/apache/commons/beanutils/bugs/Jira463TestCase.java
>>>     commons/proper/beanutils/trunk/src/test/java/org/apache/commons/beanutils/bugs/Jira465TestCase.java
>>>     commons/proper/beanutils/trunk/src/test/java/org/apache/commons/beanutils/bugs/Jira61TestCase.java
>>>     commons/proper/beanutils/trunk/src/test/java/org/apache/commons/beanutils/bugs/Jira87TestCase.java
>>>     commons/proper/beanutils/trunk/src/test/java/org/apache/commons/beanutils/bugs/Jira92TestCase.java
>>>     commons/proper/beanutils/trunk/src/test/java/org/apache/commons/beanutils/bugs/other/Jira18BeanFactory.java
>>>     commons/proper/beanutils/trunk/src/test/java/org/apache/commons/beanutils/bugs/other/Jira298BeanFactory.java
>>>     commons/proper/beanutils/trunk/src/test/java/org/apache/commons/beanutils/bugs/other/Jira61BeanFactory.java
>>>     commons/proper/beanutils/trunk/src/test/java/org/apache/commons/beanutils/bugs/other/Jira87BeanFactory.java
>>>     commons/proper/beanutils/trunk/src/test/java/org/apache/commons/beanutils/converters/ArrayConverterTestCase.java
>>>     commons/proper/beanutils/trunk/src/test/java/org/apache/commons/beanutils/converters/BigDecimalConverterTestCase.java
>>>     commons/proper/beanutils/trunk/src/test/java/org/apache/commons/beanutils/converters/BigIntegerConverterTestCase.java
>>>     commons/proper/beanutils/trunk/src/test/java/org/apache/commons/beanutils/converters/BooleanArrayConverterTestCase.java
>>>     commons/proper/beanutils/trunk/src/test/java/org/apache/commons/beanutils/converters/BooleanConverterTestCase.java
>>>     commons/proper/beanutils/trunk/src/test/java/org/apache/commons/beanutils/converters/ByteConverterTestCase.java
>>>     commons/proper/beanutils/trunk/src/test/java/org/apache/commons/beanutils/converters/CalendarConverterTestCase.java
>>>     commons/proper/beanutils/trunk/src/test/java/org/apache/commons/beanutils/converters/CharacterConverterTestCase.java
>>>     commons/proper/beanutils/trunk/src/test/java/org/apache/commons/beanutils/converters/ClassConverterTestCase.java
>>>     commons/proper/beanutils/trunk/src/test/java/org/apache/commons/beanutils/converters/ClassReloader.java
>>>     commons/proper/beanutils/trunk/src/test/java/org/apache/commons/beanutils/converters/ClassReloaderTestCase.java
>>>     commons/proper/beanutils/trunk/src/test/java/org/apache/commons/beanutils/converters/ConverterTestSuite.java
>>>     commons/proper/beanutils/trunk/src/test/java/org/apache/commons/beanutils/converters/DateConverterTestBase.java
>>>     commons/proper/beanutils/trunk/src/test/java/org/apache/commons/beanutils/converters/DateConverterTestCase.java
>>>     commons/proper/beanutils/trunk/src/test/java/org/apache/commons/beanutils/converters/DoubleConverterTestCase.java
>>>     commons/proper/beanutils/trunk/src/test/java/org/apache/commons/beanutils/converters/FileConverterTestCase.java
>>>     commons/proper/beanutils/trunk/src/test/java/org/apache/commons/beanutils/converters/FloatConverterTestCase.java
>>>     commons/proper/beanutils/trunk/src/test/java/org/apache/commons/beanutils/converters/IntegerConverterTestCase.java
>>>     commons/proper/beanutils/trunk/src/test/java/org/apache/commons/beanutils/converters/LongConverterTestCase.java
>>>     commons/proper/beanutils/trunk/src/test/java/org/apache/commons/beanutils/converters/MemoryTestCase.java
>>>     commons/proper/beanutils/trunk/src/test/java/org/apache/commons/beanutils/converters/NumberConverterTestBase.java
>>>     commons/proper/beanutils/trunk/src/test/java/org/apache/commons/beanutils/converters/ShortConverterTestCase.java
>>>     commons/proper/beanutils/trunk/src/test/java/org/apache/commons/beanutils/converters/SqlDateConverterTestCase.java
>>>     commons/proper/beanutils/trunk/src/test/java/org/apache/commons/beanutils/converters/SqlTimeConverterTestCase.java
>>>     commons/proper/beanutils/trunk/src/test/java/org/apache/commons/beanutils/converters/SqlTimestampConverterTestCase.java
>>>     commons/proper/beanutils/trunk/src/test/java/org/apache/commons/beanutils/converters/StringArrayConverterTestCase.java
>>>     commons/proper/beanutils/trunk/src/test/java/org/apache/commons/beanutils/converters/StringConverterTestCase.java
>>>     commons/proper/beanutils/trunk/src/test/java/org/apache/commons/beanutils/converters/URLConverterTestCase.java
>>>     commons/proper/beanutils/trunk/src/test/java/org/apache/commons/beanutils/expression/DefaultResolverTestCase.java
>>>     commons/proper/beanutils/trunk/src/test/java/org/apache/commons/beanutils/locale/LocaleBeanUtilsTestCase.java
>>>     commons/proper/beanutils/trunk/src/test/java/org/apache/commons/beanutils/locale/LocaleBeanificationTestCase.java
>>>     commons/proper/beanutils/trunk/src/test/java/org/apache/commons/beanutils/locale/LocaleConvertTestSuite.java
>>>     commons/proper/beanutils/trunk/src/test/java/org/apache/commons/beanutils/locale/LocaleConvertUtilsTestCase.java
>>>     commons/proper/beanutils/trunk/src/test/java/org/apache/commons/beanutils/locale/converters/BaseLocaleConverterTestCase.java
>>>     commons/proper/beanutils/trunk/src/test/java/org/apache/commons/beanutils/locale/converters/BigDecimalLocaleConverterTestCase.java
>>>     commons/proper/beanutils/trunk/src/test/java/org/apache/commons/beanutils/locale/converters/BigIntegerLocaleConverterTestCase.java
>>>     commons/proper/beanutils/trunk/src/test/java/org/apache/commons/beanutils/locale/converters/ByteLocaleConverterTestCase.java
>>>     commons/proper/beanutils/trunk/src/test/java/org/apache/commons/beanutils/locale/converters/DateLocaleConverterTestCase.java
>>>     commons/proper/beanutils/trunk/src/test/java/org/apache/commons/beanutils/locale/converters/DoubleLocaleConverterTestCase.java
>>>     commons/proper/beanutils/trunk/src/test/java/org/apache/commons/beanutils/locale/converters/FloatLocaleConverterTestCase.java
>>>     commons/proper/beanutils/trunk/src/test/java/org/apache/commons/beanutils/locale/converters/IntegerLocaleConverterTestCase.java
>>>     commons/proper/beanutils/trunk/src/test/java/org/apache/commons/beanutils/locale/converters/LongLocaleConverterTestCase.java
>>>     commons/proper/beanutils/trunk/src/test/java/org/apache/commons/beanutils/locale/converters/ShortLocaleConverterTestCase.java
>>>     commons/proper/beanutils/trunk/src/test/java/org/apache/commons/beanutils/memoryleaktests/MemoryLeakTestCase.java
>>>     commons/proper/beanutils/trunk/src/test/java/org/apache/commons/beanutils/memoryleaktests/pojotests/CustomInteger.java
>>>     commons/proper/beanutils/trunk/src/test/java/org/apache/commons/beanutils/memoryleaktests/pojotests/SomeMappedPojo.java
>>>     commons/proper/beanutils/trunk/src/test/java/org/apache/commons/beanutils/memoryleaktests/pojotests/SomePojo.java
>>>     commons/proper/beanutils/trunk/src/test/java/org/apache/commons/beanutils/priv/PackageBean.java
>>>     commons/proper/beanutils/trunk/src/test/java/org/apache/commons/beanutils/priv/PrivateBean.java
>>>     commons/proper/beanutils/trunk/src/test/java/org/apache/commons/beanutils/priv/PublicSubBean.java
>>
>> <snip/>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org

Re: Use of final modifiers - WAS svn commit: r1632171 [1/20] - in /commons/proper/beanutils/trunk/src: main/java/org/apache/commons/beanutils/ main/java/org/apache/commons/beanutils/converters/ main/java/org/apache/commons/beanutils/expression/ main/java/org/apache/commons/beanutils/l...

Posted by Phil Steitz <ph...@gmail.com>.

On 10/28/14 8:46 AM, Benedikt Ritter wrote:
> 2014-10-28 13:18 GMT+01:00 Gary Gregory <ga...@gmail.com>:
>
>> On Tue, Oct 28, 2014 at 5:52 AM, Torsten Curdt <tc...@vafer.org> wrote:
>>
>>>> You know that Java has no out variables (as it is call by value) and
>> the
>>>> final identifier does not make an object read only. So in fact having
>>> final
>>>> modifiers would misslead you even more.
>>>>
>>> The last sentence is a bit of theory. I don't see that to be true for me
>> at
>>> least.
>>>
>>> Following some of the arguments in this thread declarations like "const"
>> or
>>> "let" are just noise. I could say the same thing about the stupid
>>> "override" annotation everyone keeps using. Taking that a step (or
>> rather a
>>> few steps) further it makes you wonder why some people here prefer a
>>> statically typed language like java over dynamic ones.
>>>
>>> Anyway - I do think "final" has value. Not sure I would want to have it
>>> everywhere though.
>>> But the point is: everyone has a different opinion on this.
>>>
>>> I have a hard time seeing value in this thread

Hi Torsten!  (there is the value in this thread ;)

>>>  unless there is a more
>>> concrete objective or question to answer.
>>> These could be...
>>>
>>> "Are stylistic commits acceptable?"
>>> "Do we want to enforce a common code style?"
>>>
>> Some components already do explicitly define a style through Checkstyle and
>> PMD or implicitly with the general guideline of "follow the style of the
>> file you are in" I've seen listed on a guideline page.
>>
> If you're actively working on BeanUtils and help with applying existing
> patches, fine.
> If you're just jumping in to add final everywhere but are not working on
> the component, I'd rather revert the commit.

I disagree.  People contribute here in different ways and as long as
what they are doing is OK with the community and people are at least
+0 on the changes, we should thank them for it.  I used to think all
the final stuff was useless, but have come around to +0-ish to the
point that I don't make Gilles clean up after me so much on [math]
any more.  In any case, I don't see it damaging the code and I agree
with Mark that patch aging is a separate issue.

Phil


>
>
>> Some Apache projects (HC for example IIRC) cause the build to fail is a
>> Checkstyle rule is broken.
>>
>> Gary
>>
>>
>>> Maybe answer those first?
>>>
>>> cheers,
>>> Torsten
>>>
>>
>>
>> --
>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>> Java Persistence with Hibernate, Second Edition
>> <http://www.manning.com/bauer3/>
>> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
>> Spring Batch in Action <http://www.manning.com/templier/>
>> Blog: http://garygregory.wordpress.com
>> Home: http://garygregory.com/
>> Tweet! http://twitter.com/GaryGregory
>>
>
>



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org

Re: Use of final modifiers - WAS svn commit: r1632171 [1/20] - in /commons/proper/beanutils/trunk/src: main/java/org/apache/commons/beanutils/ main/java/org/apache/commons/beanutils/converters/ main/java/org/apache/commons/beanutils/expression/ main/java/org/apache/commons/beanutils/l...

Posted by Benedikt Ritter <br...@apache.org>.

2014-10-28 13:18 GMT+01:00 Gary Gregory <ga...@gmail.com>:

> On Tue, Oct 28, 2014 at 5:52 AM, Torsten Curdt <tc...@vafer.org> wrote:
>
> > >
> > > You know that Java has no out variables (as it is call by value) and
> the
> > > final identifier does not make an object read only. So in fact having
> > final
> > > modifiers would misslead you even more.
> > >
> >
> > The last sentence is a bit of theory. I don't see that to be true for me
> at
> > least.
> >
> > Following some of the arguments in this thread declarations like "const"
> or
> > "let" are just noise. I could say the same thing about the stupid
> > "override" annotation everyone keeps using. Taking that a step (or
> rather a
> > few steps) further it makes you wonder why some people here prefer a
> > statically typed language like java over dynamic ones.
> >
> > Anyway - I do think "final" has value. Not sure I would want to have it
> > everywhere though.
> > But the point is: everyone has a different opinion on this.
> >
> > I have a hard time seeing value in this thread unless there is a more
> > concrete objective or question to answer.
> > These could be...
> >
> > "Are stylistic commits acceptable?"
> > "Do we want to enforce a common code style?"
> >
>
> Some components already do explicitly define a style through Checkstyle and
> PMD or implicitly with the general guideline of "follow the style of the
> file you are in" I've seen listed on a guideline page.
>

If you're actively working on BeanUtils and help with applying existing
patches, fine.
If you're just jumping in to add final everywhere but are not working on
the component, I'd rather revert the commit.


>
> Some Apache projects (HC for example IIRC) cause the build to fail is a
> Checkstyle rule is broken.
>
> Gary
>
>
> >
> > Maybe answer those first?
> >
> > cheers,
> > Torsten
> >
>
>
>
> --
> E-Mail: garydgregory@gmail.com | ggregory@apache.org
> Java Persistence with Hibernate, Second Edition
> <http://www.manning.com/bauer3/>
> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
> Spring Batch in Action <http://www.manning.com/templier/>
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
>



-- 
http://people.apache.org/~britter/
http://www.systemoutprintln.de/
http://twitter.com/BenediktRitter
http://github.com/britter

Re: Use of final modifiers - WAS svn commit: r1632171 [1/20] - in /commons/proper/beanutils/trunk/src: main/java/org/apache/commons/beanutils/ main/java/org/apache/commons/beanutils/converters/ main/java/org/apache/commons/beanutils/expression/ main/java/org/apache/commons/beanutils/l...

Posted by Gary Gregory <ga...@gmail.com>.

On Tue, Oct 28, 2014 at 5:52 AM, Torsten Curdt <tc...@vafer.org> wrote:

> >
> > You know that Java has no out variables (as it is call by value) and the
> > final identifier does not make an object read only. So in fact having
> final
> > modifiers would misslead you even more.
> >
>
> The last sentence is a bit of theory. I don't see that to be true for me at
> least.
>
> Following some of the arguments in this thread declarations like "const" or
> "let" are just noise. I could say the same thing about the stupid
> "override" annotation everyone keeps using. Taking that a step (or rather a
> few steps) further it makes you wonder why some people here prefer a
> statically typed language like java over dynamic ones.
>
> Anyway - I do think "final" has value. Not sure I would want to have it
> everywhere though.
> But the point is: everyone has a different opinion on this.
>
> I have a hard time seeing value in this thread unless there is a more
> concrete objective or question to answer.
> These could be...
>
> "Are stylistic commits acceptable?"
> "Do we want to enforce a common code style?"
>

Some components already do explicitly define a style through Checkstyle and
PMD or implicitly with the general guideline of "follow the style of the
file you are in" I've seen listed on a guideline page.

Some Apache projects (HC for example IIRC) cause the build to fail is a
Checkstyle rule is broken.

Gary


>
> Maybe answer those first?
>
> cheers,
> Torsten
>



-- 
E-Mail: garydgregory@gmail.com | ggregory@apache.org
Java Persistence with Hibernate, Second Edition
<http://www.manning.com/bauer3/>
JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
Spring Batch in Action <http://www.manning.com/templier/>
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

Re: Use of final modifiers - WAS svn commit: r1632171 [1/20] - in /commons/proper/beanutils/trunk/src: main/java/org/apache/commons/beanutils/ main/java/org/apache/commons/beanutils/converters/ main/java/org/apache/commons/beanutils/expression/ main/java/org/apache/commons/beanutils/l...

Posted by Torsten Curdt <tc...@vafer.org>.

>
> You know that Java has no out variables (as it is call by value) and the
> final identifier does not make an object read only. So in fact having final
> modifiers would misslead you even more.
>

The last sentence is a bit of theory. I don't see that to be true for me at
least.

Following some of the arguments in this thread declarations like "const" or
"let" are just noise. I could say the same thing about the stupid
"override" annotation everyone keeps using. Taking that a step (or rather a
few steps) further it makes you wonder why some people here prefer a
statically typed language like java over dynamic ones.

Anyway - I do think "final" has value. Not sure I would want to have it
everywhere though.
But the point is: everyone has a different opinion on this.

I have a hard time seeing value in this thread unless there is a more
concrete objective or question to answer.
These could be...

"Are stylistic commits acceptable?"
"Do we want to enforce a common code style?"

Maybe answer those first?

cheers,
Torsten

Re: Use of final modifiers - WAS svn commit: r1632171 [1/20] - in /commons/proper/beanutils/trunk/src: main/java/org/apache/commons/beanutils/ main/java/org/apache/commons/beanutils/converters/ main/java/org/apache/commons/beanutils/expression/ main/java/org/apache/commons/beanutils/l...

Posted by James Sawle <ja...@hotmail.com>.

Whilst with primitives it is call by value with objects it is not, and whilst the final modifier does not stop a method from changing an internal value, it is acknowledgement that they won't, read writings by Joshua Bolchdku h m

Sent from my iPhone

> On 28 Oct 2014, at 08:55, Bernd <ec...@zusammenkunft.net> wrote:
> 
> Hmm,
> 
> You know that Java has no out variables (as it is call by value) and the
> final identifier does not make an object read only. So in fact having final
> modifiers would misslead you even more.
> 
> Actually I like having final fields and variables (for example it avoids
> unneeded initialisation). On the parameters I feel it makes the signatures
> unreadable long, and given that stylistic warnings about Ssigning
> parameters happen in Eclipse anyway I dont need them. (But I dont mind if
> used).
> 
> Greetings
> Bernd
> Am 28.10.2014 09:17 schrieb "James Sawle" <ja...@hotmail.com>:
> 
>> I have no view on the use of final modifiers on variables within methods;
>> however on the parameters I think it is very important so that the code
>> self documents to the caller the behaviour that they should expect.
>> Recently I was bitten by a library that I was using in a multithreaded
>> application that was modifying the values I sent it, even though from the
>> contract there seemed no reason for this. Using the final modifier will
>> give that guarantee, without having to add it to the Javadoc and definitely
>> without having to look at the source, which no one apart from a contributor
>> should ever HAVE to do!
>> 
>> Sent from my iPhone
>> 
>>> On 28 Oct 2014, at 07:21, Benedikt Ritter <br...@apache.org> wrote:
>>> 
>>> I agree with Oliver. This change is just of cosmetic value and makes it
>>> harder to apply patches (the same applies for the "sort methods in abc
>>> order" changes IMHO).
>>> If we come to the consensus that we want a final key word everywhere, we
>>> should add that to our code analysis tools configuration. For now, I
>> don't
>>> feel like we have consens about that.
>>> 
>>> Benedikt
>>> 
>>> 2014-10-28 1:24 GMT+01:00 Ralph Goers <ra...@dslextreme.com>:
>>> 
>>>> Gary does have a passion for these kinds of changes.
>>>> 
>>>> I am definitely +0 on them but Gary has taken the initiative to make the
>>>> changes to Log4j and has continually sought to keep them up to date even
>>>> though the rest of us don’t really care. We had this same discussion a
>>>> while ago on that mailing list.  The conclusion I came to is that the
>> final
>>>> keyword has value on class attributes and some value on parameter
>>>> declarations and has value only in special cases inside of methods.
>>>> 
>>>> I do know there are cases where the compiler takes advantage of the
>>>> declaration.  I also know that occasionally I have to remove the final
>>>> keyword because I want to modify the value of a local variable.  I
>> really
>>>> dislike them in unit tests.
>>>> 
>>>> Personally I think the way to go is to come to a consensus on where they
>>>> are required, where they are optional, and where they should not occur.
>>>> 
>>>> Ralph
>>>> 
>>>> 
>>>> 
>>>>>> On Oct 27, 2014, at 1:44 PM, Oliver Heger <
>> oliver.heger@oliver-heger.de>
>>>>> wrote:
>>>>> 
>>>>> 
>>>>> 
>>>>>> Am 27.10.2014 um 02:04 schrieb Gary Gregory:
>>>>>> On Sat, Oct 25, 2014 at 3:27 PM, Oliver Heger <
>>>> oliver.heger@oliver-heger.de>
>>>>>> wrote:
>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>>>> Am 24.10.2014 um 22:47 schrieb Mark Thomas:
>>>>>>>>> On 24/10/2014 21:17, Oliver Heger wrote:
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>>> Am 24.10.2014 um 22:01 schrieb Gary Gregory:
>>>>>>>>>> On Fri, Oct 24, 2014 at 3:23 PM, Oliver Heger <
>>>>>>> oliver.heger@oliver-heger.de>
>>>>>>>>>> wrote:
>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>>> Am 23.10.2014 um 22:58 schrieb Gary Gregory:
>>>>>>>>>>>> Patches go stale no matter what...
>>>>>>>>>>> 
>>>>>>>>>>> Right, this can happen during normal development, but not
>>>> necessarily
>>>>>>>>>>> because of a big bang change for which there is no technical
>>>> reason,
>>>>>>> but
>>>>>>>>>>> which is just a matter of personal taste.
>>>>>>>>>> 
>>>>>>>>>> I call it a technical reason, you call it personal taste, we are
>> not
>>>>>>> going
>>>>>>>>>> to agree.
>>>>>>>>> 
>>>>>>>>> Obviously not. So how do we proceed?
>>>>>>>> 
>>>>>>>> You work it out until a consensus is reached and then that consensus
>>>> is
>>>>>>>> implemented. The more entrenched folks are in their positions, the
>>>>>>>> longer consensus is going to take. (And no, a VOTE is not the right
>>>> way
>>>>>>>> to resolve this.)
>>>>>>>> 
>>>>>>>> My own view is that the addition of the final keywords does have
>>>>>>>> technical merit. Not enough to make me want to spend the time to fix
>>>> the
>>>>>>>> projects I work on, but I wouldn't complain if someone else wanted
>> to
>>>>>>>> make all the necessary changes. Similarly while I think it would be
>> a
>>>>>>>> shame to throw away all this good work, I could live with that
>> option
>>>> if
>>>>>>>> that was the consensus opinion.
>>>>>>>> 
>>>>>>>> The issue of out-dated patches is a red herring. That is a separate
>>>>>>>> problem. The community needs to apply / review patches faster.
>>>>>>>> 
>>>>>>>> Mark
>>>>>>> 
>>>>>>> Okay, so back to discussion.
>>>>>>> 
>>>>>>> First of all I have to state that I am irritated about the way this
>>>>>>> change was done. It is really an invasive commit without any prior
>>>>>>> announcement. For a collaborative project I do not consider this as
>>>> good
>>>>>>> style. As some replies to this thread show, there is no consensus
>> about
>>>>>>> the changes performed.
>>>>>>> 
>>>>>>> As an example on the same level,
>>>>>> 
>>>>>> 
>>>>>> This is a silly example IMO because you talk about using a Windows C
>>>>>> _naming_ convention in Java, which has zero effect on compiled code,
>>>> while
>>>>>> we are talking about using a Java language feature which does matter
>> to
>>>> the
>>>>>> compiler. Apples and Oranges.
>>>>> 
>>>>> Not in the sense that both changes aim at making code more
>>>>> understandable without having any impact on functionality.
>>>>> 
>>>>>> 
>>>>>> 
>>>>>>> I could come to the idea that I prefer
>>>>>>> variable names with special prefixes. In C programming under Windows
>>>>>>> there was a convention of adding prefixes to variable names derived
>>>> from
>>>>>>> their data type: String sName, int iCount, Double[] adNumbers, etc.
>>>> What
>>>>>>> could argue that this makes code more understandable because each
>>>>>>> variable carries meta-information with it. If I suddenly started to
>>>>>>> rework the code of multiple components based on this convention, I
>>>> would
>>>>>>> surely trigger some reactions.
>>>>>>> 
>>>>>>> IIUC, the purpose behind this change is to make the intension of the
>>>>>>> programmer explicit that a specific variable is not going to be
>>>> changed.
>>>>>> 
>>>>>> It is that, and more. Just as important and perhaps more so: When I
>> read
>>>>>> code or I am stepping in a debugger and I see a 'final' I know that a
>>>> value
>>>>>> is not going to change from under my feet. I can put that aside as a
>>>>>> variable (pun intended) in my mind and worry about other aspects of
>> the
>>>>>> code.
>>>>> 
>>>>> The vast majority of Java code I encounter does not use final modifiers
>>>>> in this way (I know, it is your mission to change this). Therefore,
>> when
>>>>> I see a final I ask myself what is the special purpose here? Is it
>>>>> referenced by an anonymous class?
>>>>> 
>>>>> The information whether a variable cannot be changed has not been that
>>>>> important for me; this can easily be spotted from the context: if there
>>>>> is an assignment, well it is changed. Otherwise, your method is
>> probably
>>>>> too complex and needs refactoring.
>>>>> 
>>>>> Oliver
>>>>> 
>>>>>> 
>>>>>> Gary
>>>>>> 
>>>>>> 
>>>>>>> I doubt that you manually inspected the whole code base. Rather, I
>>>>>>> assume you used a tool - Eclipse has a corresponding option - which
>>>>>>> analyzed all possible code paths to determine whether a variable can
>> be
>>>>>>> final. This does not tell too much about the intentions of the
>> original
>>>>>>> authors. Further, when using such a tool there is not much
>> intellectual
>>>>>>> work behind this. Please correct me if I am wrong here.
>>>>>>> 
>>>>>>> From my perspective the excessive use of final modifiers makes code
>>>>>>> harder to read because it adds so much noise. There are some places
>>>> when
>>>>>>> Java requires the use of final; but those special places which may be
>>>> of
>>>>>>> interest are now completely hidden in the overall final fog.
>>>>>>> 
>>>>>>> Oliver
>>>>>>> 
>> ---------------------------------------------------------------------
>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>> 
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>> 
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org <mailto:
>>>> dev-unsubscribe@commons.apache.org>
>>>>> For additional commands, e-mail: dev-help@commons.apache.org <mailto:
>>>> dev-help@commons.apache.org>
>>> 
>>> 
>>> 
>>> --
>>> http://people.apache.org/~britter/
>>> http://www.systemoutprintln.de/
>>> http://twitter.com/BenediktRitter
>>> http://github.com/britter
>>

Re: Use of final modifiers - WAS svn commit: r1632171 [1/20] - in /commons/proper/beanutils/trunk/src: main/java/org/apache/commons/beanutils/ main/java/org/apache/commons/beanutils/converters/ main/java/org/apache/commons/beanutils/expression/ main/java/org/apache/commons/beanutils/l...

Posted by Bernd <ec...@zusammenkunft.net>.

Hmm,

You know that Java has no out variables (as it is call by value) and the
final identifier does not make an object read only. So in fact having final
modifiers would misslead you even more.

Actually I like having final fields and variables (for example it avoids
unneeded initialisation). On the parameters I feel it makes the signatures
unreadable long, and given that stylistic warnings about Ssigning
parameters happen in Eclipse anyway I dont need them. (But I dont mind if
used).

Greetings
Bernd
Am 28.10.2014 09:17 schrieb "James Sawle" <ja...@hotmail.com>:

> I have no view on the use of final modifiers on variables within methods;
> however on the parameters I think it is very important so that the code
> self documents to the caller the behaviour that they should expect.
> Recently I was bitten by a library that I was using in a multithreaded
> application that was modifying the values I sent it, even though from the
> contract there seemed no reason for this. Using the final modifier will
> give that guarantee, without having to add it to the Javadoc and definitely
> without having to look at the source, which no one apart from a contributor
> should ever HAVE to do!
>
> Sent from my iPhone
>
> > On 28 Oct 2014, at 07:21, Benedikt Ritter <br...@apache.org> wrote:
> >
> > I agree with Oliver. This change is just of cosmetic value and makes it
> > harder to apply patches (the same applies for the "sort methods in abc
> > order" changes IMHO).
> > If we come to the consensus that we want a final key word everywhere, we
> > should add that to our code analysis tools configuration. For now, I
> don't
> > feel like we have consens about that.
> >
> > Benedikt
> >
> > 2014-10-28 1:24 GMT+01:00 Ralph Goers <ra...@dslextreme.com>:
> >
> >> Gary does have a passion for these kinds of changes.
> >>
> >> I am definitely +0 on them but Gary has taken the initiative to make the
> >> changes to Log4j and has continually sought to keep them up to date even
> >> though the rest of us don’t really care. We had this same discussion a
> >> while ago on that mailing list.  The conclusion I came to is that the
> final
> >> keyword has value on class attributes and some value on parameter
> >> declarations and has value only in special cases inside of methods.
> >>
> >> I do know there are cases where the compiler takes advantage of the
> >> declaration.  I also know that occasionally I have to remove the final
> >> keyword because I want to modify the value of a local variable.  I
> really
> >> dislike them in unit tests.
> >>
> >> Personally I think the way to go is to come to a consensus on where they
> >> are required, where they are optional, and where they should not occur.
> >>
> >> Ralph
> >>
> >>
> >>
> >>>> On Oct 27, 2014, at 1:44 PM, Oliver Heger <
> oliver.heger@oliver-heger.de>
> >>> wrote:
> >>>
> >>>
> >>>
> >>>> Am 27.10.2014 um 02:04 schrieb Gary Gregory:
> >>>> On Sat, Oct 25, 2014 at 3:27 PM, Oliver Heger <
> >> oliver.heger@oliver-heger.de>
> >>>> wrote:
> >>>>
> >>>>>
> >>>>>
> >>>>>> Am 24.10.2014 um 22:47 schrieb Mark Thomas:
> >>>>>>> On 24/10/2014 21:17, Oliver Heger wrote:
> >>>>>>>
> >>>>>>>
> >>>>>>>> Am 24.10.2014 um 22:01 schrieb Gary Gregory:
> >>>>>>>> On Fri, Oct 24, 2014 at 3:23 PM, Oliver Heger <
> >>>>> oliver.heger@oliver-heger.de>
> >>>>>>>> wrote:
> >>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>> Am 23.10.2014 um 22:58 schrieb Gary Gregory:
> >>>>>>>>>> Patches go stale no matter what...
> >>>>>>>>>
> >>>>>>>>> Right, this can happen during normal development, but not
> >> necessarily
> >>>>>>>>> because of a big bang change for which there is no technical
> >> reason,
> >>>>> but
> >>>>>>>>> which is just a matter of personal taste.
> >>>>>>>>
> >>>>>>>> I call it a technical reason, you call it personal taste, we are
> not
> >>>>> going
> >>>>>>>> to agree.
> >>>>>>>
> >>>>>>> Obviously not. So how do we proceed?
> >>>>>>
> >>>>>> You work it out until a consensus is reached and then that consensus
> >> is
> >>>>>> implemented. The more entrenched folks are in their positions, the
> >>>>>> longer consensus is going to take. (And no, a VOTE is not the right
> >> way
> >>>>>> to resolve this.)
> >>>>>>
> >>>>>> My own view is that the addition of the final keywords does have
> >>>>>> technical merit. Not enough to make me want to spend the time to fix
> >> the
> >>>>>> projects I work on, but I wouldn't complain if someone else wanted
> to
> >>>>>> make all the necessary changes. Similarly while I think it would be
> a
> >>>>>> shame to throw away all this good work, I could live with that
> option
> >> if
> >>>>>> that was the consensus opinion.
> >>>>>>
> >>>>>> The issue of out-dated patches is a red herring. That is a separate
> >>>>>> problem. The community needs to apply / review patches faster.
> >>>>>>
> >>>>>> Mark
> >>>>>
> >>>>> Okay, so back to discussion.
> >>>>>
> >>>>> First of all I have to state that I am irritated about the way this
> >>>>> change was done. It is really an invasive commit without any prior
> >>>>> announcement. For a collaborative project I do not consider this as
> >> good
> >>>>> style. As some replies to this thread show, there is no consensus
> about
> >>>>> the changes performed.
> >>>>>
> >>>>> As an example on the same level,
> >>>>
> >>>>
> >>>> This is a silly example IMO because you talk about using a Windows C
> >>>> _naming_ convention in Java, which has zero effect on compiled code,
> >> while
> >>>> we are talking about using a Java language feature which does matter
> to
> >> the
> >>>> compiler. Apples and Oranges.
> >>>
> >>> Not in the sense that both changes aim at making code more
> >>> understandable without having any impact on functionality.
> >>>
> >>>>
> >>>>
> >>>>> I could come to the idea that I prefer
> >>>>> variable names with special prefixes. In C programming under Windows
> >>>>> there was a convention of adding prefixes to variable names derived
> >> from
> >>>>> their data type: String sName, int iCount, Double[] adNumbers, etc.
> >> What
> >>>>> could argue that this makes code more understandable because each
> >>>>> variable carries meta-information with it. If I suddenly started to
> >>>>> rework the code of multiple components based on this convention, I
> >> would
> >>>>> surely trigger some reactions.
> >>>>>
> >>>>> IIUC, the purpose behind this change is to make the intension of the
> >>>>> programmer explicit that a specific variable is not going to be
> >> changed.
> >>>>
> >>>> It is that, and more. Just as important and perhaps more so: When I
> read
> >>>> code or I am stepping in a debugger and I see a 'final' I know that a
> >> value
> >>>> is not going to change from under my feet. I can put that aside as a
> >>>> variable (pun intended) in my mind and worry about other aspects of
> the
> >>>> code.
> >>>
> >>> The vast majority of Java code I encounter does not use final modifiers
> >>> in this way (I know, it is your mission to change this). Therefore,
> when
> >>> I see a final I ask myself what is the special purpose here? Is it
> >>> referenced by an anonymous class?
> >>>
> >>> The information whether a variable cannot be changed has not been that
> >>> important for me; this can easily be spotted from the context: if there
> >>> is an assignment, well it is changed. Otherwise, your method is
> probably
> >>> too complex and needs refactoring.
> >>>
> >>> Oliver
> >>>
> >>>>
> >>>> Gary
> >>>>
> >>>>
> >>>>> I doubt that you manually inspected the whole code base. Rather, I
> >>>>> assume you used a tool - Eclipse has a corresponding option - which
> >>>>> analyzed all possible code paths to determine whether a variable can
> be
> >>>>> final. This does not tell too much about the intentions of the
> original
> >>>>> authors. Further, when using such a tool there is not much
> intellectual
> >>>>> work behind this. Please correct me if I am wrong here.
> >>>>>
> >>>>> From my perspective the excessive use of final modifiers makes code
> >>>>> harder to read because it adds so much noise. There are some places
> >> when
> >>>>> Java requires the use of final; but those special places which may be
> >> of
> >>>>> interest are now completely hidden in the overall final fog.
> >>>>>
> >>>>> Oliver
> >>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> ---------------------------------------------------------------------
> >>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >>>>>> For additional commands, e-mail: dev-help@commons.apache.org
> >>>>>
> >>>>> ---------------------------------------------------------------------
> >>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >>>>> For additional commands, e-mail: dev-help@commons.apache.org
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org <mailto:
> >> dev-unsubscribe@commons.apache.org>
> >>> For additional commands, e-mail: dev-help@commons.apache.org <mailto:
> >> dev-help@commons.apache.org>
> >
> >
> >
> > --
> > http://people.apache.org/~britter/
> > http://www.systemoutprintln.de/
> > http://twitter.com/BenediktRitter
> > http://github.com/britter
>

Re: Use of final modifiers - WAS svn commit: r1632171 [1/20] - in /commons/proper/beanutils/trunk/src: main/java/org/apache/commons/beanutils/ main/java/org/apache/commons/beanutils/converters/ main/java/org/apache/commons/beanutils/expression/ main/java/org/apache/commons/beanutils/l...

Posted by James Sawle <ja...@hotmail.com>.

I have no view on the use of final modifiers on variables within methods; however on the parameters I think it is very important so that the code self documents to the caller the behaviour that they should expect. Recently I was bitten by a library that I was using in a multithreaded application that was modifying the values I sent it, even though from the contract there seemed no reason for this. Using the final modifier will give that guarantee, without having to add it to the Javadoc and definitely without having to look at the source, which no one apart from a contributor should ever HAVE to do!

Sent from my iPhone

> On 28 Oct 2014, at 07:21, Benedikt Ritter <br...@apache.org> wrote:
> 
> I agree with Oliver. This change is just of cosmetic value and makes it
> harder to apply patches (the same applies for the "sort methods in abc
> order" changes IMHO).
> If we come to the consensus that we want a final key word everywhere, we
> should add that to our code analysis tools configuration. For now, I don't
> feel like we have consens about that.
> 
> Benedikt
> 
> 2014-10-28 1:24 GMT+01:00 Ralph Goers <ra...@dslextreme.com>:
> 
>> Gary does have a passion for these kinds of changes.
>> 
>> I am definitely +0 on them but Gary has taken the initiative to make the
>> changes to Log4j and has continually sought to keep them up to date even
>> though the rest of us don’t really care. We had this same discussion a
>> while ago on that mailing list.  The conclusion I came to is that the final
>> keyword has value on class attributes and some value on parameter
>> declarations and has value only in special cases inside of methods.
>> 
>> I do know there are cases where the compiler takes advantage of the
>> declaration.  I also know that occasionally I have to remove the final
>> keyword because I want to modify the value of a local variable.  I really
>> dislike them in unit tests.
>> 
>> Personally I think the way to go is to come to a consensus on where they
>> are required, where they are optional, and where they should not occur.
>> 
>> Ralph
>> 
>> 
>> 
>>>> On Oct 27, 2014, at 1:44 PM, Oliver Heger <ol...@oliver-heger.de>
>>> wrote:
>>> 
>>> 
>>> 
>>>> Am 27.10.2014 um 02:04 schrieb Gary Gregory:
>>>> On Sat, Oct 25, 2014 at 3:27 PM, Oliver Heger <
>> oliver.heger@oliver-heger.de>
>>>> wrote:
>>>> 
>>>>> 
>>>>> 
>>>>>> Am 24.10.2014 um 22:47 schrieb Mark Thomas:
>>>>>>> On 24/10/2014 21:17, Oliver Heger wrote:
>>>>>>> 
>>>>>>> 
>>>>>>>> Am 24.10.2014 um 22:01 schrieb Gary Gregory:
>>>>>>>> On Fri, Oct 24, 2014 at 3:23 PM, Oliver Heger <
>>>>> oliver.heger@oliver-heger.de>
>>>>>>>> wrote:
>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>>> Am 23.10.2014 um 22:58 schrieb Gary Gregory:
>>>>>>>>>> Patches go stale no matter what...
>>>>>>>>> 
>>>>>>>>> Right, this can happen during normal development, but not
>> necessarily
>>>>>>>>> because of a big bang change for which there is no technical
>> reason,
>>>>> but
>>>>>>>>> which is just a matter of personal taste.
>>>>>>>> 
>>>>>>>> I call it a technical reason, you call it personal taste, we are not
>>>>> going
>>>>>>>> to agree.
>>>>>>> 
>>>>>>> Obviously not. So how do we proceed?
>>>>>> 
>>>>>> You work it out until a consensus is reached and then that consensus
>> is
>>>>>> implemented. The more entrenched folks are in their positions, the
>>>>>> longer consensus is going to take. (And no, a VOTE is not the right
>> way
>>>>>> to resolve this.)
>>>>>> 
>>>>>> My own view is that the addition of the final keywords does have
>>>>>> technical merit. Not enough to make me want to spend the time to fix
>> the
>>>>>> projects I work on, but I wouldn't complain if someone else wanted to
>>>>>> make all the necessary changes. Similarly while I think it would be a
>>>>>> shame to throw away all this good work, I could live with that option
>> if
>>>>>> that was the consensus opinion.
>>>>>> 
>>>>>> The issue of out-dated patches is a red herring. That is a separate
>>>>>> problem. The community needs to apply / review patches faster.
>>>>>> 
>>>>>> Mark
>>>>> 
>>>>> Okay, so back to discussion.
>>>>> 
>>>>> First of all I have to state that I am irritated about the way this
>>>>> change was done. It is really an invasive commit without any prior
>>>>> announcement. For a collaborative project I do not consider this as
>> good
>>>>> style. As some replies to this thread show, there is no consensus about
>>>>> the changes performed.
>>>>> 
>>>>> As an example on the same level,
>>>> 
>>>> 
>>>> This is a silly example IMO because you talk about using a Windows C
>>>> _naming_ convention in Java, which has zero effect on compiled code,
>> while
>>>> we are talking about using a Java language feature which does matter to
>> the
>>>> compiler. Apples and Oranges.
>>> 
>>> Not in the sense that both changes aim at making code more
>>> understandable without having any impact on functionality.
>>> 
>>>> 
>>>> 
>>>>> I could come to the idea that I prefer
>>>>> variable names with special prefixes. In C programming under Windows
>>>>> there was a convention of adding prefixes to variable names derived
>> from
>>>>> their data type: String sName, int iCount, Double[] adNumbers, etc.
>> What
>>>>> could argue that this makes code more understandable because each
>>>>> variable carries meta-information with it. If I suddenly started to
>>>>> rework the code of multiple components based on this convention, I
>> would
>>>>> surely trigger some reactions.
>>>>> 
>>>>> IIUC, the purpose behind this change is to make the intension of the
>>>>> programmer explicit that a specific variable is not going to be
>> changed.
>>>> 
>>>> It is that, and more. Just as important and perhaps more so: When I read
>>>> code or I am stepping in a debugger and I see a 'final' I know that a
>> value
>>>> is not going to change from under my feet. I can put that aside as a
>>>> variable (pun intended) in my mind and worry about other aspects of the
>>>> code.
>>> 
>>> The vast majority of Java code I encounter does not use final modifiers
>>> in this way (I know, it is your mission to change this). Therefore, when
>>> I see a final I ask myself what is the special purpose here? Is it
>>> referenced by an anonymous class?
>>> 
>>> The information whether a variable cannot be changed has not been that
>>> important for me; this can easily be spotted from the context: if there
>>> is an assignment, well it is changed. Otherwise, your method is probably
>>> too complex and needs refactoring.
>>> 
>>> Oliver
>>> 
>>>> 
>>>> Gary
>>>> 
>>>> 
>>>>> I doubt that you manually inspected the whole code base. Rather, I
>>>>> assume you used a tool - Eclipse has a corresponding option - which
>>>>> analyzed all possible code paths to determine whether a variable can be
>>>>> final. This does not tell too much about the intentions of the original
>>>>> authors. Further, when using such a tool there is not much intellectual
>>>>> work behind this. Please correct me if I am wrong here.
>>>>> 
>>>>> From my perspective the excessive use of final modifiers makes code
>>>>> harder to read because it adds so much noise. There are some places
>> when
>>>>> Java requires the use of final; but those special places which may be
>> of
>>>>> interest are now completely hidden in the overall final fog.
>>>>> 
>>>>> Oliver
>>>>> 
>>>>>> 
>>>>>> 
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>> 
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>> 
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org <mailto:
>> dev-unsubscribe@commons.apache.org>
>>> For additional commands, e-mail: dev-help@commons.apache.org <mailto:
>> dev-help@commons.apache.org>
> 
> 
> 
> -- 
> http://people.apache.org/~britter/
> http://www.systemoutprintln.de/
> http://twitter.com/BenediktRitter
> http://github.com/britter

Re: Use of final modifiers - WAS svn commit: r1632171 [1/20] - in /commons/proper/beanutils/trunk/src: main/java/org/apache/commons/beanutils/ main/java/org/apache/commons/beanutils/converters/ main/java/org/apache/commons/beanutils/expression/ main/java/org/apache/commons/beanutils/l...

Posted by Benedikt Ritter <br...@apache.org>.

I agree with Oliver. This change is just of cosmetic value and makes it
harder to apply patches (the same applies for the "sort methods in abc
order" changes IMHO).
If we come to the consensus that we want a final key word everywhere, we
should add that to our code analysis tools configuration. For now, I don't
feel like we have consens about that.

Benedikt

2014-10-28 1:24 GMT+01:00 Ralph Goers <ra...@dslextreme.com>:

> Gary does have a passion for these kinds of changes.
>
> I am definitely +0 on them but Gary has taken the initiative to make the
> changes to Log4j and has continually sought to keep them up to date even
> though the rest of us don’t really care. We had this same discussion a
> while ago on that mailing list.  The conclusion I came to is that the final
> keyword has value on class attributes and some value on parameter
> declarations and has value only in special cases inside of methods.
>
> I do know there are cases where the compiler takes advantage of the
> declaration.  I also know that occasionally I have to remove the final
> keyword because I want to modify the value of a local variable.  I really
> dislike them in unit tests.
>
> Personally I think the way to go is to come to a consensus on where they
> are required, where they are optional, and where they should not occur.
>
> Ralph
>
>
>
> > On Oct 27, 2014, at 1:44 PM, Oliver Heger <ol...@oliver-heger.de>
> wrote:
> >
> >
> >
> > Am 27.10.2014 um 02:04 schrieb Gary Gregory:
> >> On Sat, Oct 25, 2014 at 3:27 PM, Oliver Heger <
> oliver.heger@oliver-heger.de>
> >> wrote:
> >>
> >>>
> >>>
> >>> Am 24.10.2014 um 22:47 schrieb Mark Thomas:
> >>>> On 24/10/2014 21:17, Oliver Heger wrote:
> >>>>>
> >>>>>
> >>>>> Am 24.10.2014 um 22:01 schrieb Gary Gregory:
> >>>>>> On Fri, Oct 24, 2014 at 3:23 PM, Oliver Heger <
> >>> oliver.heger@oliver-heger.de>
> >>>>>> wrote:
> >>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> Am 23.10.2014 um 22:58 schrieb Gary Gregory:
> >>>>>>>> Patches go stale no matter what...
> >>>>>>>
> >>>>>>> Right, this can happen during normal development, but not
> necessarily
> >>>>>>> because of a big bang change for which there is no technical
> reason,
> >>> but
> >>>>>>> which is just a matter of personal taste.
> >>>>>>>
> >>>>>>
> >>>>>> I call it a technical reason, you call it personal taste, we are not
> >>> going
> >>>>>> to agree.
> >>>>>
> >>>>> Obviously not. So how do we proceed?
> >>>>
> >>>> You work it out until a consensus is reached and then that consensus
> is
> >>>> implemented. The more entrenched folks are in their positions, the
> >>>> longer consensus is going to take. (And no, a VOTE is not the right
> way
> >>>> to resolve this.)
> >>>>
> >>>> My own view is that the addition of the final keywords does have
> >>>> technical merit. Not enough to make me want to spend the time to fix
> the
> >>>> projects I work on, but I wouldn't complain if someone else wanted to
> >>>> make all the necessary changes. Similarly while I think it would be a
> >>>> shame to throw away all this good work, I could live with that option
> if
> >>>> that was the consensus opinion.
> >>>>
> >>>> The issue of out-dated patches is a red herring. That is a separate
> >>>> problem. The community needs to apply / review patches faster.
> >>>>
> >>>> Mark
> >>>
> >>> Okay, so back to discussion.
> >>>
> >>> First of all I have to state that I am irritated about the way this
> >>> change was done. It is really an invasive commit without any prior
> >>> announcement. For a collaborative project I do not consider this as
> good
> >>> style. As some replies to this thread show, there is no consensus about
> >>> the changes performed.
> >>>
> >>> As an example on the same level,
> >>
> >>
> >> This is a silly example IMO because you talk about using a Windows C
> >> _naming_ convention in Java, which has zero effect on compiled code,
> while
> >> we are talking about using a Java language feature which does matter to
> the
> >> compiler. Apples and Oranges.
> >
> > Not in the sense that both changes aim at making code more
> > understandable without having any impact on functionality.
> >
> >>
> >>
> >>> I could come to the idea that I prefer
> >>> variable names with special prefixes. In C programming under Windows
> >>> there was a convention of adding prefixes to variable names derived
> from
> >>> their data type: String sName, int iCount, Double[] adNumbers, etc.
> What
> >>> could argue that this makes code more understandable because each
> >>> variable carries meta-information with it. If I suddenly started to
> >>> rework the code of multiple components based on this convention, I
> would
> >>> surely trigger some reactions.
> >>>
> >>> IIUC, the purpose behind this change is to make the intension of the
> >>> programmer explicit that a specific variable is not going to be
> changed.
> >>>
> >>
> >> It is that, and more. Just as important and perhaps more so: When I read
> >> code or I am stepping in a debugger and I see a 'final' I know that a
> value
> >> is not going to change from under my feet. I can put that aside as a
> >> variable (pun intended) in my mind and worry about other aspects of the
> >> code.
> >
> > The vast majority of Java code I encounter does not use final modifiers
> > in this way (I know, it is your mission to change this). Therefore, when
> > I see a final I ask myself what is the special purpose here? Is it
> > referenced by an anonymous class?
> >
> > The information whether a variable cannot be changed has not been that
> > important for me; this can easily be spotted from the context: if there
> > is an assignment, well it is changed. Otherwise, your method is probably
> > too complex and needs refactoring.
> >
> > Oliver
> >
> >>
> >> Gary
> >>
> >>
> >>> I doubt that you manually inspected the whole code base. Rather, I
> >>> assume you used a tool - Eclipse has a corresponding option - which
> >>> analyzed all possible code paths to determine whether a variable can be
> >>> final. This does not tell too much about the intentions of the original
> >>> authors. Further, when using such a tool there is not much intellectual
> >>> work behind this. Please correct me if I am wrong here.
> >>>
> >>> From my perspective the excessive use of final modifiers makes code
> >>> harder to read because it adds so much noise. There are some places
> when
> >>> Java requires the use of final; but those special places which may be
> of
> >>> interest are now completely hidden in the overall final fog.
> >>>
> >>> Oliver
> >>>
> >>>>
> >>>>
> >>>> ---------------------------------------------------------------------
> >>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >>>> For additional commands, e-mail: dev-help@commons.apache.org
> >>>>
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >>> For additional commands, e-mail: dev-help@commons.apache.org
> >>>
> >>>
> >>
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org <mailto:
> dev-unsubscribe@commons.apache.org>
> > For additional commands, e-mail: dev-help@commons.apache.org <mailto:
> dev-help@commons.apache.org>
>



-- 
http://people.apache.org/~britter/
http://www.systemoutprintln.de/
http://twitter.com/BenediktRitter
http://github.com/britter

Re: Use of final modifiers - WAS svn commit: r1632171 [1/20] - in /commons/proper/beanutils/trunk/src: main/java/org/apache/commons/beanutils/ main/java/org/apache/commons/beanutils/converters/ main/java/org/apache/commons/beanutils/expression/ main/java/org/apache/commons/beanutils/l...

Posted by venkatesha murthy <ve...@gmail.com>.

Does a custom annotation at a class level say
@AccessLevel(default=PRIVATE/PROTECTED, final=true/false) that applies to
all the variables declared help reduce the clutter. With this; only few
variables may really require the non-final characteristics. May be a
@NonFinal annotation can help their to convey intention very clear and as
well clutter free.

As always; its just annotation and a one line change to make default level
to private or protected and final as true/false so changes are at one place.

of course this is already available in lombok libraries and am not sure if
we can consume that within apache or perhaps should we write one based on
standard annotation libraries.

Basically the idea is to keep the code minimal and have annotation declared
at one place do the desired intent.

Please let know opinion.

Murthy



On Tue, Oct 28, 2014 at 5:54 AM, Ralph Goers <ra...@dslextreme.com>
wrote:

> Gary does have a passion for these kinds of changes.
>
> I am definitely +0 on them but Gary has taken the initiative to make the
> changes to Log4j and has continually sought to keep them up to date even
> though the rest of us don’t really care. We had this same discussion a
> while ago on that mailing list.  The conclusion I came to is that the final
> keyword has value on class attributes and some value on parameter
> declarations and has value only in special cases inside of methods.
>
> I do know there are cases where the compiler takes advantage of the
> declaration.  I also know that occasionally I have to remove the final
> keyword because I want to modify the value of a local variable.  I really
> dislike them in unit tests.
>
> Personally I think the way to go is to come to a consensus on where they
> are required, where they are optional, and where they should not occur.
>
> Ralph
>
>
>
> > On Oct 27, 2014, at 1:44 PM, Oliver Heger <ol...@oliver-heger.de>
> wrote:
> >
> >
> >
> > Am 27.10.2014 um 02:04 schrieb Gary Gregory:
> >> On Sat, Oct 25, 2014 at 3:27 PM, Oliver Heger <
> oliver.heger@oliver-heger.de>
> >> wrote:
> >>
> >>>
> >>>
> >>> Am 24.10.2014 um 22:47 schrieb Mark Thomas:
> >>>> On 24/10/2014 21:17, Oliver Heger wrote:
> >>>>>
> >>>>>
> >>>>> Am 24.10.2014 um 22:01 schrieb Gary Gregory:
> >>>>>> On Fri, Oct 24, 2014 at 3:23 PM, Oliver Heger <
> >>> oliver.heger@oliver-heger.de>
> >>>>>> wrote:
> >>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> Am 23.10.2014 um 22:58 schrieb Gary Gregory:
> >>>>>>>> Patches go stale no matter what...
> >>>>>>>
> >>>>>>> Right, this can happen during normal development, but not
> necessarily
> >>>>>>> because of a big bang change for which there is no technical
> reason,
> >>> but
> >>>>>>> which is just a matter of personal taste.
> >>>>>>>
> >>>>>>
> >>>>>> I call it a technical reason, you call it personal taste, we are not
> >>> going
> >>>>>> to agree.
> >>>>>
> >>>>> Obviously not. So how do we proceed?
> >>>>
> >>>> You work it out until a consensus is reached and then that consensus
> is
> >>>> implemented. The more entrenched folks are in their positions, the
> >>>> longer consensus is going to take. (And no, a VOTE is not the right
> way
> >>>> to resolve this.)
> >>>>
> >>>> My own view is that the addition of the final keywords does have
> >>>> technical merit. Not enough to make me want to spend the time to fix
> the
> >>>> projects I work on, but I wouldn't complain if someone else wanted to
> >>>> make all the necessary changes. Similarly while I think it would be a
> >>>> shame to throw away all this good work, I could live with that option
> if
> >>>> that was the consensus opinion.
> >>>>
> >>>> The issue of out-dated patches is a red herring. That is a separate
> >>>> problem. The community needs to apply / review patches faster.
> >>>>
> >>>> Mark
> >>>
> >>> Okay, so back to discussion.
> >>>
> >>> First of all I have to state that I am irritated about the way this
> >>> change was done. It is really an invasive commit without any prior
> >>> announcement. For a collaborative project I do not consider this as
> good
> >>> style. As some replies to this thread show, there is no consensus about
> >>> the changes performed.
> >>>
> >>> As an example on the same level,
> >>
> >>
> >> This is a silly example IMO because you talk about using a Windows C
> >> _naming_ convention in Java, which has zero effect on compiled code,
> while
> >> we are talking about using a Java language feature which does matter to
> the
> >> compiler. Apples and Oranges.
> >
> > Not in the sense that both changes aim at making code more
> > understandable without having any impact on functionality.
> >
> >>
> >>
> >>> I could come to the idea that I prefer
> >>> variable names with special prefixes. In C programming under Windows
> >>> there was a convention of adding prefixes to variable names derived
> from
> >>> their data type: String sName, int iCount, Double[] adNumbers, etc.
> What
> >>> could argue that this makes code more understandable because each
> >>> variable carries meta-information with it. If I suddenly started to
> >>> rework the code of multiple components based on this convention, I
> would
> >>> surely trigger some reactions.
> >>>
> >>> IIUC, the purpose behind this change is to make the intension of the
> >>> programmer explicit that a specific variable is not going to be
> changed.
> >>>
> >>
> >> It is that, and more. Just as important and perhaps more so: When I read
> >> code or I am stepping in a debugger and I see a 'final' I know that a
> value
> >> is not going to change from under my feet. I can put that aside as a
> >> variable (pun intended) in my mind and worry about other aspects of the
> >> code.
> >
> > The vast majority of Java code I encounter does not use final modifiers
> > in this way (I know, it is your mission to change this). Therefore, when
> > I see a final I ask myself what is the special purpose here? Is it
> > referenced by an anonymous class?
> >
> > The information whether a variable cannot be changed has not been that
> > important for me; this can easily be spotted from the context: if there
> > is an assignment, well it is changed. Otherwise, your method is probably
> > too complex and needs refactoring.
> >
> > Oliver
> >
> >>
> >> Gary
> >>
> >>
> >>> I doubt that you manually inspected the whole code base. Rather, I
> >>> assume you used a tool - Eclipse has a corresponding option - which
> >>> analyzed all possible code paths to determine whether a variable can be
> >>> final. This does not tell too much about the intentions of the original
> >>> authors. Further, when using such a tool there is not much intellectual
> >>> work behind this. Please correct me if I am wrong here.
> >>>
> >>> From my perspective the excessive use of final modifiers makes code
> >>> harder to read because it adds so much noise. There are some places
> when
> >>> Java requires the use of final; but those special places which may be
> of
> >>> interest are now completely hidden in the overall final fog.
> >>>
> >>> Oliver
> >>>
> >>>>
> >>>>
> >>>> ---------------------------------------------------------------------
> >>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >>>> For additional commands, e-mail: dev-help@commons.apache.org
> >>>>
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >>> For additional commands, e-mail: dev-help@commons.apache.org
> >>>
> >>>
> >>
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org <mailto:
> dev-unsubscribe@commons.apache.org>
> > For additional commands, e-mail: dev-help@commons.apache.org <mailto:
> dev-help@commons.apache.org>
>

Re: Use of final modifiers - WAS svn commit: r1632171 [1/20] - in /commons/proper/beanutils/trunk/src: main/java/org/apache/commons/beanutils/ main/java/org/apache/commons/beanutils/converters/ main/java/org/apache/commons/beanutils/expression/ main/java/org/apache/commons/beanutils/l...

Posted by Ralph Goers <ra...@dslextreme.com>.

Gary does have a passion for these kinds of changes. 

I am definitely +0 on them but Gary has taken the initiative to make the changes to Log4j and has continually sought to keep them up to date even though the rest of us don’t really care. We had this same discussion a while ago on that mailing list.  The conclusion I came to is that the final keyword has value on class attributes and some value on parameter declarations and has value only in special cases inside of methods.

I do know there are cases where the compiler takes advantage of the declaration.  I also know that occasionally I have to remove the final keyword because I want to modify the value of a local variable.  I really dislike them in unit tests.

Personally I think the way to go is to come to a consensus on where they are required, where they are optional, and where they should not occur.

Ralph



> On Oct 27, 2014, at 1:44 PM, Oliver Heger <ol...@oliver-heger.de> wrote:
> 
> 
> 
> Am 27.10.2014 um 02:04 schrieb Gary Gregory:
>> On Sat, Oct 25, 2014 at 3:27 PM, Oliver Heger <ol...@oliver-heger.de>
>> wrote:
>> 
>>> 
>>> 
>>> Am 24.10.2014 um 22:47 schrieb Mark Thomas:
>>>> On 24/10/2014 21:17, Oliver Heger wrote:
>>>>> 
>>>>> 
>>>>> Am 24.10.2014 um 22:01 schrieb Gary Gregory:
>>>>>> On Fri, Oct 24, 2014 at 3:23 PM, Oliver Heger <
>>> oliver.heger@oliver-heger.de>
>>>>>> wrote:
>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> Am 23.10.2014 um 22:58 schrieb Gary Gregory:
>>>>>>>> Patches go stale no matter what...
>>>>>>> 
>>>>>>> Right, this can happen during normal development, but not necessarily
>>>>>>> because of a big bang change for which there is no technical reason,
>>> but
>>>>>>> which is just a matter of personal taste.
>>>>>>> 
>>>>>> 
>>>>>> I call it a technical reason, you call it personal taste, we are not
>>> going
>>>>>> to agree.
>>>>> 
>>>>> Obviously not. So how do we proceed?
>>>> 
>>>> You work it out until a consensus is reached and then that consensus is
>>>> implemented. The more entrenched folks are in their positions, the
>>>> longer consensus is going to take. (And no, a VOTE is not the right way
>>>> to resolve this.)
>>>> 
>>>> My own view is that the addition of the final keywords does have
>>>> technical merit. Not enough to make me want to spend the time to fix the
>>>> projects I work on, but I wouldn't complain if someone else wanted to
>>>> make all the necessary changes. Similarly while I think it would be a
>>>> shame to throw away all this good work, I could live with that option if
>>>> that was the consensus opinion.
>>>> 
>>>> The issue of out-dated patches is a red herring. That is a separate
>>>> problem. The community needs to apply / review patches faster.
>>>> 
>>>> Mark
>>> 
>>> Okay, so back to discussion.
>>> 
>>> First of all I have to state that I am irritated about the way this
>>> change was done. It is really an invasive commit without any prior
>>> announcement. For a collaborative project I do not consider this as good
>>> style. As some replies to this thread show, there is no consensus about
>>> the changes performed.
>>> 
>>> As an example on the same level,
>> 
>> 
>> This is a silly example IMO because you talk about using a Windows C
>> _naming_ convention in Java, which has zero effect on compiled code, while
>> we are talking about using a Java language feature which does matter to the
>> compiler. Apples and Oranges.
> 
> Not in the sense that both changes aim at making code more
> understandable without having any impact on functionality.
> 
>> 
>> 
>>> I could come to the idea that I prefer
>>> variable names with special prefixes. In C programming under Windows
>>> there was a convention of adding prefixes to variable names derived from
>>> their data type: String sName, int iCount, Double[] adNumbers, etc. What
>>> could argue that this makes code more understandable because each
>>> variable carries meta-information with it. If I suddenly started to
>>> rework the code of multiple components based on this convention, I would
>>> surely trigger some reactions.
>>> 
>>> IIUC, the purpose behind this change is to make the intension of the
>>> programmer explicit that a specific variable is not going to be changed.
>>> 
>> 
>> It is that, and more. Just as important and perhaps more so: When I read
>> code or I am stepping in a debugger and I see a 'final' I know that a value
>> is not going to change from under my feet. I can put that aside as a
>> variable (pun intended) in my mind and worry about other aspects of the
>> code.
> 
> The vast majority of Java code I encounter does not use final modifiers
> in this way (I know, it is your mission to change this). Therefore, when
> I see a final I ask myself what is the special purpose here? Is it
> referenced by an anonymous class?
> 
> The information whether a variable cannot be changed has not been that
> important for me; this can easily be spotted from the context: if there
> is an assignment, well it is changed. Otherwise, your method is probably
> too complex and needs refactoring.
> 
> Oliver
> 
>> 
>> Gary
>> 
>> 
>>> I doubt that you manually inspected the whole code base. Rather, I
>>> assume you used a tool - Eclipse has a corresponding option - which
>>> analyzed all possible code paths to determine whether a variable can be
>>> final. This does not tell too much about the intentions of the original
>>> authors. Further, when using such a tool there is not much intellectual
>>> work behind this. Please correct me if I am wrong here.
>>> 
>>> From my perspective the excessive use of final modifiers makes code
>>> harder to read because it adds so much noise. There are some places when
>>> Java requires the use of final; but those special places which may be of
>>> interest are now completely hidden in the overall final fog.
>>> 
>>> Oliver
>>> 
>>>> 
>>>> 
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>> 
>>> 
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>> 
>>> 
>> 
>> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org <ma...@commons.apache.org>
> For additional commands, e-mail: dev-help@commons.apache.org <ma...@commons.apache.org>

Re: Use of final modifiers - WAS svn commit: r1632171 [1/20] - in /commons/proper/beanutils/trunk/src: main/java/org/apache/commons/beanutils/ main/java/org/apache/commons/beanutils/converters/ main/java/org/apache/commons/beanutils/expression/ main/java/org/apache/commons/beanutils/l...

Posted by Oliver Heger <ol...@oliver-heger.de>.


Am 27.10.2014 um 02:04 schrieb Gary Gregory:
> On Sat, Oct 25, 2014 at 3:27 PM, Oliver Heger <ol...@oliver-heger.de>
> wrote:
> 
>>
>>
>> Am 24.10.2014 um 22:47 schrieb Mark Thomas:
>>> On 24/10/2014 21:17, Oliver Heger wrote:
>>>>
>>>>
>>>> Am 24.10.2014 um 22:01 schrieb Gary Gregory:
>>>>> On Fri, Oct 24, 2014 at 3:23 PM, Oliver Heger <
>> oliver.heger@oliver-heger.de>
>>>>> wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> Am 23.10.2014 um 22:58 schrieb Gary Gregory:
>>>>>>> Patches go stale no matter what...
>>>>>>
>>>>>> Right, this can happen during normal development, but not necessarily
>>>>>> because of a big bang change for which there is no technical reason,
>> but
>>>>>> which is just a matter of personal taste.
>>>>>>
>>>>>
>>>>> I call it a technical reason, you call it personal taste, we are not
>> going
>>>>> to agree.
>>>>
>>>> Obviously not. So how do we proceed?
>>>
>>> You work it out until a consensus is reached and then that consensus is
>>> implemented. The more entrenched folks are in their positions, the
>>> longer consensus is going to take. (And no, a VOTE is not the right way
>>> to resolve this.)
>>>
>>> My own view is that the addition of the final keywords does have
>>> technical merit. Not enough to make me want to spend the time to fix the
>>> projects I work on, but I wouldn't complain if someone else wanted to
>>> make all the necessary changes. Similarly while I think it would be a
>>> shame to throw away all this good work, I could live with that option if
>>> that was the consensus opinion.
>>>
>>> The issue of out-dated patches is a red herring. That is a separate
>>> problem. The community needs to apply / review patches faster.
>>>
>>> Mark
>>
>> Okay, so back to discussion.
>>
>> First of all I have to state that I am irritated about the way this
>> change was done. It is really an invasive commit without any prior
>> announcement. For a collaborative project I do not consider this as good
>> style. As some replies to this thread show, there is no consensus about
>> the changes performed.
>>
>> As an example on the same level,
> 
> 
> This is a silly example IMO because you talk about using a Windows C
> _naming_ convention in Java, which has zero effect on compiled code, while
> we are talking about using a Java language feature which does matter to the
> compiler. Apples and Oranges.

Not in the sense that both changes aim at making code more
understandable without having any impact on functionality.

> 
> 
>> I could come to the idea that I prefer
>> variable names with special prefixes. In C programming under Windows
>> there was a convention of adding prefixes to variable names derived from
>> their data type: String sName, int iCount, Double[] adNumbers, etc. What
>> could argue that this makes code more understandable because each
>> variable carries meta-information with it. If I suddenly started to
>> rework the code of multiple components based on this convention, I would
>> surely trigger some reactions.
>>
>> IIUC, the purpose behind this change is to make the intension of the
>> programmer explicit that a specific variable is not going to be changed.
>>
> 
> It is that, and more. Just as important and perhaps more so: When I read
> code or I am stepping in a debugger and I see a 'final' I know that a value
> is not going to change from under my feet. I can put that aside as a
> variable (pun intended) in my mind and worry about other aspects of the
> code.

The vast majority of Java code I encounter does not use final modifiers
in this way (I know, it is your mission to change this). Therefore, when
I see a final I ask myself what is the special purpose here? Is it
referenced by an anonymous class?

The information whether a variable cannot be changed has not been that
important for me; this can easily be spotted from the context: if there
is an assignment, well it is changed. Otherwise, your method is probably
too complex and needs refactoring.

Oliver

> 
> Gary
> 
> 
>> I doubt that you manually inspected the whole code base. Rather, I
>> assume you used a tool - Eclipse has a corresponding option - which
>> analyzed all possible code paths to determine whether a variable can be
>> final. This does not tell too much about the intentions of the original
>> authors. Further, when using such a tool there is not much intellectual
>> work behind this. Please correct me if I am wrong here.
>>
>> From my perspective the excessive use of final modifiers makes code
>> harder to read because it adds so much noise. There are some places when
>> Java requires the use of final; but those special places which may be of
>> interest are now completely hidden in the overall final fog.
>>
>> Oliver
>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
> 
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org

Re: Use of final modifiers - WAS svn commit: r1632171 [1/20] - in /commons/proper/beanutils/trunk/src: main/java/org/apache/commons/beanutils/ main/java/org/apache/commons/beanutils/converters/ main/java/org/apache/commons/beanutils/expression/ main/java/org/apache/commons/beanutils/l...

Posted by Paul Benedict <pb...@apache.org>.

Even I must admit that the use of "final" here is more of a formality than
a necessity. I believe that's why it's been called a "stylistic" commit.
The compiler isn't driving you to use it for what you need to accomplish,
and there is no pressing technical need to use it aside from it enforces
something you don't like. The current code works just fine with or without
"final" in this commit, which is why I do consider it to be more of a
personal style than anything else.

Cheers,
Paul

On Sun, Oct 26, 2014 at 8:04 PM, Gary Gregory <ga...@gmail.com>
wrote:

> On Sat, Oct 25, 2014 at 3:27 PM, Oliver Heger <
> oliver.heger@oliver-heger.de>
> wrote:
>
> >
> >
> > Am 24.10.2014 um 22:47 schrieb Mark Thomas:
> > > On 24/10/2014 21:17, Oliver Heger wrote:
> > >>
> > >>
> > >> Am 24.10.2014 um 22:01 schrieb Gary Gregory:
> > >>> On Fri, Oct 24, 2014 at 3:23 PM, Oliver Heger <
> > oliver.heger@oliver-heger.de>
> > >>> wrote:
> > >>>
> > >>>>
> > >>>>
> > >>>> Am 23.10.2014 um 22:58 schrieb Gary Gregory:
> > >>>>> Patches go stale no matter what...
> > >>>>
> > >>>> Right, this can happen during normal development, but not
> necessarily
> > >>>> because of a big bang change for which there is no technical reason,
> > but
> > >>>> which is just a matter of personal taste.
> > >>>>
> > >>>
> > >>> I call it a technical reason, you call it personal taste, we are not
> > going
> > >>> to agree.
> > >>
> > >> Obviously not. So how do we proceed?
> > >
> > > You work it out until a consensus is reached and then that consensus is
> > > implemented. The more entrenched folks are in their positions, the
> > > longer consensus is going to take. (And no, a VOTE is not the right way
> > > to resolve this.)
> > >
> > > My own view is that the addition of the final keywords does have
> > > technical merit. Not enough to make me want to spend the time to fix
> the
> > > projects I work on, but I wouldn't complain if someone else wanted to
> > > make all the necessary changes. Similarly while I think it would be a
> > > shame to throw away all this good work, I could live with that option
> if
> > > that was the consensus opinion.
> > >
> > > The issue of out-dated patches is a red herring. That is a separate
> > > problem. The community needs to apply / review patches faster.
> > >
> > > Mark
> >
> > Okay, so back to discussion.
> >
> > First of all I have to state that I am irritated about the way this
> > change was done. It is really an invasive commit without any prior
> > announcement. For a collaborative project I do not consider this as good
> > style. As some replies to this thread show, there is no consensus about
> > the changes performed.
> >
> > As an example on the same level,
>
>
> This is a silly example IMO because you talk about using a Windows C
> _naming_ convention in Java, which has zero effect on compiled code, while
> we are talking about using a Java language feature which does matter to the
> compiler. Apples and Oranges.
>
>
> > I could come to the idea that I prefer
> > variable names with special prefixes. In C programming under Windows
> > there was a convention of adding prefixes to variable names derived from
> > their data type: String sName, int iCount, Double[] adNumbers, etc. What
> > could argue that this makes code more understandable because each
> > variable carries meta-information with it. If I suddenly started to
> > rework the code of multiple components based on this convention, I would
> > surely trigger some reactions.
> >
> > IIUC, the purpose behind this change is to make the intension of the
> > programmer explicit that a specific variable is not going to be changed.
> >
>
> It is that, and more. Just as important and perhaps more so: When I read
> code or I am stepping in a debugger and I see a 'final' I know that a value
> is not going to change from under my feet. I can put that aside as a
> variable (pun intended) in my mind and worry about other aspects of the
> code.
>
> Gary
>
>
> > I doubt that you manually inspected the whole code base. Rather, I
> > assume you used a tool - Eclipse has a corresponding option - which
> > analyzed all possible code paths to determine whether a variable can be
> > final. This does not tell too much about the intentions of the original
> > authors. Further, when using such a tool there is not much intellectual
> > work behind this. Please correct me if I am wrong here.
> >
> > From my perspective the excessive use of final modifiers makes code
> > harder to read because it adds so much noise. There are some places when
> > Java requires the use of final; but those special places which may be of
> > interest are now completely hidden in the overall final fog.
> >
> > Oliver
>

Re: Use of final modifiers - WAS svn commit: r1632171 [1/20] - in /commons/proper/beanutils/trunk/src: main/java/org/apache/commons/beanutils/ main/java/org/apache/commons/beanutils/converters/ main/java/org/apache/commons/beanutils/expression/ main/java/org/apache/commons/beanutils/l...

Posted by Gary Gregory <ga...@gmail.com>.

On Sat, Oct 25, 2014 at 3:27 PM, Oliver Heger <ol...@oliver-heger.de>
wrote:

>
>
> Am 24.10.2014 um 22:47 schrieb Mark Thomas:
> > On 24/10/2014 21:17, Oliver Heger wrote:
> >>
> >>
> >> Am 24.10.2014 um 22:01 schrieb Gary Gregory:
> >>> On Fri, Oct 24, 2014 at 3:23 PM, Oliver Heger <
> oliver.heger@oliver-heger.de>
> >>> wrote:
> >>>
> >>>>
> >>>>
> >>>> Am 23.10.2014 um 22:58 schrieb Gary Gregory:
> >>>>> Patches go stale no matter what...
> >>>>
> >>>> Right, this can happen during normal development, but not necessarily
> >>>> because of a big bang change for which there is no technical reason,
> but
> >>>> which is just a matter of personal taste.
> >>>>
> >>>
> >>> I call it a technical reason, you call it personal taste, we are not
> going
> >>> to agree.
> >>
> >> Obviously not. So how do we proceed?
> >
> > You work it out until a consensus is reached and then that consensus is
> > implemented. The more entrenched folks are in their positions, the
> > longer consensus is going to take. (And no, a VOTE is not the right way
> > to resolve this.)
> >
> > My own view is that the addition of the final keywords does have
> > technical merit. Not enough to make me want to spend the time to fix the
> > projects I work on, but I wouldn't complain if someone else wanted to
> > make all the necessary changes. Similarly while I think it would be a
> > shame to throw away all this good work, I could live with that option if
> > that was the consensus opinion.
> >
> > The issue of out-dated patches is a red herring. That is a separate
> > problem. The community needs to apply / review patches faster.
> >
> > Mark
>
> Okay, so back to discussion.
>
> First of all I have to state that I am irritated about the way this
> change was done. It is really an invasive commit without any prior
> announcement. For a collaborative project I do not consider this as good
> style. As some replies to this thread show, there is no consensus about
> the changes performed.
>
> As an example on the same level,


This is a silly example IMO because you talk about using a Windows C
_naming_ convention in Java, which has zero effect on compiled code, while
we are talking about using a Java language feature which does matter to the
compiler. Apples and Oranges.


> I could come to the idea that I prefer
> variable names with special prefixes. In C programming under Windows
> there was a convention of adding prefixes to variable names derived from
> their data type: String sName, int iCount, Double[] adNumbers, etc. What
> could argue that this makes code more understandable because each
> variable carries meta-information with it. If I suddenly started to
> rework the code of multiple components based on this convention, I would
> surely trigger some reactions.
>
> IIUC, the purpose behind this change is to make the intension of the
> programmer explicit that a specific variable is not going to be changed.
>

It is that, and more. Just as important and perhaps more so: When I read
code or I am stepping in a debugger and I see a 'final' I know that a value
is not going to change from under my feet. I can put that aside as a
variable (pun intended) in my mind and worry about other aspects of the
code.

Gary


> I doubt that you manually inspected the whole code base. Rather, I
> assume you used a tool - Eclipse has a corresponding option - which
> analyzed all possible code paths to determine whether a variable can be
> final. This does not tell too much about the intentions of the original
> authors. Further, when using such a tool there is not much intellectual
> work behind this. Please correct me if I am wrong here.
>
> From my perspective the excessive use of final modifiers makes code
> harder to read because it adds so much noise. There are some places when
> Java requires the use of final; but those special places which may be of
> interest are now completely hidden in the overall final fog.
>
> Oliver
>
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>


-- 
E-Mail: garydgregory@gmail.com | ggregory@apache.org
Java Persistence with Hibernate, Second Edition
<http://www.manning.com/bauer3/>
JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
Spring Batch in Action <http://www.manning.com/templier/>
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

Use of final modifiers - WAS svn commit: r1632171 [1/20] - in /commons/proper/beanutils/trunk/src: main/java/org/apache/commons/beanutils/ main/java/org/apache/commons/beanutils/converters/ main/java/org/apache/commons/beanutils/expression/ main/java/org/apache/commons/beanutils/l...

Posted by Oliver Heger <ol...@oliver-heger.de>.

Am 24.10.2014 um 22:47 schrieb Mark Thomas:
> On 24/10/2014 21:17, Oliver Heger wrote:
>>
>>
>> Am 24.10.2014 um 22:01 schrieb Gary Gregory:
>>> On Fri, Oct 24, 2014 at 3:23 PM, Oliver Heger <ol...@oliver-heger.de>
>>> wrote:
>>>
>>>>
>>>>
>>>> Am 23.10.2014 um 22:58 schrieb Gary Gregory:
>>>>> Patches go stale no matter what...
>>>>
>>>> Right, this can happen during normal development, but not necessarily
>>>> because of a big bang change for which there is no technical reason, but
>>>> which is just a matter of personal taste.
>>>>
>>>
>>> I call it a technical reason, you call it personal taste, we are not going
>>> to agree.
>>
>> Obviously not. So how do we proceed?
> 
> You work it out until a consensus is reached and then that consensus is
> implemented. The more entrenched folks are in their positions, the
> longer consensus is going to take. (And no, a VOTE is not the right way
> to resolve this.)
> 
> My own view is that the addition of the final keywords does have
> technical merit. Not enough to make me want to spend the time to fix the
> projects I work on, but I wouldn't complain if someone else wanted to
> make all the necessary changes. Similarly while I think it would be a
> shame to throw away all this good work, I could live with that option if
> that was the consensus opinion.
> 
> The issue of out-dated patches is a red herring. That is a separate
> problem. The community needs to apply / review patches faster.
> 
> Mark

Okay, so back to discussion.

First of all I have to state that I am irritated about the way this
change was done. It is really an invasive commit without any prior
announcement. For a collaborative project I do not consider this as good
style. As some replies to this thread show, there is no consensus about
the changes performed.

As an example on the same level, I could come to the idea that I prefer
variable names with special prefixes. In C programming under Windows
there was a convention of adding prefixes to variable names derived from
their data type: String sName, int iCount, Double[] adNumbers, etc. What
could argue that this makes code more understandable because each
variable carries meta-information with it. If I suddenly started to
rework the code of multiple components based on this convention, I would
surely trigger some reactions.

IIUC, the purpose behind this change is to make the intension of the
programmer explicit that a specific variable is not going to be changed.
I doubt that you manually inspected the whole code base. Rather, I
assume you used a tool - Eclipse has a corresponding option - which
analyzed all possible code paths to determine whether a variable can be
final. This does not tell too much about the intentions of the original
authors. Further, when using such a tool there is not much intellectual
work behind this. Please correct me if I am wrong here.

>From my perspective the excessive use of final modifiers makes code
harder to read because it adds so much noise. There are some places when
Java requires the use of final; but those special places which may be of
interest are now completely hidden in the overall final fog.

Oliver

> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org