You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@velocity.apache.org by Claude Brisson <cl...@renegat.net.INVALID> on 2019/02/22 23:40:30 UTC
Merging VELOCITY-892
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<Integer> 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-unsubscribe@velocity.apache.org
For additional commands, e-mail: dev-help@velocity.apache.org
Re: Merging VELOCITY-892
Posted by Claude Brisson <cl...@renegat.net.INVALID>.
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<Integer> or List<Float>, 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-unsubscribe@velocity.apache.org
> For additional commands, e-mail: dev-help@velocity.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org
For additional commands, e-mail: dev-help@velocity.apache.org
Re: Merging VELOCITY-892
Posted by Claude Brisson <cl...@renegat.net.INVALID>.
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<Integer> or List<Float>, 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-unsubscribe@velocity.apache.org
For additional commands, e-mail: dev-help@velocity.apache.org
Re: Merging VELOCITY-892
Posted by Michael Osipov <mi...@apache.org>.
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<Integer> 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-unsubscribe@velocity.apache.org
For additional commands, e-mail: dev-help@velocity.apache.org
Re: Merging VELOCITY-892
Posted by Nate Chadwick <na...@percussion.com>.
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 <cl...@renegat.net.invalid>
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<Integer> 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-unsubscribe@velocity.apache.org
> For additional commands, e-mail: dev-help@velocity.apache.org
>
>
--
*Nate Chadwick • Vice President of Products & Services*
(0) 781-835-1356 | (M) 781-835-8766 | nate_chadwick@percussion.com
600 Unicorn Park Drive, 2nd Floor | Woburn, MA 01801 | www.percussion.com
*Follow us on Twitter @percussion <https://twitter.com/percussion>*
<http://www.percussion.com/products/cm1/video-demo/index>
Re: Merging VELOCITY-892
Posted by Nathan Bubna <nb...@gmail.com>.
+1 Java 8 has been around plenty long
On Fri, Feb 22, 2019 at 3:40 PM Claude Brisson <cl...@renegat.net.invalid>
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<Integer> 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-unsubscribe@velocity.apache.org
> For additional commands, e-mail: dev-help@velocity.apache.org
>
>