Re: Merging VELOCITY-892

[Claude Brisson]

Oh, and I just saw that commons-lang3 is also moving the target jdk to 
1.8 in their next release (3.9).


See the discussion in the dev list [1], the jira issue [2] and the 
commit [3].


So there is no point in holding back to 1.7, I can obviously merge the 
VELOCITY-892 branch.


 [1]: 
https://lists.apache.org/thread.html/4432e7ee064cb4162eda3c79f881256b1c42bcd4e1cf0203d0a0e852@%3Cdev.commons.apache.org%3E

 [2]: https://issues.apache.org/jira/browse/LANG-1415
 [3]: 
https://gitbox.apache.org/repos/asf?p=commons-lang.git;a=commit;h=b4609c81e41d678cf03898a7cc4a4660beef0f88


On 23/02/2019 11:22, Claude Brisson wrote:

On 2/23/19 8:52 AM, Michael Osipov wrote:
I think it is absolutely not our task to split strings for user's 
convenience. The next one will request another separator and so on. 
We should add at most a splitter tool. What we could do is to provide 
a new syntax: "$obj.foo([1,2,3,4,5])", but that is another story and 
out of my knowledge


We're not splitting strings for the user. Sorry if the given example 
wasn't clear.


What VELOCITY-892 does is provide a way for the user to *specify* such 
a converter towards List or List, whereas without it, 
he can only specify a single converter towards List.




As for Java 8, don't do if you don't have a compelling reaons, i.e., 
rewriting most of the codebase to use Java 8 features. We yet event 
didn't move to generics in some places.


Hopefully, since we don't anywhere rely on HashMap ordering, the 
change is fully backward compatible. Requiring Java 1.8 opens the door 
to some interesting features like static/default interface methods and 
streaming APIs.


Yes, there are many places where the source code could be modernized. 
But I don't see how this stops us from moving to 1.8, on the contrary. 
Should one decide to tackle obsolete syntaxes, better do it with 1.8.


  Claude



-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org




-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org

Re: Merging VELOCITY-892

[Claude Brisson]

On 2/23/19 8:52 AM, Michael Osipov wrote:
I think it is absolutely not our task to split strings for user's 
convenience. The next one will request another separator and so on. We 
should add at most a splitter tool. What we could do is to provide a 
new syntax: "$obj.foo([1,2,3,4,5])", but that is another story and out 
of my knowledge


We're not splitting strings for the user. Sorry if the given example 
wasn't clear.


What VELOCITY-892 does is provide a way for the user to *specify* such a 
converter towards List or List, whereas without it, he 
can only specify a single converter towards List.




As for Java 8, don't do if you don't have a compelling reaons, i.e., 
rewriting most of the codebase to use Java 8 features. We yet event 
didn't move to generics in some places.


Hopefully, since we don't anywhere rely on HashMap ordering, the change 
is fully backward compatible. Requiring Java 1.8 opens the door to some 
interesting features like static/default interface methods and streaming 
APIs.


Yes, there are many places where the source code could be modernized. 
But I don't see how this stops us from moving to 1.8, on the contrary. 
Should one decide to tackle obsolete syntaxes, better do it with 1.8.


  Claude



-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org

Re: Merging VELOCITY-892

[Michael Osipov]

Am 2019-02-23 um 00:40 schrieb Claude Brisson:

Hi all.

The VELOCITY-892 branch contains a fix for the corresponding issue [1].

The purpose is to let the method arguments conversion handler manipulate 
the formal arguments types as java.lang.reflect.Type rather than 
java.lang.Class, so that when dealing with a method like


   void foo(List list)

called with a string like "1,2,3", the conversion handler can choose the 
correct converter between several string->list converters.


But merging the VELOCITY-892 branch back to trunk requires a minimal jdk 
version of 1.8 (because of the Type.getTypeName() method).


Java SE 8 is now five years old, so I don't think it's a problem.

Any objection?


I think it is absolutely not our task to split strings for user's 
convenience. The next one will request another separator and so on. We 
should add at most a splitter tool. What we could do is to provide a new 
syntax: "$obj.foo([1,2,3,4,5])", but that is another story and out of my 
knowledge


As for Java 8, don't do if you don't have a compelling reaons, i.e., 
rewriting most of the codebase to use Java 8 features. We yet event 
didn't move to generics in some places.


Michael


-
To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
For additional commands, e-mail: dev-h...@velocity.apache.org

Re: Merging VELOCITY-892

[Nate Chadwick]

I think upping the JDK  version is good and healthy.  Are there any worries
about JDK 1.8 changes in the Velocity code base?  The main thing I have
seen get messed up in our code bases are routines that use Maps/Hashmaps
that expected things to be in the order added which changed in that jdk
version.

https://docs.oracle.com/javase/8/docs/technotes/guides/collections/changes8.html


-n

On Fri, Feb 22, 2019 at 6:40 PM Claude Brisson 
wrote:

> Hi all.
>
> The VELOCITY-892 branch contains a fix for the corresponding issue [1].
>
> The purpose is to let the method arguments conversion handler manipulate
> the formal arguments types as java.lang.reflect.Type rather than
> java.lang.Class, so that when dealing with a method like
>
>void foo(List list)
>
> called with a string like "1,2,3", the conversion handler can choose the
> correct converter between several string->list converters.
>
> But merging the VELOCITY-892 branch back to trunk requires a minimal jdk
> version of 1.8 (because of the Type.getTypeName() method).
>
> Java SE 8 is now five years old, so I don't think it's a problem.
>
> Any objection?
>
> This would also involve raising the source and target versions to 1.8
> for consistency.
>
> [1] https://issues.apache.org/jira/projects/VELOCITY/issues/VELOCITY-892
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
> For additional commands, e-mail: dev-h...@velocity.apache.org
>
>

-- 
*Nate Chadwick • Vice President of Products & Services*
(0) 781-835-1356 |  (M) 781-835-8766 | nate_chadw...@percussion.com
600 Unicorn Park Drive, 2nd Floor | Woburn, MA 01801 | www.percussion.com

*Follow us on Twitter @percussion *

Re: Merging VELOCITY-892

[Nathan Bubna]

+1 Java 8 has been around plenty long

On Fri, Feb 22, 2019 at 3:40 PM Claude Brisson 
wrote:

> Hi all.
>
> The VELOCITY-892 branch contains a fix for the corresponding issue [1].
>
> The purpose is to let the method arguments conversion handler manipulate
> the formal arguments types as java.lang.reflect.Type rather than
> java.lang.Class, so that when dealing with a method like
>
>void foo(List list)
>
> called with a string like "1,2,3", the conversion handler can choose the
> correct converter between several string->list converters.
>
> But merging the VELOCITY-892 branch back to trunk requires a minimal jdk
> version of 1.8 (because of the Type.getTypeName() method).
>
> Java SE 8 is now five years old, so I don't think it's a problem.
>
> Any objection?
>
> This would also involve raising the source and target versions to 1.8
> for consistency.
>
> [1] https://issues.apache.org/jira/projects/VELOCITY/issues/VELOCITY-892
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org
> For additional commands, e-mail: dev-h...@velocity.apache.org
>
>