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://
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 i
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 whe
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
versio
+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
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 l
