[ANNOUNCE] Velocity Engine 2.0 RC6 test build available

[Claude Brisson <cl...@renegat.net>]

A new test build of Velocity Engine 2.0 is available (RC6).

No determination as to the quality ('alpha,' 'beta,' or 'GA') of 
Velocity Engine 2.0 has been made, and at this time it is simply a "test 
build". We welcome any comments you may have, and will take all feedback 
into account if a quality vote is called for this build.

Release notes:

* 
https://dist.apache.org/repos/dist/dev/velocity/velocity-engine/2.0/release-notes.html 


Distribution:

  * https://dist.apache.org/repos/dist/dev/velocity/velocity-engine/2.0/

Maven 2 staging repository:

  * 
https://repository.apache.org/content/repositories/orgapachevelocity-1016/

A vote regarding the quality of this test build will be initiated within 
the next couple of days.

Release Candidates changelog:
   RC1: initial candidate
   RC2: bugfixes
   RC3: review SLF4J Logger names (instead of a single logger named 
"Velocity", have a hierarchy of loggers with a base of 
'org.apache.velocity')
   RC4: minor fixes
   RC5:
    * the default encoding is now UTF-8 (and not the platform default)
    * commons-collections is not any more a compilation dependency
    * commons-lang3 dependency is not any more shaded
    * the configuration API doesn't reference ExtProperties
    * the events API has been optimized and reviewed: all events do 
receive the current Context
    * there has been a few optimizations in ASTStringLiteral rendering
RC6: mostly code cleaning and build process optimization ; assembly 
module has been dropped


Regards,

   Claude

Re: Velocity truth

[Michael Osipov <mi...@apache.org>]

Looks sound, nothing to complain here.

Am 2017-02-07 um 02:42 schrieb Claude Brisson:
> Another try:
>
> 1) return false for a null object
>
> 2) return its value for a Boolean object, or the result of the
> getAsBoolean() method if it exists.
>
> 3) If directive.if.emptycheck = false (true by default), stop here and
> return true.
>
> 4) check for emptiness:
>   - return whether an array is empty.
>   - return whether isEmpty() is false (covers String and all Collection
> classes).
>   - return whether length() is zero (covers CharSequence classes other
> than String).
>   - returns whether size() is zero.
>   - return whether a Number *strictly* equals zero.
>
> 5) check for emptiness after explicit conversion methods:
>   - return whether the result of getAsString() is empty (and false for a
> null result) if it exists.
>   - return whether the result of getAsNumber() *strictly* equals zero
> (and false for a null result) if it exists.
>
> About toString(), I agree that we could simply drop it along with its
> configuration setting: we're talking about non-basic objects, which
> don't have any size() or length() or isEmpty() method, and whose
> toString() method could still return null or the empty string. Pretty
> rare, I guess. And for such an object, the user may only want to check
> whether it's null or not when he writes #if($foo).
>
> We will also clearly state in the docs that checking for null can be
> done with #if($foo == $null), for false with #if($foo == false), and for
> empty string with #if("$!foo" == "").
>
>   Claude
>
>
> On 06/02/2017 19:55, Michael Osipov wrote:
>> Am 2017-02-06 um 19:45 schrieb Nathan Bubna:
>>> On Mon, Feb 6, 2017 at 10:32 AM, Michael Osipov <mi...@apache.org>
>>> wrote:
>>>
>>>> Am 2017-02-06 um 19:23 schrieb Nathan Bubna:
>>>>
>>>>> On Mon, Feb 6, 2017 at 9:43 AM, Michael Osipov <mi...@apache.org>
>>>>> wrote:
>>>>>
>>>>>> 7) check object for a length() or size() method, if so return
>>>>>> whether it
>>>>>>
>>>>>>> returns 0, but I agree with Alex Fedotov that we could skip those
>>>>>>> methods if we already took care for strings and collections.
>>>>>>>
>>>>>>>
>>>>>> What happened to array#length? You completely missed that out.
>>>>>> I would not drop #length() and #size(), you'd ultimately fail with
>>>>>> javax.naming.directory.Attribute#size() or
>>>>>> javax.naming.directory.Attributes#size().
>>>>>> There are likely more examples to have this.
>>>>>>
>>>>>
>>>>>
>>>>> i don't think it hurts to keep them, most users won't often get
>>>>> that far,
>>>>> i
>>>>> think.
>>>>>
>>>>
>>>> I did not say we should drop them, I said that they are crucial in some
>>>> situations. Dropping them would be wrong.
>>>
>>>
>>>
>>> Yup. I was agreeing. :)
>>>
>>>
>>>> 8) If directive.if.tostring.check = false, stop here and return true
>>>> (*)
>>>>>
>>>>>>
>>>>>>> 9) check object for a toString() method, and return whether the
>>>>>>> string
>>>>>>> is non-null and non-empty
>>>>>>>
>>>>>>> The 6th step won't be reached very often...
>>>>>>>
>>>>>>> (*) the old configuration parameter was
>>>>>>> directive.if.tostring.nullchec
>>>>>>> k,
>>>>>>> but for consistency with the new behavior regarding empty
>>>>>>> strings, my
>>>>>>> proposal is to rename it like this. I don't consider that backward
>>>>>>> compatibility is important since all collections are handled
>>>>>>> above in
>>>>>>> the chain.
>>>>>>>
>>>>>>>
>>>>>> 9) is somewhat confusing because #toString() is never null unless you
>>>>>> override it and return a custom string. Moreover, how will a
>>>>>> #toString()
>>>>>> guarantee you that an object is logically empty? It can't, see
>>>>>> javax.naming.directory.SearchResult#getAttributes().
>>>>>>
>>>>>> At best, this would be false by default in 2.0.
>>>>>>
>>>>>
>>>>> ...
>>>>>
>>>>> I still back this check. Velocity is for templating, text output,
>>>>> i.e. a
>>>>> display language. Velocity-specific classes (including some
>>>>> VelocityTools)
>>>>> have had cause in the past to return null or empty strings
>>>>> specifically
>>>>> because of this check and that toString() is regularly central to
>>>>> rendering
>>>>> objects. While it cannot guarantee emptiness for every object out
>>>>> there,
>>>>> it
>>>>> is a sensible check. The goal here is not perfection, but to catch
>>>>> common
>>>>> cases, and due to history, i believe this is a common one.
>>>>>
>>>>
>>>> Again, there might be cases this is necessary though I cannot make
>>>> up one
>>>> from the top of my head. I am just saying that this should not be a
>>>> default
>>>> setting and people must know what they enable at the end.
>>>
>>>
>>> My concern was backward compatibility, which, while not necessary, is
>>> still
>>> quite valuable. There are existing VelocityTools that rely on this,
>>> after
>>> all. Given all the ways to avoid getting to this check, i don't see the
>>> compelling reason to toggle the default here. Though, as always, i will
>>> defer to those doing actual work right now. :) Just chiming in with
>>> my two
>>> bits.
>>
>> This is a new major release (!) for a for period of time, approaches
>> chang, so should software. We shall take the freedom and do the right
>> step forward. After all, people don't like surprises if the world
>> keeps revolving and you don't move with it.
>>
>>
>> ---------------------------------------------------------------------
>> 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
>
>


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

Re: Velocity truth

[Claude Brisson <cl...@renegat.net>]

Another try:

1) return false for a null object

2) return its value for a Boolean object, or the result of the 
getAsBoolean() method if it exists.

3) If directive.if.emptycheck = false (true by default), stop here and 
return true.

4) check for emptiness:
   - return whether an array is empty.
   - return whether isEmpty() is false (covers String and all Collection 
classes).
   - return whether length() is zero (covers CharSequence classes other 
than String).
   - returns whether size() is zero.
   - return whether a Number *strictly* equals zero.

5) check for emptiness after explicit conversion methods:
   - return whether the result of getAsString() is empty (and false for 
a null result) if it exists.
   - return whether the result of getAsNumber() *strictly* equals zero 
(and false for a null result) if it exists.

About toString(), I agree that we could simply drop it along with its 
configuration setting: we're talking about non-basic objects, which 
don't have any size() or length() or isEmpty() method, and whose 
toString() method could still return null or the empty string. Pretty 
rare, I guess. And for such an object, the user may only want to check 
whether it's null or not when he writes #if($foo).

We will also clearly state in the docs that checking for null can be 
done with #if($foo == $null), for false with #if($foo == false), and for 
empty string with #if("$!foo" == "").

   Claude


On 06/02/2017 19:55, Michael Osipov wrote:
> Am 2017-02-06 um 19:45 schrieb Nathan Bubna:
>> On Mon, Feb 6, 2017 at 10:32 AM, Michael Osipov <mi...@apache.org> 
>> wrote:
>>
>>> Am 2017-02-06 um 19:23 schrieb Nathan Bubna:
>>>
>>>> On Mon, Feb 6, 2017 at 9:43 AM, Michael Osipov <mi...@apache.org>
>>>> wrote:
>>>>
>>>>> 7) check object for a length() or size() method, if so return 
>>>>> whether it
>>>>>
>>>>>> returns 0, but I agree with Alex Fedotov that we could skip those
>>>>>> methods if we already took care for strings and collections.
>>>>>>
>>>>>>
>>>>> What happened to array#length? You completely missed that out.
>>>>> I would not drop #length() and #size(), you'd ultimately fail with
>>>>> javax.naming.directory.Attribute#size() or
>>>>> javax.naming.directory.Attributes#size().
>>>>> There are likely more examples to have this.
>>>>>
>>>>
>>>>
>>>> i don't think it hurts to keep them, most users won't often get 
>>>> that far,
>>>> i
>>>> think.
>>>>
>>>
>>> I did not say we should drop them, I said that they are crucial in some
>>> situations. Dropping them would be wrong.
>>
>>
>>
>> Yup. I was agreeing. :)
>>
>>
>>> 8) If directive.if.tostring.check = false, stop here and return true 
>>> (*)
>>>>
>>>>>
>>>>>> 9) check object for a toString() method, and return whether the 
>>>>>> string
>>>>>> is non-null and non-empty
>>>>>>
>>>>>> The 6th step won't be reached very often...
>>>>>>
>>>>>> (*) the old configuration parameter was 
>>>>>> directive.if.tostring.nullchec
>>>>>> k,
>>>>>> but for consistency with the new behavior regarding empty 
>>>>>> strings, my
>>>>>> proposal is to rename it like this. I don't consider that backward
>>>>>> compatibility is important since all collections are handled 
>>>>>> above in
>>>>>> the chain.
>>>>>>
>>>>>>
>>>>> 9) is somewhat confusing because #toString() is never null unless you
>>>>> override it and return a custom string. Moreover, how will a 
>>>>> #toString()
>>>>> guarantee you that an object is logically empty? It can't, see
>>>>> javax.naming.directory.SearchResult#getAttributes().
>>>>>
>>>>> At best, this would be false by default in 2.0.
>>>>>
>>>>
>>>> ...
>>>>
>>>> I still back this check. Velocity is for templating, text output, 
>>>> i.e. a
>>>> display language. Velocity-specific classes (including some 
>>>> VelocityTools)
>>>> have had cause in the past to return null or empty strings 
>>>> specifically
>>>> because of this check and that toString() is regularly central to
>>>> rendering
>>>> objects. While it cannot guarantee emptiness for every object out 
>>>> there,
>>>> it
>>>> is a sensible check. The goal here is not perfection, but to catch 
>>>> common
>>>> cases, and due to history, i believe this is a common one.
>>>>
>>>
>>> Again, there might be cases this is necessary though I cannot make 
>>> up one
>>> from the top of my head. I am just saying that this should not be a 
>>> default
>>> setting and people must know what they enable at the end.
>>
>>
>> My concern was backward compatibility, which, while not necessary, is 
>> still
>> quite valuable. There are existing VelocityTools that rely on this, 
>> after
>> all. Given all the ways to avoid getting to this check, i don't see the
>> compelling reason to toggle the default here. Though, as always, i will
>> defer to those doing actual work right now. :) Just chiming in with 
>> my two
>> bits.
>
> This is a new major release (!) for a for period of time, approaches 
> chang, so should software. We shall take the freedom and do the right 
> step forward. After all, people don't like surprises if the world 
> keeps revolving and you don't move with it.
>
>
> ---------------------------------------------------------------------
> 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: Velocity truth

[Michael Osipov <mi...@apache.org>]

Am 2017-02-06 um 19:45 schrieb Nathan Bubna:
> On Mon, Feb 6, 2017 at 10:32 AM, Michael Osipov <mi...@apache.org> wrote:
>
>> Am 2017-02-06 um 19:23 schrieb Nathan Bubna:
>>
>>> On Mon, Feb 6, 2017 at 9:43 AM, Michael Osipov <mi...@apache.org>
>>> wrote:
>>>
>>>> 7) check object for a length() or size() method, if so return whether it
>>>>
>>>>> returns 0, but I agree with Alex Fedotov that we could skip those
>>>>> methods if we already took care for strings and collections.
>>>>>
>>>>>
>>>> What happened to array#length? You completely missed that out.
>>>> I would not drop #length() and #size(), you'd ultimately fail with
>>>> javax.naming.directory.Attribute#size() or
>>>> javax.naming.directory.Attributes#size().
>>>> There are likely more examples to have this.
>>>>
>>>
>>>
>>> i don't think it hurts to keep them, most users won't often get that far,
>>> i
>>> think.
>>>
>>
>> I did not say we should drop them, I said that they are crucial in some
>> situations. Dropping them would be wrong.
>
>
>
> Yup. I was agreeing. :)
>
>
>> 8) If directive.if.tostring.check = false, stop here and return true (*)
>>>
>>>>
>>>>> 9) check object for a toString() method, and return whether the string
>>>>> is non-null and non-empty
>>>>>
>>>>> The 6th step won't be reached very often...
>>>>>
>>>>> (*) the old configuration parameter was directive.if.tostring.nullchec
>>>>> k,
>>>>> but for consistency with the new behavior regarding empty strings, my
>>>>> proposal is to rename it like this. I don't consider that backward
>>>>> compatibility is important since all collections are handled above in
>>>>> the chain.
>>>>>
>>>>>
>>>> 9) is somewhat confusing because #toString() is never null unless you
>>>> override it and return a custom string. Moreover, how will a #toString()
>>>> guarantee you that an object is logically empty? It can't, see
>>>> javax.naming.directory.SearchResult#getAttributes().
>>>>
>>>> At best, this would be false by default in 2.0.
>>>>
>>>
>>> ...
>>>
>>> I still back this check. Velocity is for templating, text output, i.e. a
>>> display language. Velocity-specific classes (including some VelocityTools)
>>> have had cause in the past to return null or empty strings specifically
>>> because of this check and that toString() is regularly central to
>>> rendering
>>> objects. While it cannot guarantee emptiness for every object out there,
>>> it
>>> is a sensible check. The goal here is not perfection, but to catch common
>>> cases, and due to history, i believe this is a common one.
>>>
>>
>> Again, there might be cases this is necessary though I cannot make up one
>> from the top of my head. I am just saying that this should not be a default
>> setting and people must know what they enable at the end.
>
>
> My concern was backward compatibility, which, while not necessary, is still
> quite valuable. There are existing VelocityTools that rely on this, after
> all. Given all the ways to avoid getting to this check, i don't see the
> compelling reason to toggle the default here. Though, as always, i will
> defer to those doing actual work right now. :) Just chiming in with my two
> bits.

This is a new major release (!) for a for period of time, approaches 
chang, so should software. We shall take the freedom and do the right 
step forward. After all, people don't like surprises if the world keeps 
revolving and you don't move with it.


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

Re: Velocity truth

[Nathan Bubna <nb...@gmail.com>]

On Mon, Feb 6, 2017 at 10:32 AM, Michael Osipov <mi...@apache.org> wrote:

> Am 2017-02-06 um 19:23 schrieb Nathan Bubna:
>
>> On Mon, Feb 6, 2017 at 9:43 AM, Michael Osipov <mi...@apache.org>
>> wrote:
>>
>>> 7) check object for a length() or size() method, if so return whether it
>>>
>>>> returns 0, but I agree with Alex Fedotov that we could skip those
>>>> methods if we already took care for strings and collections.
>>>>
>>>>
>>> What happened to array#length? You completely missed that out.
>>> I would not drop #length() and #size(), you'd ultimately fail with
>>> javax.naming.directory.Attribute#size() or
>>> javax.naming.directory.Attributes#size().
>>> There are likely more examples to have this.
>>>
>>
>>
>> i don't think it hurts to keep them, most users won't often get that far,
>> i
>> think.
>>
>
> I did not say we should drop them, I said that they are crucial in some
> situations. Dropping them would be wrong.



Yup. I was agreeing. :)


> 8) If directive.if.tostring.check = false, stop here and return true (*)
>>
>>>
>>>> 9) check object for a toString() method, and return whether the string
>>>> is non-null and non-empty
>>>>
>>>> The 6th step won't be reached very often...
>>>>
>>>> (*) the old configuration parameter was directive.if.tostring.nullchec
>>>> k,
>>>> but for consistency with the new behavior regarding empty strings, my
>>>> proposal is to rename it like this. I don't consider that backward
>>>> compatibility is important since all collections are handled above in
>>>> the chain.
>>>>
>>>>
>>> 9) is somewhat confusing because #toString() is never null unless you
>>> override it and return a custom string. Moreover, how will a #toString()
>>> guarantee you that an object is logically empty? It can't, see
>>> javax.naming.directory.SearchResult#getAttributes().
>>>
>>> At best, this would be false by default in 2.0.
>>>
>>
>> ...
>>
>> I still back this check. Velocity is for templating, text output, i.e. a
>> display language. Velocity-specific classes (including some VelocityTools)
>> have had cause in the past to return null or empty strings specifically
>> because of this check and that toString() is regularly central to
>> rendering
>> objects. While it cannot guarantee emptiness for every object out there,
>> it
>> is a sensible check. The goal here is not perfection, but to catch common
>> cases, and due to history, i believe this is a common one.
>>
>
> Again, there might be cases this is necessary though I cannot make up one
> from the top of my head. I am just saying that this should not be a default
> setting and people must know what they enable at the end.


My concern was backward compatibility, which, while not necessary, is still
quite valuable. There are existing VelocityTools that rely on this, after
all. Given all the ways to avoid getting to this check, i don't see the
compelling reason to toggle the default here. Though, as always, i will
defer to those doing actual work right now. :) Just chiming in with my two
bits.

Re: Velocity truth

[Michael Osipov <mi...@apache.org>]

Am 2017-02-06 um 19:23 schrieb Nathan Bubna:
> On Mon, Feb 6, 2017 at 9:43 AM, Michael Osipov <mi...@apache.org> wrote:
>> 7) check object for a length() or size() method, if so return whether it
>>> returns 0, but I agree with Alex Fedotov that we could skip those
>>> methods if we already took care for strings and collections.
>>>
>>
>> What happened to array#length? You completely missed that out.
>> I would not drop #length() and #size(), you'd ultimately fail with
>> javax.naming.directory.Attribute#size() or javax.naming.directory.Attributes#size().
>> There are likely more examples to have this.
>
>
> i don't think it hurts to keep them, most users won't often get that far, i
> think.

I did not say we should drop them, I said that they are crucial in some 
situations. Dropping them would be wrong.

> 8) If directive.if.tostring.check = false, stop here and return true (*)
>>>
>>> 9) check object for a toString() method, and return whether the string
>>> is non-null and non-empty
>>>
>>> The 6th step won't be reached very often...
>>>
>>> (*) the old configuration parameter was directive.if.tostring.nullcheck,
>>> but for consistency with the new behavior regarding empty strings, my
>>> proposal is to rename it like this. I don't consider that backward
>>> compatibility is important since all collections are handled above in
>>> the chain.
>>>
>>
>> 9) is somewhat confusing because #toString() is never null unless you
>> override it and return a custom string. Moreover, how will a #toString()
>> guarantee you that an object is logically empty? It can't, see
>> javax.naming.directory.SearchResult#getAttributes().
>>
>> At best, this would be false by default in 2.0.
>
> ...
>
> I still back this check. Velocity is for templating, text output, i.e. a
> display language. Velocity-specific classes (including some VelocityTools)
> have had cause in the past to return null or empty strings specifically
> because of this check and that toString() is regularly central to rendering
> objects. While it cannot guarantee emptiness for every object out there, it
> is a sensible check. The goal here is not perfection, but to catch common
> cases, and due to history, i believe this is a common one.

Again, there might be cases this is necessary though I cannot make up 
one from the top of my head. I am just saying that this should not be a 
default setting and people must know what they enable at the end.

Michael


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

Re: Velocity truth

[Nathan Bubna <nb...@gmail.com>]

On Mon, Feb 6, 2017 at 9:43 AM, Michael Osipov <mi...@apache.org> wrote:
...

> 4) check for empty objects by class:
>>   - return whether the collection is empty for a Collection object
>>
>> 5) check object for an isEmpty() method, if so return whether it
>> returned false
>>
>
> Why explicitly check for collection if you do #isEmpty()?
> I'd either add Map to the explicit check or drop collection altogether and
> rely on #isEmpty() solely.


makes sense to me.


> 7) check object for a length() or size() method, if so return whether it
>> returns 0, but I agree with Alex Fedotov that we could skip those
>> methods if we already took care for strings and collections.
>>
>
> What happened to array#length? You completely missed that out.
> I would not drop #length() and #size(), you'd ultimately fail with
> javax.naming.directory.Attribute#size() or javax.naming.directory.Attributes#size().
> There are likely more examples to have this.


i don't think it hurts to keep them, most users won't often get that far, i
think.

8) If directive.if.tostring.check = false, stop here and return true (*)
>>
>> 9) check object for a toString() method, and return whether the string
>> is non-null and non-empty
>>
>> The 6th step won't be reached very often...
>>
>> (*) the old configuration parameter was directive.if.tostring.nullcheck,
>> but for consistency with the new behavior regarding empty strings, my
>> proposal is to rename it like this. I don't consider that backward
>> compatibility is important since all collections are handled above in
>> the chain.
>>
>
> 9) is somewhat confusing because #toString() is never null unless you
> override it and return a custom string. Moreover, how will a #toString()
> guarantee you that an object is logically empty? It can't, see
> javax.naming.directory.SearchResult#getAttributes().
>
> At best, this would be false by default in 2.0.

...

I still back this check. Velocity is for templating, text output, i.e. a
display language. Velocity-specific classes (including some VelocityTools)
have had cause in the past to return null or empty strings specifically
because of this check and that toString() is regularly central to rendering
objects. While it cannot guarantee emptiness for every object out there, it
is a sensible check. The goal here is not perfection, but to catch common
cases, and due to history, i believe this is a common one.

Re: Velocity truth

[Michael Osipov <mi...@apache.org>]

Hi Claude,

Am 2017-02-06 um 17:55 schrieb Claude Brisson:
> Hi Christopher.
>
> The spec has evolved quite a bit since then: the course I've taken is
> this one (and remarks are welcome):
>
> 4) check for empty objects by class:
>   - return whether the collection is empty for a Collection object
>
> 5) check object for an isEmpty() method, if so return whether it
> returned false

Why explicitly check for collection if you do #isEmpty()?
I'd either add Map to the explicit check or drop collection altogether 
and rely on #isEmpty() solely.

> 7) check object for a length() or size() method, if so return whether it
> returns 0, but I agree with Alex Fedotov that we could skip those
> methods if we already took care for strings and collections.

What happened to array#length? You completely missed that out.
I would not drop #length() and #size(), you'd ultimately fail with 
javax.naming.directory.Attribute#size() or 
javax.naming.directory.Attributes#size(). There are likely more examples 
to have this.

> 8) If directive.if.tostring.check = false, stop here and return true (*)
>
> 9) check object for a toString() method, and return whether the string
> is non-null and non-empty
>
> The 6th step won't be reached very often...
>
> (*) the old configuration parameter was directive.if.tostring.nullcheck,
> but for consistency with the new behavior regarding empty strings, my
> proposal is to rename it like this. I don't consider that backward
> compatibility is important since all collections are handled above in
> the chain.

9) is somewhat confusing because #toString() is never null unless you 
override it and return a custom string. Moreover, how will a #toString() 
guarantee you that an object is logically empty? It can't, see 
javax.naming.directory.SearchResult#getAttributes().

At best, this would be false by default in 2.0.

Michael

> On 06/02/2017 16:48, Christopher Schultz wrote:
>> Claude,
>>
>> On 1/28/17 10:15 AM, Claude Brisson wrote:
>>> Here's what had been specified by Nathan at the time (order is
>>> meaningful, and falseness seems easier to specify than truth):
>>>
>>> $obj is null
>>> $obj is boolean false
>>> $obj returns false from getAsBoolean() (provided there is such a method)
>>> $obj is empty string (CharSequence w/length 0)
>>> $obj returns true from isEmpty() (provided there is such a method)
>>> $obj is array of length 0
>>> $obj returns null from getAsString() (provided there is such a method)
>>> $obj returns empty string from getAsString() (provided there is such a
>>> method)
>>> $obj returns null from getAsNumber() (provided there is such a method)
>>> $obj returns 0 from length() or size() (provided there is such a method)
>>> $obj returns empty string from toString() (provided there is such a
>>> method)
>> I *hate* that last one. A great use-case that ran us into OOMEs for a
>> while until I figured out what was going on:
>>
>> 1. SELECT [fields] FROM table
>> 2. Build ArrayList with e.g. User objects
>> 3. Build a user list in HTML from a Velocity template like this:
>>
>> #if($users)
>>    <table>
>>      #foreach($user in $users)
>>        ...
>>      #end
>>    </table>
>> #else
>>    No users found :()
>> #end
>>
>> This gives me horrible performance and an OOME when the list gets too
>> long, because the check for #if($users) truthiness converts the whole
>> list collection into a String (which takes forever) which can be huge
>> (which can cause OOME).
>>
>> I have now set the "directive.if.tostring.nullcheck=false" configuration
>> property (and written a set of wrapper classes around Collection classes
>> that throws an exception when toString is called, so things fail in
>> development) to avoid this, but also taken to using this check instead:
>>
>> #if($users.size() > 0)
>>
>> But this gets me a warning about the "size" method not existing on a
>> null object when the list is null. So I get junk in my logs when I do
>> things the hacky-way and I get performance problems and OOMEs when I do
>> things the "correct" way (at least, it looks totally correct).
>>
>>> Regarding this spec:
>>>   - I'm not sure about getAsString() ; toString() is usually the
>>> standard
>>> way of getting the String representation and should be enough.
>>>   - I'm not convinced by the fact that zero should be true. I hear
>>> Nathan's point that for a display language, zero is as legitimate as any
>>> other number to be displayed. But it breaks the principle of least
>>> surprise, since each and every other language around, when not
>>> forbidding number towards boolean implicit conversion, consider zero as
>>> false.
>>>
>>> So I'd rather go with:
>>>
>>> $obj is null
>>> $obj is Boolean false
>>> $obj is Number zero (whatever Number variant)
>> For floating point values, does this have to be *zero*, or just close
>> enough to zero?
>>
>>> $obj returns false from getAsBoolean() (provided there is such a method)
>>> $obj is empty string (CharSequence w/length 0)
>>> $obj returns true from isEmpty() (provided there is such a method)
>>> $obj is array of length 0
>>> $obj returns null from getAsNumber() (provided there is such a method)
>>> $obj returns 0 from length() or size() (provided there is such a method)
>>> $obj returns empty string from toString() (provided there is such a
>>> method)
>>>
>>> Also, I noticed that Velocity weren't very consistent with literals. The
>>> only literal returning true is the 'true' literal. "foo" is false,
>>> whereas it should be consistent with $foo containing "foo".
>> Can we maybe make an exception for Collections? Maybe for a Collection
>> (or array), we never call toString() on it? [].toString will always give
>> you garbage (which will be truthy) and Collection.toString() will also
>> likely give you garbage and it will also always be truthy unless it's
>> (a) null or (b) the Collection implements toString in a surprising way
>> relative to java.util Collections.
>>
>> -chris
>>
>
>
> ---------------------------------------------------------------------
> 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: Velocity truth

[Claude Brisson <cl...@renegat.net>]

Hi Christopher.

The spec has evolved quite a bit since then: the course I've taken is 
this one (and remarks are welcome):

1) return false for a null object

2) return its value for a Boolean object, or the result of the 
getAsBoolean() method if it exists.

3) If directive.if.emptycheck = false, stop here and return true.

4) check for empty objects by class:
   - return whether the number *strictly* equals zero for a Number object
   - return whether the string is empty for a CharSequence object
   - return whether the collection is empty for a Collection object

5) check object for an isEmpty() method, if so return whether it 
returned false

6) check object for explicit conversion methods:
   - return the result of getAsBoolean() (and false for a null result) 
if it exists
   - return whether the result of getAsNumber() *strictly* equals zero 
(and false for a null result) if it exists
   - return whether the result of getAsString() is empty (and false for 
a null result) if it exists

7) check object for a length() or size() method, if so return whether it 
returns 0, but I agree with Alex Fedotov that we could skip those 
methods if we already took care for strings and collections.

8) If directive.if.tostring.check = false, stop here and return true (*)

9) check object for a toString() method, and return whether the string 
is non-null and non-empty

The 6th step won't be reached very often...

(*) the old configuration parameter was directive.if.tostring.nullcheck, 
but for consistency with the new behavior regarding empty strings, my 
proposal is to rename it like this. I don't consider that backward 
compatibility is important since all collections are handled above in 
the chain.


   Claude


On 06/02/2017 16:48, Christopher Schultz wrote:
> Claude,
>
> On 1/28/17 10:15 AM, Claude Brisson wrote:
>> Here's what had been specified by Nathan at the time (order is
>> meaningful, and falseness seems easier to specify than truth):
>>
>> $obj is null
>> $obj is boolean false
>> $obj returns false from getAsBoolean() (provided there is such a method)
>> $obj is empty string (CharSequence w/length 0)
>> $obj returns true from isEmpty() (provided there is such a method)
>> $obj is array of length 0
>> $obj returns null from getAsString() (provided there is such a method)
>> $obj returns empty string from getAsString() (provided there is such a
>> method)
>> $obj returns null from getAsNumber() (provided there is such a method)
>> $obj returns 0 from length() or size() (provided there is such a method)
>> $obj returns empty string from toString() (provided there is such a method)
> I *hate* that last one. A great use-case that ran us into OOMEs for a
> while until I figured out what was going on:
>
> 1. SELECT [fields] FROM table
> 2. Build ArrayList with e.g. User objects
> 3. Build a user list in HTML from a Velocity template like this:
>
> #if($users)
>    <table>
>      #foreach($user in $users)
>        ...
>      #end
>    </table>
> #else
>    No users found :()
> #end
>
> This gives me horrible performance and an OOME when the list gets too
> long, because the check for #if($users) truthiness converts the whole
> list collection into a String (which takes forever) which can be huge
> (which can cause OOME).
>
> I have now set the "directive.if.tostring.nullcheck=false" configuration
> property (and written a set of wrapper classes around Collection classes
> that throws an exception when toString is called, so things fail in
> development) to avoid this, but also taken to using this check instead:
>
> #if($users.size() > 0)
>
> But this gets me a warning about the "size" method not existing on a
> null object when the list is null. So I get junk in my logs when I do
> things the hacky-way and I get performance problems and OOMEs when I do
> things the "correct" way (at least, it looks totally correct).
>
>> Regarding this spec:
>>   - I'm not sure about getAsString() ; toString() is usually the standard
>> way of getting the String representation and should be enough.
>>   - I'm not convinced by the fact that zero should be true. I hear
>> Nathan's point that for a display language, zero is as legitimate as any
>> other number to be displayed. But it breaks the principle of least
>> surprise, since each and every other language around, when not
>> forbidding number towards boolean implicit conversion, consider zero as
>> false.
>>
>> So I'd rather go with:
>>
>> $obj is null
>> $obj is Boolean false
>> $obj is Number zero (whatever Number variant)
> For floating point values, does this have to be *zero*, or just close
> enough to zero?
>
>> $obj returns false from getAsBoolean() (provided there is such a method)
>> $obj is empty string (CharSequence w/length 0)
>> $obj returns true from isEmpty() (provided there is such a method)
>> $obj is array of length 0
>> $obj returns null from getAsNumber() (provided there is such a method)
>> $obj returns 0 from length() or size() (provided there is such a method)
>> $obj returns empty string from toString() (provided there is such a method)
>>
>> Also, I noticed that Velocity weren't very consistent with literals. The
>> only literal returning true is the 'true' literal. "foo" is false,
>> whereas it should be consistent with $foo containing "foo".
> Can we maybe make an exception for Collections? Maybe for a Collection
> (or array), we never call toString() on it? [].toString will always give
> you garbage (which will be truthy) and Collection.toString() will also
> likely give you garbage and it will also always be truthy unless it's
> (a) null or (b) the Collection implements toString in a surprising way
> relative to java.util Collections.
>
> -chris
>


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

Re: Velocity truth

[Alex Fedotov <al...@kayak.com>]

I would try to something similar to Javascript convention
https://javascriptweblog.wordpress.com/2011/02/07/truth-equality-and-javascript/
substituting CharSequence instead of String (so that other empty String
like objects i.e. StringBuilder would evaluate as false) and also treating
empty arrays and collections as "false".

Not sure if Duck typing for methods like isEmpty(), length() or size() is
really necessary, could just support BooleanSupplier interface for custom
conversions. All other cases would be covered by collections and arrays.

Alex


On Mon, Feb 6, 2017 at 10:48 AM, Christopher Schultz <
chris@christopherschultz.net> wrote:

> Claude,
>
> On 1/28/17 10:15 AM, Claude Brisson wrote:
> > Here's what had been specified by Nathan at the time (order is
> > meaningful, and falseness seems easier to specify than truth):
> >
> > $obj is null
> > $obj is boolean false
> > $obj returns false from getAsBoolean() (provided there is such a method)
> > $obj is empty string (CharSequence w/length 0)
> > $obj returns true from isEmpty() (provided there is such a method)
> > $obj is array of length 0
> > $obj returns null from getAsString() (provided there is such a method)
> > $obj returns empty string from getAsString() (provided there is such a
> > method)
> > $obj returns null from getAsNumber() (provided there is such a method)
> > $obj returns 0 from length() or size() (provided there is such a method)
> > $obj returns empty string from toString() (provided there is such a
> method)
>
> I *hate* that last one. A great use-case that ran us into OOMEs for a
> while until I figured out what was going on:
>
> 1. SELECT [fields] FROM table
> 2. Build ArrayList with e.g. User objects
> 3. Build a user list in HTML from a Velocity template like this:
>
> #if($users)
>   <table>
>     #foreach($user in $users)
>       ...
>     #end
>   </table>
> #else
>   No users found :()
> #end
>
> This gives me horrible performance and an OOME when the list gets too
> long, because the check for #if($users) truthiness converts the whole
> list collection into a String (which takes forever) which can be huge
> (which can cause OOME).
>
> I have now set the "directive.if.tostring.nullcheck=false" configuration
> property (and written a set of wrapper classes around Collection classes
> that throws an exception when toString is called, so things fail in
> development) to avoid this, but also taken to using this check instead:
>
> #if($users.size() > 0)
>
> But this gets me a warning about the "size" method not existing on a
> null object when the list is null. So I get junk in my logs when I do
> things the hacky-way and I get performance problems and OOMEs when I do
> things the "correct" way (at least, it looks totally correct).
>
> > Regarding this spec:
> >  - I'm not sure about getAsString() ; toString() is usually the standard
> > way of getting the String representation and should be enough.
> >  - I'm not convinced by the fact that zero should be true. I hear
> > Nathan's point that for a display language, zero is as legitimate as any
> > other number to be displayed. But it breaks the principle of least
> > surprise, since each and every other language around, when not
> > forbidding number towards boolean implicit conversion, consider zero as
> > false.
> >
> > So I'd rather go with:
> >
> > $obj is null
> > $obj is Boolean false
> > $obj is Number zero (whatever Number variant)
>
> For floating point values, does this have to be *zero*, or just close
> enough to zero?
>
> > $obj returns false from getAsBoolean() (provided there is such a method)
> > $obj is empty string (CharSequence w/length 0)
> > $obj returns true from isEmpty() (provided there is such a method)
> > $obj is array of length 0
> > $obj returns null from getAsNumber() (provided there is such a method)
> > $obj returns 0 from length() or size() (provided there is such a method)
> > $obj returns empty string from toString() (provided there is such a
> method)
> >
> > Also, I noticed that Velocity weren't very consistent with literals. The
> > only literal returning true is the 'true' literal. "foo" is false,
> > whereas it should be consistent with $foo containing "foo".
>
> Can we maybe make an exception for Collections? Maybe for a Collection
> (or array), we never call toString() on it? [].toString will always give
> you garbage (which will be truthy) and Collection.toString() will also
> likely give you garbage and it will also always be truthy unless it's
> (a) null or (b) the Collection implements toString in a surprising way
> relative to java.util Collections.
>
> -chris
>
>

Re: Velocity truth

[Nathan Bubna <nb...@gmail.com>]

On Mon, Feb 6, 2017 at 7:48 AM, Christopher Schultz <
chris@christopherschultz.net> wrote:

> Claude,

...

> > $obj returns false from getAsBoolean() (provided there is such a method)
>
> $obj is empty string (CharSequence w/length 0)
> > $obj returns true from isEmpty() (provided there is such a method)
> > $obj is array of length 0
> > $obj returns null from getAsNumber() (provided there is such a method)
> > $obj returns 0 from length() or size() (provided there is such a method)
> > $obj returns empty string from toString() (provided there is such a
> method)
> >
> > Also, I noticed that Velocity weren't very consistent with literals. The
> > only literal returning true is the 'true' literal. "foo" is false,
> > whereas it should be consistent with $foo containing "foo".
>
> Can we maybe make an exception for Collections? Maybe for a Collection
> (or array), we never call toString() on it? [].toString will always give
> you garbage (which will be truthy) and Collection.toString() will also
> likely give you garbage and it will also always be truthy unless it's
> (a) null or (b) the Collection implements toString in a surprising way
> relative to java.util Collections.
>
...

Yeah, one of the crucial ideas here is that Velocity would stop checking as
soon as it found one of these. So no Array, CharSequence, or Collection
would ever make it down the lookup chain to toString(). The goal is to be
more type/function aware specifically to avoid getting down to the
toString(), but still leaving that toString() check for better backward
compatibility.

Re: Velocity truth

[Christopher Schultz <ch...@christopherschultz.net>]

Claude,

On 1/28/17 10:15 AM, Claude Brisson wrote:
> Here's what had been specified by Nathan at the time (order is
> meaningful, and falseness seems easier to specify than truth):
> 
> $obj is null
> $obj is boolean false
> $obj returns false from getAsBoolean() (provided there is such a method)
> $obj is empty string (CharSequence w/length 0)
> $obj returns true from isEmpty() (provided there is such a method)
> $obj is array of length 0
> $obj returns null from getAsString() (provided there is such a method)
> $obj returns empty string from getAsString() (provided there is such a
> method)
> $obj returns null from getAsNumber() (provided there is such a method)
> $obj returns 0 from length() or size() (provided there is such a method)
> $obj returns empty string from toString() (provided there is such a method)

I *hate* that last one. A great use-case that ran us into OOMEs for a
while until I figured out what was going on:

1. SELECT [fields] FROM table
2. Build ArrayList with e.g. User objects
3. Build a user list in HTML from a Velocity template like this:

#if($users)
  <table>
    #foreach($user in $users)
      ...
    #end
  </table>
#else
  No users found :()
#end

This gives me horrible performance and an OOME when the list gets too
long, because the check for #if($users) truthiness converts the whole
list collection into a String (which takes forever) which can be huge
(which can cause OOME).

I have now set the "directive.if.tostring.nullcheck=false" configuration
property (and written a set of wrapper classes around Collection classes
that throws an exception when toString is called, so things fail in
development) to avoid this, but also taken to using this check instead:

#if($users.size() > 0)

But this gets me a warning about the "size" method not existing on a
null object when the list is null. So I get junk in my logs when I do
things the hacky-way and I get performance problems and OOMEs when I do
things the "correct" way (at least, it looks totally correct).

> Regarding this spec:
>  - I'm not sure about getAsString() ; toString() is usually the standard
> way of getting the String representation and should be enough.
>  - I'm not convinced by the fact that zero should be true. I hear
> Nathan's point that for a display language, zero is as legitimate as any
> other number to be displayed. But it breaks the principle of least
> surprise, since each and every other language around, when not
> forbidding number towards boolean implicit conversion, consider zero as
> false.
> 
> So I'd rather go with:
> 
> $obj is null
> $obj is Boolean false
> $obj is Number zero (whatever Number variant)

For floating point values, does this have to be *zero*, or just close
enough to zero?

> $obj returns false from getAsBoolean() (provided there is such a method)
> $obj is empty string (CharSequence w/length 0)
> $obj returns true from isEmpty() (provided there is such a method)
> $obj is array of length 0
> $obj returns null from getAsNumber() (provided there is such a method)
> $obj returns 0 from length() or size() (provided there is such a method)
> $obj returns empty string from toString() (provided there is such a method)
> 
> Also, I noticed that Velocity weren't very consistent with literals. The
> only literal returning true is the 'true' literal. "foo" is false,
> whereas it should be consistent with $foo containing "foo".

Can we maybe make an exception for Collections? Maybe for a Collection
(or array), we never call toString() on it? [].toString will always give
you garbage (which will be truthy) and Collection.toString() will also
likely give you garbage and it will also always be truthy unless it's
(a) null or (b) the Collection implements toString in a surprising way
relative to java.util Collections.

-chris

Re: Velocity truth (was: Re: [ANNOUNCE] Velocity Engine 2.0 RC6 test build available)

[Alex Fedotov <al...@kayak.com>]

I guess I was not clear enough.

This option does indeed exist in 1.7. I just wanted to make sure it does
not get dropped in 2.0 as part of the cleanup work.

Alex


On Mon, Jan 30, 2017 at 4:04 PM, Nathan Bubna <nb...@gmail.com> wrote:

> On Mon, Jan 30, 2017 at 12:51 PM, Nathan Bubna <nb...@gmail.com> wrote:
>
> > On Sat, Jan 28, 2017 at 11:23 AM, Alex Fedotov <al...@kayak.com> wrote:
> >
> >> You guys should definitely leave a way of disabling the toString()
> >> conversion in boolean expressions.
> >>
> >
> > Seems reasonable, and also familiar; this may have been discussed before.
> >
>
> Oh, yes, and built. I knew this was familiar. :)
>
> See http://velocity.apache.org/engine/2.0/configuration.html :
>
> directive.if.tostring.nullcheck = true
>
>
> >
> >> There are many places where people do null checks if #if($obj)...#end.
> >>
> >> Classes almost never return an empty string or null string from the
> >> toString  call. Even worse some classes may use toString for debugging
> >> purposes and produce very long  strings (including nested objects,
> etc.).
> >> In the code above that would be a huge inefficiency.
> >>
> >
> > Yes, that's part of the motive to have this lookup chain. If there's a
> > match higher up, toString() is avoided. Big deal for maps and arrays.
> >
> >
> >>
> >> Alex
> >>
> >> On Sat, Jan 28, 2017 at 2:06 PM, Nathan Bubna <nb...@gmail.com> wrote:
> >>
> >> > Shame that i can't remember anymore all my reasons for wanting those
> >> > "getAs<Type>" lookups. Wondering why getAsNumber and getAsBoolean are
> >> here
> >> > too. Anyone else recall the use case? And assuming that i had good
> >> reason
> >> > (that did happen sometimes <grin>), i wonder why i pushed for bucking
> >> the
> >> > "to<Type>()" convention.
> >> >
> >> > As for the literals, the thought of them being used in #if statements
> >> in a
> >> > template language is cringe-inducing. What's the use-case? Temporary
> >> > debugging hacks? If so, part of me thinks maybe only 'true' should
> even
> >> be
> >> > allowed.
> >> >
> >> > On Sat, Jan 28, 2017 at 7:15 AM, Claude Brisson <cl...@renegat.net>
> >> > wrote:
> >> >
> >> > >
> >> > >
> >> > >>>> What is the problem?
> >> > >>>>
> >> > >>>> Velocity "truthiness":
> >> > >>> https://issues.apache.org/jira/browse/VELOCITY-692
> >> > >>>
> >> > >>> It should definitely be part of 2.0. I missed it because the issue
> >> was
> >> > >>> closed, we should have opened a 2.0 one to remember it.
> >> > >>>
> >> > >>
> >> > >> Thats's the problem if a closed/resolved issue does not have an
> >> > >> assignee. You never know who handled it without reading the entire
> >> > >> thread. A ticket should always have an assignee if code has been
> >> > changed.
> >> > >>
> >> > >>
> >> > > Here's what had been specified by Nathan at the time (order is
> >> > meaningful,
> >> > > and falseness seems easier to specify than truth):
> >> > >
> >> > > $obj is null
> >> > > $obj is boolean false
> >> > > $obj returns false from getAsBoolean() (provided there is such a
> >> method)
> >> > > $obj is empty string (CharSequence w/length 0)
> >> > > $obj returns true from isEmpty() (provided there is such a method)
> >> > > $obj is array of length 0
> >> > > $obj returns null from getAsString() (provided there is such a
> method)
> >> > > $obj returns empty string from getAsString() (provided there is
> such a
> >> > > method)
> >> > > $obj returns null from getAsNumber() (provided there is such a
> method)
> >> > > $obj returns 0 from length() or size() (provided there is such a
> >> method)
> >> > > $obj returns empty string from toString() (provided there is such a
> >> > method)
> >> > >
> >> > > Regarding this spec:
> >> > >  - I'm not sure about getAsString() ; toString() is usually the
> >> standard
> >> > > way of getting the String representation and should be enough.
> >> > >  - I'm not convinced by the fact that zero should be true. I hear
> >> > Nathan's
> >> > > point that for a display language, zero is as legitimate as any
> other
> >> > > number to be displayed. But it breaks the principle of least
> surprise,
> >> > > since each and every other language around, when not forbidding
> number
> >> > > towards boolean implicit conversion, consider zero as false.
> >> > >
> >> > > So I'd rather go with:
> >> > >
> >> > > $obj is null
> >> > > $obj is Boolean false
> >> > > $obj is Number zero (whatever Number variant)
> >> > > $obj returns false from getAsBoolean() (provided there is such a
> >> method)
> >> > > $obj is empty string (CharSequence w/length 0)
> >> > > $obj returns true from isEmpty() (provided there is such a method)
> >> > > $obj is array of length 0
> >> > > $obj returns null from getAsNumber() (provided there is such a
> method)
> >> > > $obj returns 0 from length() or size() (provided there is such a
> >> method)
> >> > > $obj returns empty string from toString() (provided there is such a
> >> > method)
> >> > >
> >> > > Also, I noticed that Velocity weren't very consistent with literals.
> >> The
> >> > > only literal returning true is the 'true' literal. "foo" is false,
> >> > whereas
> >> > > it should be consistent with $foo containing "foo".
> >> > >
> >> > >   Claude
> >> > >
> >> > >
> >> > > ------------------------------------------------------------
> ---------
> >> > > To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org
> >> > > For additional commands, e-mail: dev-help@velocity.apache.org
> >> > >
> >> > >
> >> >
> >>
> >
> >
>

Re: Velocity truth (was: Re: [ANNOUNCE] Velocity Engine 2.0 RC6 test build available)

[Nathan Bubna <nb...@gmail.com>]

On Mon, Jan 30, 2017 at 12:51 PM, Nathan Bubna <nb...@gmail.com> wrote:

> On Sat, Jan 28, 2017 at 11:23 AM, Alex Fedotov <al...@kayak.com> wrote:
>
>> You guys should definitely leave a way of disabling the toString()
>> conversion in boolean expressions.
>>
>
> Seems reasonable, and also familiar; this may have been discussed before.
>

Oh, yes, and built. I knew this was familiar. :)

See http://velocity.apache.org/engine/2.0/configuration.html :

directive.if.tostring.nullcheck = true


>
>> There are many places where people do null checks if #if($obj)...#end.
>>
>> Classes almost never return an empty string or null string from the
>> toString  call. Even worse some classes may use toString for debugging
>> purposes and produce very long  strings (including nested objects, etc.).
>> In the code above that would be a huge inefficiency.
>>
>
> Yes, that's part of the motive to have this lookup chain. If there's a
> match higher up, toString() is avoided. Big deal for maps and arrays.
>
>
>>
>> Alex
>>
>> On Sat, Jan 28, 2017 at 2:06 PM, Nathan Bubna <nb...@gmail.com> wrote:
>>
>> > Shame that i can't remember anymore all my reasons for wanting those
>> > "getAs<Type>" lookups. Wondering why getAsNumber and getAsBoolean are
>> here
>> > too. Anyone else recall the use case? And assuming that i had good
>> reason
>> > (that did happen sometimes <grin>), i wonder why i pushed for bucking
>> the
>> > "to<Type>()" convention.
>> >
>> > As for the literals, the thought of them being used in #if statements
>> in a
>> > template language is cringe-inducing. What's the use-case? Temporary
>> > debugging hacks? If so, part of me thinks maybe only 'true' should even
>> be
>> > allowed.
>> >
>> > On Sat, Jan 28, 2017 at 7:15 AM, Claude Brisson <cl...@renegat.net>
>> > wrote:
>> >
>> > >
>> > >
>> > >>>> What is the problem?
>> > >>>>
>> > >>>> Velocity "truthiness":
>> > >>> https://issues.apache.org/jira/browse/VELOCITY-692
>> > >>>
>> > >>> It should definitely be part of 2.0. I missed it because the issue
>> was
>> > >>> closed, we should have opened a 2.0 one to remember it.
>> > >>>
>> > >>
>> > >> Thats's the problem if a closed/resolved issue does not have an
>> > >> assignee. You never know who handled it without reading the entire
>> > >> thread. A ticket should always have an assignee if code has been
>> > changed.
>> > >>
>> > >>
>> > > Here's what had been specified by Nathan at the time (order is
>> > meaningful,
>> > > and falseness seems easier to specify than truth):
>> > >
>> > > $obj is null
>> > > $obj is boolean false
>> > > $obj returns false from getAsBoolean() (provided there is such a
>> method)
>> > > $obj is empty string (CharSequence w/length 0)
>> > > $obj returns true from isEmpty() (provided there is such a method)
>> > > $obj is array of length 0
>> > > $obj returns null from getAsString() (provided there is such a method)
>> > > $obj returns empty string from getAsString() (provided there is such a
>> > > method)
>> > > $obj returns null from getAsNumber() (provided there is such a method)
>> > > $obj returns 0 from length() or size() (provided there is such a
>> method)
>> > > $obj returns empty string from toString() (provided there is such a
>> > method)
>> > >
>> > > Regarding this spec:
>> > >  - I'm not sure about getAsString() ; toString() is usually the
>> standard
>> > > way of getting the String representation and should be enough.
>> > >  - I'm not convinced by the fact that zero should be true. I hear
>> > Nathan's
>> > > point that for a display language, zero is as legitimate as any other
>> > > number to be displayed. But it breaks the principle of least surprise,
>> > > since each and every other language around, when not forbidding number
>> > > towards boolean implicit conversion, consider zero as false.
>> > >
>> > > So I'd rather go with:
>> > >
>> > > $obj is null
>> > > $obj is Boolean false
>> > > $obj is Number zero (whatever Number variant)
>> > > $obj returns false from getAsBoolean() (provided there is such a
>> method)
>> > > $obj is empty string (CharSequence w/length 0)
>> > > $obj returns true from isEmpty() (provided there is such a method)
>> > > $obj is array of length 0
>> > > $obj returns null from getAsNumber() (provided there is such a method)
>> > > $obj returns 0 from length() or size() (provided there is such a
>> method)
>> > > $obj returns empty string from toString() (provided there is such a
>> > method)
>> > >
>> > > Also, I noticed that Velocity weren't very consistent with literals.
>> The
>> > > only literal returning true is the 'true' literal. "foo" is false,
>> > whereas
>> > > it should be consistent with $foo containing "foo".
>> > >
>> > >   Claude
>> > >
>> > >
>> > > ---------------------------------------------------------------------
>> > > To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org
>> > > For additional commands, e-mail: dev-help@velocity.apache.org
>> > >
>> > >
>> >
>>
>
>

Re: Velocity truth (was: Re: [ANNOUNCE] Velocity Engine 2.0 RC6 test build available)

[Nathan Bubna <nb...@gmail.com>]

On Sat, Jan 28, 2017 at 11:23 AM, Alex Fedotov <al...@kayak.com> wrote:

> You guys should definitely leave a way of disabling the toString()
> conversion in boolean expressions.
>

Seems reasonable, and also familiar; this may have been discussed before.


> There are many places where people do null checks if #if($obj)...#end.
>
> Classes almost never return an empty string or null string from the
> toString  call. Even worse some classes may use toString for debugging
> purposes and produce very long  strings (including nested objects, etc.).
> In the code above that would be a huge inefficiency.
>

Yes, that's part of the motive to have this lookup chain. If there's a
match higher up, toString() is avoided. Big deal for maps and arrays.


>
> Alex
>
> On Sat, Jan 28, 2017 at 2:06 PM, Nathan Bubna <nb...@gmail.com> wrote:
>
> > Shame that i can't remember anymore all my reasons for wanting those
> > "getAs<Type>" lookups. Wondering why getAsNumber and getAsBoolean are
> here
> > too. Anyone else recall the use case? And assuming that i had good reason
> > (that did happen sometimes <grin>), i wonder why i pushed for bucking the
> > "to<Type>()" convention.
> >
> > As for the literals, the thought of them being used in #if statements in
> a
> > template language is cringe-inducing. What's the use-case? Temporary
> > debugging hacks? If so, part of me thinks maybe only 'true' should even
> be
> > allowed.
> >
> > On Sat, Jan 28, 2017 at 7:15 AM, Claude Brisson <cl...@renegat.net>
> > wrote:
> >
> > >
> > >
> > >>>> What is the problem?
> > >>>>
> > >>>> Velocity "truthiness":
> > >>> https://issues.apache.org/jira/browse/VELOCITY-692
> > >>>
> > >>> It should definitely be part of 2.0. I missed it because the issue
> was
> > >>> closed, we should have opened a 2.0 one to remember it.
> > >>>
> > >>
> > >> Thats's the problem if a closed/resolved issue does not have an
> > >> assignee. You never know who handled it without reading the entire
> > >> thread. A ticket should always have an assignee if code has been
> > changed.
> > >>
> > >>
> > > Here's what had been specified by Nathan at the time (order is
> > meaningful,
> > > and falseness seems easier to specify than truth):
> > >
> > > $obj is null
> > > $obj is boolean false
> > > $obj returns false from getAsBoolean() (provided there is such a
> method)
> > > $obj is empty string (CharSequence w/length 0)
> > > $obj returns true from isEmpty() (provided there is such a method)
> > > $obj is array of length 0
> > > $obj returns null from getAsString() (provided there is such a method)
> > > $obj returns empty string from getAsString() (provided there is such a
> > > method)
> > > $obj returns null from getAsNumber() (provided there is such a method)
> > > $obj returns 0 from length() or size() (provided there is such a
> method)
> > > $obj returns empty string from toString() (provided there is such a
> > method)
> > >
> > > Regarding this spec:
> > >  - I'm not sure about getAsString() ; toString() is usually the
> standard
> > > way of getting the String representation and should be enough.
> > >  - I'm not convinced by the fact that zero should be true. I hear
> > Nathan's
> > > point that for a display language, zero is as legitimate as any other
> > > number to be displayed. But it breaks the principle of least surprise,
> > > since each and every other language around, when not forbidding number
> > > towards boolean implicit conversion, consider zero as false.
> > >
> > > So I'd rather go with:
> > >
> > > $obj is null
> > > $obj is Boolean false
> > > $obj is Number zero (whatever Number variant)
> > > $obj returns false from getAsBoolean() (provided there is such a
> method)
> > > $obj is empty string (CharSequence w/length 0)
> > > $obj returns true from isEmpty() (provided there is such a method)
> > > $obj is array of length 0
> > > $obj returns null from getAsNumber() (provided there is such a method)
> > > $obj returns 0 from length() or size() (provided there is such a
> method)
> > > $obj returns empty string from toString() (provided there is such a
> > method)
> > >
> > > Also, I noticed that Velocity weren't very consistent with literals.
> The
> > > only literal returning true is the 'true' literal. "foo" is false,
> > whereas
> > > it should be consistent with $foo containing "foo".
> > >
> > >   Claude
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org
> > > For additional commands, e-mail: dev-help@velocity.apache.org
> > >
> > >
> >
>

Re: Velocity truth

[Claude Brisson <cl...@renegat.net>]

Oh, and there is one exception: both of them should of course also be 
false for the false boolean value. People willing to differentiate null 
and false do have methods to do so.

   Claude


On 29/01/2017 01:38, Claude Brisson wrote:
> On 28/01/2017 20:23, Alex Fedotov wrote:
>
>> You guys should definitely leave a way of disabling the toString()
>> conversion in boolean expressions.
>>
>> There are many places where people do null checks if #if($obj)...#end.
>>
>> Classes almost never return an empty string or null string from the
>> toString  call. Even worse some classes may use toString for debugging
>> purposes and produce very long  strings (including nested objects, 
>> etc.).
>> In the code above that would be a huge inefficiency.
>
> I totally agree that a great percentage of #if($foo) statements are 
> just here to check for nulls. And the current behavior of returning 
> false for empty strings, empty arrays and empty maps could already be 
> problematic in this regard
>
> And I think I have a good proposal about that.
>
> Since
>
> $foo differenciate null and "" (by displaying the first and not the 
> second)
> $!foo assimilates null and "" (by hiding both)
>
> why not consider that:
>
> #if($foo) returns false for null and true for everything else, and
> #if($!foo) returns false for null, "", zero, empty arrays, etc...
>
>
>   Claude
>
>>
>> Alex
>>
>> On Sat, Jan 28, 2017 at 2:06 PM, Nathan Bubna <nb...@gmail.com> wrote:
>>
>>> Shame that i can't remember anymore all my reasons for wanting those
>>> "getAs<Type>" lookups. Wondering why getAsNumber and getAsBoolean 
>>> are here
>>> too. Anyone else recall the use case? And assuming that i had good 
>>> reason
>>> (that did happen sometimes <grin>), i wonder why i pushed for 
>>> bucking the
>>> "to<Type>()" convention.
>>>
>>> As for the literals, the thought of them being used in #if 
>>> statements in a
>>> template language is cringe-inducing. What's the use-case? Temporary
>>> debugging hacks? If so, part of me thinks maybe only 'true' should 
>>> even be
>>> allowed.
>>>
>>> On Sat, Jan 28, 2017 at 7:15 AM, Claude Brisson <cl...@renegat.net>
>>> wrote:
>>>
>>>>
>>>>>>> What is the problem?
>>>>>>>
>>>>>>> Velocity "truthiness":
>>>>>> https://issues.apache.org/jira/browse/VELOCITY-692
>>>>>>
>>>>>> It should definitely be part of 2.0. I missed it because the 
>>>>>> issue was
>>>>>> closed, we should have opened a 2.0 one to remember it.
>>>>>>
>>>>> Thats's the problem if a closed/resolved issue does not have an
>>>>> assignee. You never know who handled it without reading the entire
>>>>> thread. A ticket should always have an assignee if code has been
>>> changed.
>>>>>
>>>> Here's what had been specified by Nathan at the time (order is
>>> meaningful,
>>>> and falseness seems easier to specify than truth):
>>>>
>>>> $obj is null
>>>> $obj is boolean false
>>>> $obj returns false from getAsBoolean() (provided there is such a 
>>>> method)
>>>> $obj is empty string (CharSequence w/length 0)
>>>> $obj returns true from isEmpty() (provided there is such a method)
>>>> $obj is array of length 0
>>>> $obj returns null from getAsString() (provided there is such a method)
>>>> $obj returns empty string from getAsString() (provided there is such a
>>>> method)
>>>> $obj returns null from getAsNumber() (provided there is such a method)
>>>> $obj returns 0 from length() or size() (provided there is such a 
>>>> method)
>>>> $obj returns empty string from toString() (provided there is such a
>>> method)
>>>> Regarding this spec:
>>>>   - I'm not sure about getAsString() ; toString() is usually the 
>>>> standard
>>>> way of getting the String representation and should be enough.
>>>>   - I'm not convinced by the fact that zero should be true. I hear
>>> Nathan's
>>>> point that for a display language, zero is as legitimate as any other
>>>> number to be displayed. But it breaks the principle of least surprise,
>>>> since each and every other language around, when not forbidding number
>>>> towards boolean implicit conversion, consider zero as false.
>>>>
>>>> So I'd rather go with:
>>>>
>>>> $obj is null
>>>> $obj is Boolean false
>>>> $obj is Number zero (whatever Number variant)
>>>> $obj returns false from getAsBoolean() (provided there is such a 
>>>> method)
>>>> $obj is empty string (CharSequence w/length 0)
>>>> $obj returns true from isEmpty() (provided there is such a method)
>>>> $obj is array of length 0
>>>> $obj returns null from getAsNumber() (provided there is such a method)
>>>> $obj returns 0 from length() or size() (provided there is such a 
>>>> method)
>>>> $obj returns empty string from toString() (provided there is such a
>>> method)
>>>> Also, I noticed that Velocity weren't very consistent with 
>>>> literals. The
>>>> only literal returning true is the 'true' literal. "foo" is false,
>>> whereas
>>>> it should be consistent with $foo containing "foo".
>>>>
>>>>    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
>
>


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

Re: Velocity truth

[Nathan Bubna <nb...@gmail.com>]

On Mon, Jan 30, 2017 at 1:33 PM, Claude Brisson <cl...@renegat.net> wrote:

> On 30/01/2017 22:08, Nathan Bubna wrote:
>
> On Sat, Jan 28, 2017 at 4:38 PM, Claude Brisson <cl...@renegat.net>
>> wrote:
>>
>> On 28/01/2017 20:23, Alex Fedotov wrote:
>>>
>>> You guys should definitely leave a way of disabling the toString()
>>>
>>>> conversion in boolean expressions.
>>>>
>>>> There are many places where people do null checks if #if($obj)...#end.
>>>>
>>>> Classes almost never return an empty string or null string from the
>>>> toString  call. Even worse some classes may use toString for debugging
>>>> purposes and produce very long  strings (including nested objects,
>>>> etc.).
>>>> In the code above that would be a huge inefficiency.
>>>>
>>>> I totally agree that a great percentage of #if($foo) statements are just
>>> here to check for nulls. And the current behavior of returning false for
>>> empty strings, empty arrays and empty maps could already be problematic
>>> in
>>> this regard
>>>
>>> And I think I have a good proposal about that.
>>>
>>> Since
>>>
>>> $foo differenciate null and "" (by displaying the first and not the
>>> second)
>>> $!foo assimilates null and "" (by hiding both)
>>>
>>> why not consider that:
>>>
>>> #if($foo) returns false for null and true for everything else, and
>>> #if($!foo) returns false for null, "", zero, empty arrays, etc...
>>>
>>> Yikes. That looks like a scary combo of significant and subtle. It would
>> need to be well-highlighted in the release notes, change logs, docs, etc.
>>
>> I might like it. Maybe. I dunno. The syntax is giving my tired brain
>> spasms, given that it's close to the very different #if( !$foo ). I can't
>> "read" it, if that make sense. It's like a complex regexp, where i have to
>> think my way through it, instead of just reading it.
>>
>> Is there a use-case for having both supported in the same template?
>> Otherwise, it might be better to avoid the subtlety and just support a
>> configuration property for how clever templates can be with evaluating
>> #if(
>> $foo ).
>>
>> Maybe we do the full lookup chain by default, but let people set a
>>
>> directive.if.emptycheck = false
>>
>> That would limit it to just checking for false or null values (presumably
>> still including getAsBoolean, getAsString, and toString), but skipping the
>> "empty" checks.
>>
>> Then the high performance move is:
>>
>> directive.if.emptycheck = false
>> directive.if.tostring.nullcheck = false
>>
>> But the default is for both to be true.
>>
>> That should be enough, yes.
>
> I like this syntax trick, but it remains a trick, so I won't stand for it.
> Let's forget it.
>
> However, I wonder if we should rework the lookup chain so that it never
> reaches bottom methods for standard types, collections and arrays. The
> lookup chain may pretty well mix false and true checks. Like: if it's an
> array, return whether or not it's empty and don't go further.


Good idea.  Once we find a method for checking (whether for null, false, or
empty), then we should take its answer and go no further in the chain.

Re: Velocity truth

[Claude Brisson <cl...@renegat.net>]

On 30/01/2017 22:08, Nathan Bubna wrote:

> On Sat, Jan 28, 2017 at 4:38 PM, Claude Brisson <cl...@renegat.net> wrote:
>
>> On 28/01/2017 20:23, Alex Fedotov wrote:
>>
>> You guys should definitely leave a way of disabling the toString()
>>> conversion in boolean expressions.
>>>
>>> There are many places where people do null checks if #if($obj)...#end.
>>>
>>> Classes almost never return an empty string or null string from the
>>> toString  call. Even worse some classes may use toString for debugging
>>> purposes and produce very long  strings (including nested objects, etc.).
>>> In the code above that would be a huge inefficiency.
>>>
>> I totally agree that a great percentage of #if($foo) statements are just
>> here to check for nulls. And the current behavior of returning false for
>> empty strings, empty arrays and empty maps could already be problematic in
>> this regard
>>
>> And I think I have a good proposal about that.
>>
>> Since
>>
>> $foo differenciate null and "" (by displaying the first and not the second)
>> $!foo assimilates null and "" (by hiding both)
>>
>> why not consider that:
>>
>> #if($foo) returns false for null and true for everything else, and
>> #if($!foo) returns false for null, "", zero, empty arrays, etc...
>>
> Yikes. That looks like a scary combo of significant and subtle. It would
> need to be well-highlighted in the release notes, change logs, docs, etc.
>
> I might like it. Maybe. I dunno. The syntax is giving my tired brain
> spasms, given that it's close to the very different #if( !$foo ). I can't
> "read" it, if that make sense. It's like a complex regexp, where i have to
> think my way through it, instead of just reading it.
>
> Is there a use-case for having both supported in the same template?
> Otherwise, it might be better to avoid the subtlety and just support a
> configuration property for how clever templates can be with evaluating #if(
> $foo ).
>
> Maybe we do the full lookup chain by default, but let people set a
>
> directive.if.emptycheck = false
>
> That would limit it to just checking for false or null values (presumably
> still including getAsBoolean, getAsString, and toString), but skipping the
> "empty" checks.
>
> Then the high performance move is:
>
> directive.if.emptycheck = false
> directive.if.tostring.nullcheck = false
>
> But the default is for both to be true.
>
That should be enough, yes.

I like this syntax trick, but it remains a trick, so I won't stand for 
it. Let's forget it.

However, I wonder if we should rework the lookup chain so that it never 
reaches bottom methods for standard types, collections and arrays. The 
lookup chain may pretty well mix false and true checks. Like: if it's an 
array, return whether or not it's empty and don't go further.

   Claude



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

Re: Velocity truth

[Nathan Bubna <nb...@gmail.com>]

On Sat, Jan 28, 2017 at 4:38 PM, Claude Brisson <cl...@renegat.net> wrote:

> On 28/01/2017 20:23, Alex Fedotov wrote:
>
> You guys should definitely leave a way of disabling the toString()
>> conversion in boolean expressions.
>>
>> There are many places where people do null checks if #if($obj)...#end.
>>
>> Classes almost never return an empty string or null string from the
>> toString  call. Even worse some classes may use toString for debugging
>> purposes and produce very long  strings (including nested objects, etc.).
>> In the code above that would be a huge inefficiency.
>>
>
> I totally agree that a great percentage of #if($foo) statements are just
> here to check for nulls. And the current behavior of returning false for
> empty strings, empty arrays and empty maps could already be problematic in
> this regard
>
> And I think I have a good proposal about that.
>
> Since
>
> $foo differenciate null and "" (by displaying the first and not the second)
> $!foo assimilates null and "" (by hiding both)
>
> why not consider that:
>
> #if($foo) returns false for null and true for everything else, and
> #if($!foo) returns false for null, "", zero, empty arrays, etc...
>

Yikes. That looks like a scary combo of significant and subtle. It would
need to be well-highlighted in the release notes, change logs, docs, etc.

I might like it. Maybe. I dunno. The syntax is giving my tired brain
spasms, given that it's close to the very different #if( !$foo ). I can't
"read" it, if that make sense. It's like a complex regexp, where i have to
think my way through it, instead of just reading it.

Is there a use-case for having both supported in the same template?
Otherwise, it might be better to avoid the subtlety and just support a
configuration property for how clever templates can be with evaluating #if(
$foo ).

Maybe we do the full lookup chain by default, but let people set a

directive.if.emptycheck = false

That would limit it to just checking for false or null values (presumably
still including getAsBoolean, getAsString, and toString), but skipping the
"empty" checks.

Then the high performance move is:

directive.if.emptycheck = false
directive.if.tostring.nullcheck = false

But the default is for both to be true.




>   Claude
>
>
>> Alex
>>
>> On Sat, Jan 28, 2017 at 2:06 PM, Nathan Bubna <nb...@gmail.com> wrote:
>>
>> Shame that i can't remember anymore all my reasons for wanting those
>>> "getAs<Type>" lookups. Wondering why getAsNumber and getAsBoolean are
>>> here
>>> too. Anyone else recall the use case? And assuming that i had good reason
>>> (that did happen sometimes <grin>), i wonder why i pushed for bucking the
>>> "to<Type>()" convention.
>>>
>>> As for the literals, the thought of them being used in #if statements in
>>> a
>>> template language is cringe-inducing. What's the use-case? Temporary
>>> debugging hacks? If so, part of me thinks maybe only 'true' should even
>>> be
>>> allowed.
>>>
>>> On Sat, Jan 28, 2017 at 7:15 AM, Claude Brisson <cl...@renegat.net>
>>> wrote:
>>>
>>>
>>>> What is the problem?
>>>>>>>
>>>>>>> Velocity "truthiness":
>>>>>>>
>>>>>> https://issues.apache.org/jira/browse/VELOCITY-692
>>>>>>
>>>>>> It should definitely be part of 2.0. I missed it because the issue was
>>>>>> closed, we should have opened a 2.0 one to remember it.
>>>>>>
>>>>>> Thats's the problem if a closed/resolved issue does not have an
>>>>> assignee. You never know who handled it without reading the entire
>>>>> thread. A ticket should always have an assignee if code has been
>>>>>
>>>> changed.
>>>
>>>>
>>>>> Here's what had been specified by Nathan at the time (order is
>>>>
>>> meaningful,
>>>
>>>> and falseness seems easier to specify than truth):
>>>>
>>>> $obj is null
>>>> $obj is boolean false
>>>> $obj returns false from getAsBoolean() (provided there is such a method)
>>>> $obj is empty string (CharSequence w/length 0)
>>>> $obj returns true from isEmpty() (provided there is such a method)
>>>> $obj is array of length 0
>>>> $obj returns null from getAsString() (provided there is such a method)
>>>> $obj returns empty string from getAsString() (provided there is such a
>>>> method)
>>>> $obj returns null from getAsNumber() (provided there is such a method)
>>>> $obj returns 0 from length() or size() (provided there is such a method)
>>>> $obj returns empty string from toString() (provided there is such a
>>>>
>>> method)
>>>
>>>> Regarding this spec:
>>>>   - I'm not sure about getAsString() ; toString() is usually the
>>>> standard
>>>> way of getting the String representation and should be enough.
>>>>   - I'm not convinced by the fact that zero should be true. I hear
>>>>
>>> Nathan's
>>>
>>>> point that for a display language, zero is as legitimate as any other
>>>> number to be displayed. But it breaks the principle of least surprise,
>>>> since each and every other language around, when not forbidding number
>>>> towards boolean implicit conversion, consider zero as false.
>>>>
>>>> So I'd rather go with:
>>>>
>>>> $obj is null
>>>> $obj is Boolean false
>>>> $obj is Number zero (whatever Number variant)
>>>> $obj returns false from getAsBoolean() (provided there is such a method)
>>>> $obj is empty string (CharSequence w/length 0)
>>>> $obj returns true from isEmpty() (provided there is such a method)
>>>> $obj is array of length 0
>>>> $obj returns null from getAsNumber() (provided there is such a method)
>>>> $obj returns 0 from length() or size() (provided there is such a method)
>>>> $obj returns empty string from toString() (provided there is such a
>>>>
>>> method)
>>>
>>>> Also, I noticed that Velocity weren't very consistent with literals. The
>>>> only literal returning true is the 'true' literal. "foo" is false,
>>>>
>>> whereas
>>>
>>>> it should be consistent with $foo containing "foo".
>>>>
>>>>    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: Velocity truth

[Claude Brisson <cl...@renegat.net>]

On 28/01/2017 20:23, Alex Fedotov wrote:

> You guys should definitely leave a way of disabling the toString()
> conversion in boolean expressions.
>
> There are many places where people do null checks if #if($obj)...#end.
>
> Classes almost never return an empty string or null string from the
> toString  call. Even worse some classes may use toString for debugging
> purposes and produce very long  strings (including nested objects, etc.).
> In the code above that would be a huge inefficiency.

I totally agree that a great percentage of #if($foo) statements are just 
here to check for nulls. And the current behavior of returning false for 
empty strings, empty arrays and empty maps could already be problematic 
in this regard

And I think I have a good proposal about that.

Since

$foo differenciate null and "" (by displaying the first and not the second)
$!foo assimilates null and "" (by hiding both)

why not consider that:

#if($foo) returns false for null and true for everything else, and
#if($!foo) returns false for null, "", zero, empty arrays, etc...


   Claude

>
> Alex
>
> On Sat, Jan 28, 2017 at 2:06 PM, Nathan Bubna <nb...@gmail.com> wrote:
>
>> Shame that i can't remember anymore all my reasons for wanting those
>> "getAs<Type>" lookups. Wondering why getAsNumber and getAsBoolean are here
>> too. Anyone else recall the use case? And assuming that i had good reason
>> (that did happen sometimes <grin>), i wonder why i pushed for bucking the
>> "to<Type>()" convention.
>>
>> As for the literals, the thought of them being used in #if statements in a
>> template language is cringe-inducing. What's the use-case? Temporary
>> debugging hacks? If so, part of me thinks maybe only 'true' should even be
>> allowed.
>>
>> On Sat, Jan 28, 2017 at 7:15 AM, Claude Brisson <cl...@renegat.net>
>> wrote:
>>
>>>
>>>>>> What is the problem?
>>>>>>
>>>>>> Velocity "truthiness":
>>>>> https://issues.apache.org/jira/browse/VELOCITY-692
>>>>>
>>>>> It should definitely be part of 2.0. I missed it because the issue was
>>>>> closed, we should have opened a 2.0 one to remember it.
>>>>>
>>>> Thats's the problem if a closed/resolved issue does not have an
>>>> assignee. You never know who handled it without reading the entire
>>>> thread. A ticket should always have an assignee if code has been
>> changed.
>>>>
>>> Here's what had been specified by Nathan at the time (order is
>> meaningful,
>>> and falseness seems easier to specify than truth):
>>>
>>> $obj is null
>>> $obj is boolean false
>>> $obj returns false from getAsBoolean() (provided there is such a method)
>>> $obj is empty string (CharSequence w/length 0)
>>> $obj returns true from isEmpty() (provided there is such a method)
>>> $obj is array of length 0
>>> $obj returns null from getAsString() (provided there is such a method)
>>> $obj returns empty string from getAsString() (provided there is such a
>>> method)
>>> $obj returns null from getAsNumber() (provided there is such a method)
>>> $obj returns 0 from length() or size() (provided there is such a method)
>>> $obj returns empty string from toString() (provided there is such a
>> method)
>>> Regarding this spec:
>>>   - I'm not sure about getAsString() ; toString() is usually the standard
>>> way of getting the String representation and should be enough.
>>>   - I'm not convinced by the fact that zero should be true. I hear
>> Nathan's
>>> point that for a display language, zero is as legitimate as any other
>>> number to be displayed. But it breaks the principle of least surprise,
>>> since each and every other language around, when not forbidding number
>>> towards boolean implicit conversion, consider zero as false.
>>>
>>> So I'd rather go with:
>>>
>>> $obj is null
>>> $obj is Boolean false
>>> $obj is Number zero (whatever Number variant)
>>> $obj returns false from getAsBoolean() (provided there is such a method)
>>> $obj is empty string (CharSequence w/length 0)
>>> $obj returns true from isEmpty() (provided there is such a method)
>>> $obj is array of length 0
>>> $obj returns null from getAsNumber() (provided there is such a method)
>>> $obj returns 0 from length() or size() (provided there is such a method)
>>> $obj returns empty string from toString() (provided there is such a
>> method)
>>> Also, I noticed that Velocity weren't very consistent with literals. The
>>> only literal returning true is the 'true' literal. "foo" is false,
>> whereas
>>> it should be consistent with $foo containing "foo".
>>>
>>>    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: Velocity truth (was: Re: [ANNOUNCE] Velocity Engine 2.0 RC6 test build available)

[Alex Fedotov <al...@kayak.com>]

You guys should definitely leave a way of disabling the toString()
conversion in boolean expressions.

There are many places where people do null checks if #if($obj)...#end.

Classes almost never return an empty string or null string from the
toString  call. Even worse some classes may use toString for debugging
purposes and produce very long  strings (including nested objects, etc.).
In the code above that would be a huge inefficiency.

Alex

On Sat, Jan 28, 2017 at 2:06 PM, Nathan Bubna <nb...@gmail.com> wrote:

> Shame that i can't remember anymore all my reasons for wanting those
> "getAs<Type>" lookups. Wondering why getAsNumber and getAsBoolean are here
> too. Anyone else recall the use case? And assuming that i had good reason
> (that did happen sometimes <grin>), i wonder why i pushed for bucking the
> "to<Type>()" convention.
>
> As for the literals, the thought of them being used in #if statements in a
> template language is cringe-inducing. What's the use-case? Temporary
> debugging hacks? If so, part of me thinks maybe only 'true' should even be
> allowed.
>
> On Sat, Jan 28, 2017 at 7:15 AM, Claude Brisson <cl...@renegat.net>
> wrote:
>
> >
> >
> >>>> What is the problem?
> >>>>
> >>>> Velocity "truthiness":
> >>> https://issues.apache.org/jira/browse/VELOCITY-692
> >>>
> >>> It should definitely be part of 2.0. I missed it because the issue was
> >>> closed, we should have opened a 2.0 one to remember it.
> >>>
> >>
> >> Thats's the problem if a closed/resolved issue does not have an
> >> assignee. You never know who handled it without reading the entire
> >> thread. A ticket should always have an assignee if code has been
> changed.
> >>
> >>
> > Here's what had been specified by Nathan at the time (order is
> meaningful,
> > and falseness seems easier to specify than truth):
> >
> > $obj is null
> > $obj is boolean false
> > $obj returns false from getAsBoolean() (provided there is such a method)
> > $obj is empty string (CharSequence w/length 0)
> > $obj returns true from isEmpty() (provided there is such a method)
> > $obj is array of length 0
> > $obj returns null from getAsString() (provided there is such a method)
> > $obj returns empty string from getAsString() (provided there is such a
> > method)
> > $obj returns null from getAsNumber() (provided there is such a method)
> > $obj returns 0 from length() or size() (provided there is such a method)
> > $obj returns empty string from toString() (provided there is such a
> method)
> >
> > Regarding this spec:
> >  - I'm not sure about getAsString() ; toString() is usually the standard
> > way of getting the String representation and should be enough.
> >  - I'm not convinced by the fact that zero should be true. I hear
> Nathan's
> > point that for a display language, zero is as legitimate as any other
> > number to be displayed. But it breaks the principle of least surprise,
> > since each and every other language around, when not forbidding number
> > towards boolean implicit conversion, consider zero as false.
> >
> > So I'd rather go with:
> >
> > $obj is null
> > $obj is Boolean false
> > $obj is Number zero (whatever Number variant)
> > $obj returns false from getAsBoolean() (provided there is such a method)
> > $obj is empty string (CharSequence w/length 0)
> > $obj returns true from isEmpty() (provided there is such a method)
> > $obj is array of length 0
> > $obj returns null from getAsNumber() (provided there is such a method)
> > $obj returns 0 from length() or size() (provided there is such a method)
> > $obj returns empty string from toString() (provided there is such a
> method)
> >
> > Also, I noticed that Velocity weren't very consistent with literals. The
> > only literal returning true is the 'true' literal. "foo" is false,
> whereas
> > it should be consistent with $foo containing "foo".
> >
> >   Claude
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org
> > For additional commands, e-mail: dev-help@velocity.apache.org
> >
> >
>

Re: Velocity truth

[Claude Brisson <cl...@renegat.net>]

On 28/01/2017 20:06, Nathan Bubna wrote:

> Shame that i can't remember anymore all my reasons for wanting those
> "getAs<Type>" lookups. Wondering why getAsNumber and getAsBoolean are here
> too. Anyone else recall the use case? And assuming that i had good reason
> (that did happen sometimes <grin>), i wonder why i pushed for bucking the
> "to<Type>()" convention.

It seems like Java8 went your way:
https://docs.oracle.com/javase/8/docs/api/java/util/function/BooleanSupplier.html

Anyway, we can check both getAsBoolean and toBoolean, as with 
getAsNumber and toNumber, etc... but maybe we should stick to 
to<Something> methods.
>
> As for the literals, the thought of them being used in #if statements in a
> template language is cringe-inducing. What's the use-case? Temporary
> debugging hacks? If so, part of me thinks maybe only 'true' should even be
> allowed.

Well, imagine a newcomer to Velocity trying to understand its behavior. 
He will typically write #if("") or #if(0) to check what happens for an 
empty string or for zero. Not having a consistent behavior may make him 
build wrong assumptions.

Or a developer writing #if(0) instead of #if(false) to temporarily 
inhibit a portion of code.

Or think educational use...


   Claude

> On Sat, Jan 28, 2017 at 7:15 AM, Claude Brisson <cl...@renegat.net> wrote:
>
>>
>>>>> What is the problem?
>>>>>
>>>>> Velocity "truthiness":
>>>> https://issues.apache.org/jira/browse/VELOCITY-692
>>>>
>>>> It should definitely be part of 2.0. I missed it because the issue was
>>>> closed, we should have opened a 2.0 one to remember it.
>>>>
>>> Thats's the problem if a closed/resolved issue does not have an
>>> assignee. You never know who handled it without reading the entire
>>> thread. A ticket should always have an assignee if code has been changed.
>>>
>>>
>> Here's what had been specified by Nathan at the time (order is meaningful,
>> and falseness seems easier to specify than truth):
>>
>> $obj is null
>> $obj is boolean false
>> $obj returns false from getAsBoolean() (provided there is such a method)
>> $obj is empty string (CharSequence w/length 0)
>> $obj returns true from isEmpty() (provided there is such a method)
>> $obj is array of length 0
>> $obj returns null from getAsString() (provided there is such a method)
>> $obj returns empty string from getAsString() (provided there is such a
>> method)
>> $obj returns null from getAsNumber() (provided there is such a method)
>> $obj returns 0 from length() or size() (provided there is such a method)
>> $obj returns empty string from toString() (provided there is such a method)
>>
>> Regarding this spec:
>>   - I'm not sure about getAsString() ; toString() is usually the standard
>> way of getting the String representation and should be enough.
>>   - I'm not convinced by the fact that zero should be true. I hear Nathan's
>> point that for a display language, zero is as legitimate as any other
>> number to be displayed. But it breaks the principle of least surprise,
>> since each and every other language around, when not forbidding number
>> towards boolean implicit conversion, consider zero as false.
>>
>> So I'd rather go with:
>>
>> $obj is null
>> $obj is Boolean false
>> $obj is Number zero (whatever Number variant)
>> $obj returns false from getAsBoolean() (provided there is such a method)
>> $obj is empty string (CharSequence w/length 0)
>> $obj returns true from isEmpty() (provided there is such a method)
>> $obj is array of length 0
>> $obj returns null from getAsNumber() (provided there is such a method)
>> $obj returns 0 from length() or size() (provided there is such a method)
>> $obj returns empty string from toString() (provided there is such a method)
>>
>> Also, I noticed that Velocity weren't very consistent with literals. The
>> only literal returning true is the 'true' literal. "foo" is false, whereas
>> it should be consistent with $foo containing "foo".
>>
>>    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: Velocity truth (was: Re: [ANNOUNCE] Velocity Engine 2.0 RC6 test build available)

[Nathan Bubna <nb...@gmail.com>]

Shame that i can't remember anymore all my reasons for wanting those
"getAs<Type>" lookups. Wondering why getAsNumber and getAsBoolean are here
too. Anyone else recall the use case? And assuming that i had good reason
(that did happen sometimes <grin>), i wonder why i pushed for bucking the
"to<Type>()" convention.

As for the literals, the thought of them being used in #if statements in a
template language is cringe-inducing. What's the use-case? Temporary
debugging hacks? If so, part of me thinks maybe only 'true' should even be
allowed.

On Sat, Jan 28, 2017 at 7:15 AM, Claude Brisson <cl...@renegat.net> wrote:

>
>
>>>> What is the problem?
>>>>
>>>> Velocity "truthiness":
>>> https://issues.apache.org/jira/browse/VELOCITY-692
>>>
>>> It should definitely be part of 2.0. I missed it because the issue was
>>> closed, we should have opened a 2.0 one to remember it.
>>>
>>
>> Thats's the problem if a closed/resolved issue does not have an
>> assignee. You never know who handled it without reading the entire
>> thread. A ticket should always have an assignee if code has been changed.
>>
>>
> Here's what had been specified by Nathan at the time (order is meaningful,
> and falseness seems easier to specify than truth):
>
> $obj is null
> $obj is boolean false
> $obj returns false from getAsBoolean() (provided there is such a method)
> $obj is empty string (CharSequence w/length 0)
> $obj returns true from isEmpty() (provided there is such a method)
> $obj is array of length 0
> $obj returns null from getAsString() (provided there is such a method)
> $obj returns empty string from getAsString() (provided there is such a
> method)
> $obj returns null from getAsNumber() (provided there is such a method)
> $obj returns 0 from length() or size() (provided there is such a method)
> $obj returns empty string from toString() (provided there is such a method)
>
> Regarding this spec:
>  - I'm not sure about getAsString() ; toString() is usually the standard
> way of getting the String representation and should be enough.
>  - I'm not convinced by the fact that zero should be true. I hear Nathan's
> point that for a display language, zero is as legitimate as any other
> number to be displayed. But it breaks the principle of least surprise,
> since each and every other language around, when not forbidding number
> towards boolean implicit conversion, consider zero as false.
>
> So I'd rather go with:
>
> $obj is null
> $obj is Boolean false
> $obj is Number zero (whatever Number variant)
> $obj returns false from getAsBoolean() (provided there is such a method)
> $obj is empty string (CharSequence w/length 0)
> $obj returns true from isEmpty() (provided there is such a method)
> $obj is array of length 0
> $obj returns null from getAsNumber() (provided there is such a method)
> $obj returns 0 from length() or size() (provided there is such a method)
> $obj returns empty string from toString() (provided there is such a method)
>
> Also, I noticed that Velocity weren't very consistent with literals. The
> only literal returning true is the 'true' literal. "foo" is false, whereas
> it should be consistent with $foo containing "foo".
>
>   Claude
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org
> For additional commands, e-mail: dev-help@velocity.apache.org
>
>

Velocity truth (was: Re: [ANNOUNCE] Velocity Engine 2.0 RC6 test build available)

[Claude Brisson <cl...@renegat.net>]

>>>
>>> What is the problem?
>>>
>> Velocity "truthiness":
>> https://issues.apache.org/jira/browse/VELOCITY-692
>>
>> It should definitely be part of 2.0. I missed it because the issue was
>> closed, we should have opened a 2.0 one to remember it.
>
> Thats's the problem if a closed/resolved issue does not have an
> assignee. You never know who handled it without reading the entire
> thread. A ticket should always have an assignee if code has been changed.
>

Here's what had been specified by Nathan at the time (order is 
meaningful, and falseness seems easier to specify than truth):

$obj is null
$obj is boolean false
$obj returns false from getAsBoolean() (provided there is such a method)
$obj is empty string (CharSequence w/length 0)
$obj returns true from isEmpty() (provided there is such a method)
$obj is array of length 0
$obj returns null from getAsString() (provided there is such a method)
$obj returns empty string from getAsString() (provided there is such a 
method)
$obj returns null from getAsNumber() (provided there is such a method)
$obj returns 0 from length() or size() (provided there is such a method)
$obj returns empty string from toString() (provided there is such a method)

Regarding this spec:
  - I'm not sure about getAsString() ; toString() is usually the 
standard way of getting the String representation and should be enough.
  - I'm not convinced by the fact that zero should be true. I hear 
Nathan's point that for a display language, zero is as legitimate as any 
other number to be displayed. But it breaks the principle of least 
surprise, since each and every other language around, when not 
forbidding number towards boolean implicit conversion, consider zero as 
false.

So I'd rather go with:

$obj is null
$obj is Boolean false
$obj is Number zero (whatever Number variant)
$obj returns false from getAsBoolean() (provided there is such a method)
$obj is empty string (CharSequence w/length 0)
$obj returns true from isEmpty() (provided there is such a method)
$obj is array of length 0
$obj returns null from getAsNumber() (provided there is such a method)
$obj returns 0 from length() or size() (provided there is such a method)
$obj returns empty string from toString() (provided there is such a method)

Also, I noticed that Velocity weren't very consistent with literals. The 
only literal returning true is the 'true' literal. "foo" is false, 
whereas it should be consistent with $foo containing "foo".

   Claude


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

Re: [ANNOUNCE] Velocity Engine 2.0 RC6 test build available

[Michael Osipov <mi...@apache.org>]

Am 2017-01-27 um 00:27 schrieb Claude Brisson:
>
>
> On 26/01/2017 19:45, Michael Osipov wrote:
>> Am 2017-01-26 um 18:37 schrieb Claude Brisson:
>>>
>>>>
>>>> Now my question is: do you or someone else think that the OSGi missing
>>>> meta-informations are a show stopper for the 2.0? Otherwise, my plan
>>>> is to open JIRA issues for all those remarks, try to release the RC6,
>>>> and handle the issues in 2.0.1 or 2.1. The OSGi thing is the only one
>>>> I'm not really sure about, since I'm not using any tool relying on
>>>> OSGi myself (or maybe I'm the Monsieur Jourdain of the OSGi).
>>
>> Velocity 2.0 took so much time, one month more or less doesn't really
>> make a difference now.
>>
> It does. It's becoming harder and harder for me to find time working on
> it. Your and others help as a reviewer is very helpful, but it does
> still take several hours each time, and there will *always* be an extra
> space to fix somewhere. I am not against seeking a certain form of
> perfection in the code, but the process doesn't have to be coerced in a
> single release.

I know it consumes a lot of time. So does my work for Maven. I wouldn't 
mind to commit myself and we'd do CTR (commit then review) to relieve 
you from the massive work.

> And once the engine is released, I still have to take care of the Tools.
> And then of several other tools and filters for the next release of the
> Tools.

I do not mind to review here too.

> That's why I would like to see some rhythm. And releasing can attract
> more people. And who said "release often release early"? Or, in the same
> vein, "when the product is almost ready, kill the engineer"? Well, I'm
> an engineer, but I do understand the motivation.
>
> But there will at least be an RC7. So, I'll try to do something about
> this OSGi missing informations.
>
>>>
>>> Of course, if we find any other serious bug, the question is not anymore
>>> pertinent. And I think I found a problem that sits here since some
>>> time...
>>
>> What is the problem?
>>
> Velocity "truthiness": https://issues.apache.org/jira/browse/VELOCITY-692
>
> It should definitely be part of 2.0. I missed it because the issue was
> closed, we should have opened a 2.0 one to remember it.

Thats's the problem if a closed/resolved issue does not have an 
assignee. You never know who handled it without reading the entire 
thread. A ticket should always have an assignee if code has been changed.

Michael


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

Re: [ANNOUNCE] Velocity Engine 2.0 RC6 test build available

[Claude Brisson <cl...@renegat.net>]

On 26/01/2017 19:45, Michael Osipov wrote:
> Am 2017-01-26 um 18:37 schrieb Claude Brisson:
>>
>>>
>>> Now my question is: do you or someone else think that the OSGi missing
>>> meta-informations are a show stopper for the 2.0? Otherwise, my plan
>>> is to open JIRA issues for all those remarks, try to release the RC6,
>>> and handle the issues in 2.0.1 or 2.1. The OSGi thing is the only one
>>> I'm not really sure about, since I'm not using any tool relying on
>>> OSGi myself (or maybe I'm the Monsieur Jourdain of the OSGi).
>
> Velocity 2.0 took so much time, one month more or less doesn't really 
> make a difference now.
>
It does. It's becoming harder and harder for me to find time working on 
it. Your and others help as a reviewer is very helpful, but it does 
still take several hours each time, and there will *always* be an extra 
space to fix somewhere. I am not against seeking a certain form of 
perfection in the code, but the process doesn't have to be coerced in a 
single release.

And once the engine is released, I still have to take care of the Tools. 
And then of several other tools and filters for the next release of the 
Tools.

That's why I would like to see some rhythm. And releasing can attract 
more people. And who said "release often release early"? Or, in the same 
vein, "when the product is almost ready, kill the engineer"? Well, I'm 
an engineer, but I do understand the motivation.

But there will at least be an RC7. So, I'll try to do something about 
this OSGi missing informations.

>>
>> Of course, if we find any other serious bug, the question is not anymore
>> pertinent. And I think I found a problem that sits here since some 
>> time...
>
> What is the problem?
>
Velocity "truthiness": https://issues.apache.org/jira/browse/VELOCITY-692

It should definitely be part of 2.0. I missed it because the issue was 
closed, we should have opened a 2.0 one to remember it.


   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: [ANNOUNCE] Velocity Engine 2.0 RC6 test build available

[Michael Osipov <mi...@apache.org>]

Am 2017-01-26 um 18:37 schrieb Claude Brisson:
>
>>
>> Now my question is: do you or someone else think that the OSGi missing
>> meta-informations are a show stopper for the 2.0? Otherwise, my plan
>> is to open JIRA issues for all those remarks, try to release the RC6,
>> and handle the issues in 2.0.1 or 2.1. The OSGi thing is the only one
>> I'm not really sure about, since I'm not using any tool relying on
>> OSGi myself (or maybe I'm the Monsieur Jourdain of the OSGi).

Velocity 2.0 took so much time, one month more or less doesn't really 
make a difference now.

>
> Of course, if we find any other serious bug, the question is not anymore
> pertinent. And I think I found a problem that sits here since some time...

What is the problem?


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

Re: [ANNOUNCE] Velocity Engine 2.0 RC6 test build available

[Claude Brisson <cl...@renegat.net>]

>
> Now my question is: do you or someone else think that the OSGi missing 
> meta-informations are a show stopper for the 2.0? Otherwise, my plan 
> is to open JIRA issues for all those remarks, try to release the RC6, 
> and handle the issues in 2.0.1 or 2.1. The OSGi thing is the only one 
> I'm not really sure about, since I'm not using any tool relying on 
> OSGi myself (or maybe I'm the Monsieur Jourdain of the OSGi).
>
>

Of course, if we find any other serious bug, the question is not anymore 
pertinent. And I think I found a problem that sits here since some time...

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

Re: [ANNOUNCE] Velocity Engine 2.0 RC6 test build available

[Michael Osipov <mi...@apache.org>]

Am 2017-01-26 um 17:54 schrieb Claude Brisson:
> On 26/01/2017 14:11, Michael Osipov wrote:
> [...]
>> * StringUtils#normalizePath() can likely be replaced with Common IO's
>> FilenameUtils#normalize()
> If we take this route, then we'll shade the commons-io class.

Absolutely, they might be other spots where this class can be used. 
Moreover, either using IOUtils#closeQuietly() or try-with-resources will 
clean up a lot of boilerplace code.

>> * OSGi metadata are gone from Core, no Bundle-SymbolicName, no
>> Exports, everything is gone from MANIFEST.MF
>
> This I don't understand at all. You said "gone", so you implied that
> those meta informations *were* to be found somewhere before this RC? I
> think we never made the effort to properly populate those informations.

JIRA release notes say:
[VELOCITY-694] Make Velocity OSGi-ready

I do not see any of the OSGi required metadata.

>> * There are several spots where collections are iterated with a for
>> loop with a counter and #get(i) or a literal (legacy code). This
>> should generally be avoided. One example has been commented on GitHub.
>
> I agree. Hopefully, this reenginering has already been done in sensitive
> code sections, and remaining ones should be harmless.

Are you sure? I found a few #get(i) in a few loaders, RuntimeMacro and 
Template. In a high-concurrency webapp where templates and macros are 
loaded very often, this can be an issue, but of course, I do not have 
hard numbers for this.

>> * Terrific improvement on the JavaCC code generation!
>> * JavaCC tells me:
>>> Note: UNICODE_INPUT option is specified. Please make sure you create
>>> the parser/lexer using a Reader with the correct character encoding.
>>> Warning: Choice conflict in [...] construct at line 1325, column 21.
>>>          Expansion nested within construct and expansion following
>>> construct
>>>          have common prefixes, one of which is: <TEXT>
>>>          Consider using a lookahead of 2 or more for nested expansion.
>>> Warning: Choice conflict in (...)* construct at line 2157, column 5.
>>>          Expansion nested within construct and expansion following
>>> construct
>>>          have common prefixes, one of which is: <WHITESPACE>
>>>          Consider using a lookahead of 2 or more for nested expansion.
>>
>> Is this something one needs to take care of?
>>
> Not at all. Those two grammar constructs partially rely on the *order of
> declaration* (and the '?' cardinality suffix inside a repetition
> operator is enough to trigger the warning). javacc is just anxious about
> that, and suggests adding lookahead instead.

OK, great. What about UNICODE_INPUT? Docs say we should set this if we 
have Unicode files. We have set UTF-8. Can we ignore this message too#?

> Thanks for all this remarks, Michael. They all are very constructive.

Very much welcome.

> Now my question is: do you or someone else think that the OSGi missing
> meta-informations are a show stopper for the 2.0? Otherwise, my plan is
> to open JIRA issues for all those remarks, try to release the RC6, and
> handle the issues in 2.0.1 or 2.1. The OSGi thing is the only one I'm
> not really sure about, since I'm not using any tool relying on OSGi
> myself (or maybe I'm the Monsieur Jourdain of the OSGi).

I do not use OSGi myself, but this says pretty much everything: 
https://mvnrepository.com/artifact/org.apache.servicemix.bundles/org.apache.servicemix.bundles.velocity. 
I consider proper OSGi metadata as vital for Velocity. Unfortunately, I 
do not know what to set with the Bundle Maven Plugin to have proper data 
generated.

Michael

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

Re: [ANNOUNCE] Velocity Engine 2.0 RC6 test build available

[Claude Brisson <cl...@renegat.net>]

On 26/01/2017 14:11, Michael Osipov wrote:
[...]
> * StringUtils#normalizePath() can likely be replaced with Common IO's 
> FilenameUtils#normalize()
If we take this route, then we'll shade the commons-io class.
>
> * StringUtils#nullTrim() can be replaced with Commons Lang's 
> StringUtils#trim()
> * StringUtils#trimStrings() can be disposed altogether because it 
> iterates the list and it is iterated right after the call again. Use 
> StringUtils#trim() during the real iteration directly

Right.

[...]

> * OSGi metadata are gone from Core, no Bundle-SymbolicName, no 
> Exports, everything is gone from MANIFEST.MF

This I don't understand at all. You said "gone", so you implied that 
those meta informations *were* to be found somewhere before this RC? I 
think we never made the effort to properly populate those informations.

> * There are several spots where collections are iterated with a for 
> loop with a counter and #get(i) or a literal (legacy code). This 
> should generally be avoided. One example has been commented on GitHub.

I agree. Hopefully, this reenginering has already been done in sensitive 
code sections, and remaining ones should be harmless.

> * Terrific improvement on the JavaCC code generation!
> * JavaCC tells me:
>> Note: UNICODE_INPUT option is specified. Please make sure you create 
>> the parser/lexer using a Reader with the correct character encoding.
>> Warning: Choice conflict in [...] construct at line 1325, column 21.
>>          Expansion nested within construct and expansion following 
>> construct
>>          have common prefixes, one of which is: <TEXT>
>>          Consider using a lookahead of 2 or more for nested expansion.
>> Warning: Choice conflict in (...)* construct at line 2157, column 5.
>>          Expansion nested within construct and expansion following 
>> construct
>>          have common prefixes, one of which is: <WHITESPACE>
>>          Consider using a lookahead of 2 or more for nested expansion.
>
> Is this something one needs to take care of?
>
Not at all. Those two grammar constructs partially rely on the *order of 
declaration* (and the '?' cardinality suffix inside a repetition 
operator is enough to trigger the warning). javacc is just anxious about 
that, and suggests adding lookahead instead.

Thanks for all this remarks, Michael. They all are very constructive.

Now my question is: do you or someone else think that the OSGi missing 
meta-informations are a show stopper for the 2.0? Otherwise, my plan is 
to open JIRA issues for all those remarks, try to release the RC6, and 
handle the issues in 2.0.1 or 2.1. The OSGi thing is the only one I'm 
not really sure about, since I'm not using any tool relying on OSGi 
myself (or maybe I'm the Monsieur Jourdain of the OSGi).


    Claude



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

Re: [ANNOUNCE] Velocity Engine 2.0 RC6 test build available

[Michael Osipov <mi...@apache.org>]

Am 2017-01-26 um 04:39 schrieb Claude Brisson:
> A new test build of Velocity Engine 2.0 is available (RC6).
>
> No determination as to the quality ('alpha,' 'beta,' or 'GA') of
> Velocity Engine 2.0 has been made, and at this time it is simply a "test
> build". We welcome any comments you may have, and will take all feedback
> into account if a quality vote is called for this build.
>
> Release notes:
>
> *
> https://dist.apache.org/repos/dist/dev/velocity/velocity-engine/2.0/release-notes.html
>
>
> Distribution:
>
>  * https://dist.apache.org/repos/dist/dev/velocity/velocity-engine/2.0/
>
> Maven 2 staging repository:
>
>  *
> https://repository.apache.org/content/repositories/orgapachevelocity-1016/
>
> A vote regarding the quality of this test build will be initiated within
> the next couple of days.

Hi Claude,

first of all, great improvement. Just checked the diff and have a few 
comments:

* Left a bunch of comments on the commits on GitHub, have a look
* StringUtils#EOL is never used
* StringUtils#normalizePath() can likely be replaced with Common IO's 
FilenameUtils#normalize()
* StringUtils#nullTrim() can be replaced with Commons Lang's 
StringUtils#trim()
* StringUtils#trimStrings() can be disposed altogether because it 
iterates the list and it is iterated right after the call again. Use 
StringUtils#trim() during the real iteration directly
* OSGi metadata are gone from Core, no Bundle-SymbolicName, no Exports, 
everything is gone from MANIFEST.MF
* There are several spots where collections are iterated with a for loop 
with a counter and #get(i) or a literal (legacy code). This should 
generally be avoided. One example has been commented on GitHub.
* Terrific improvement on the JavaCC code generation!
* JavaCC tells me:
> Note: UNICODE_INPUT option is specified. Please make sure you create the parser/lexer using a Reader with the correct character encoding.
> Warning: Choice conflict in [...] construct at line 1325, column 21.
>          Expansion nested within construct and expansion following construct
>          have common prefixes, one of which is: <TEXT>
>          Consider using a lookahead of 2 or more for nested expansion.
> Warning: Choice conflict in (...)* construct at line 2157, column 5.
>          Expansion nested within construct and expansion following construct
>          have common prefixes, one of which is: <WHITESPACE>
>          Consider using a lookahead of 2 or more for nested expansion.

Is this something one needs to take care of?


Michael

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

Re: [ANNOUNCE] Velocity Engine 2.0 RC6 test build available

[Greg Huber <gr...@gmail.com>]

Ahh java, now seems so many different ways of doing the same thing....
Just importing a file, I also have standard utils.

The path is the tricky one now, without testing it.

value = FileUtils.readFileToString(new File(
                                        getProject().resolveFile(value)
                                                .getCanonicalPath()),
UTF_8);

Path thePath = FileSystems.getDefault().getPath(
                                        getProject().resolveFile(value)
                                        .getCanonicalPath());

value = new String(Files.readAllBytes(thePath),
                                        StandardCharsets.UTF_8);



On 26 January 2017 at 15:48, Claude Brisson <cl...@renegat.net> wrote:

> Oh, and Michael Osipov suggested a much easier way:
>
>     import java.nio.Files;
>     import java.nio.charset.StandardCharsets;
>     ....
>     String contents = new String(Files.readAllBytes(path),
> StandardCharsets.UTF_8);
>
>
>   Claude
>
> On 26/01/2017 15:42, Claude Brisson wrote:
>
>> Hi Greg.
>>
>> Just include the commons-io library [1], then do:
>>
>>     import org.apache.commons.io.FileUtils;
>>     ....
>>     String content = FiileUtils.readFileToString(new File(filename),
>> Charset.UTF_8);
>>
>> The charset parameter is optional but recommended. Adapt it to your
>> needs, of course.
>>
>> [1] https://mvnrepository.com/artifact/commons-io/commons-io/2.5
>>
>>
>>   Claude
>>
>> On 26/01/2017 14:52, Greg Huber wrote:
>>
>>> Hello,
>>>
>>> I use the taxen task, and now have a local copy as its no longer
>>> supported.
>>>
>>> What would be an equivalent to .fileContentsToString(..) as its now
>>> missing?
>>>
>>> org.apache.velocity.util.StringUtils
>>>
>>> value = StringUtils.fileContentsToString(
>>> getProject().resolveFile(value)
>>> .getCanonicalPath());
>>>
>>> Cheers Greg
>>>
>>>
>>>
>>> On 26 January 2017 at 03:39, Claude Brisson <cl...@renegat.net> wrote:
>>>
>>> A new test build of Velocity Engine 2.0 is available (RC6).
>>>>
>>>> No determination as to the quality ('alpha,' 'beta,' or 'GA') of
>>>> Velocity
>>>> Engine 2.0 has been made, and at this time it is simply a "test build".
>>>> We
>>>> welcome any comments you may have, and will take all feedback into
>>>> account
>>>> if a quality vote is called for this build.
>>>>
>>>> Release notes:
>>>>
>>>> * https://dist.apache.org/repos/dist/dev/velocity/velocity-eng
>>>> ine/2.0/release-notes.html
>>>>
>>>> Distribution:
>>>>
>>>>   * https://dist.apache.org/repos/dist/dev/velocity/velocity-eng
>>>> ine/2.0/
>>>>
>>>> Maven 2 staging repository:
>>>>
>>>>   * https://repository.apache.org/content/repositories/orgapache
>>>> velocity-1016/
>>>>
>>>> A vote regarding the quality of this test build will be initiated within
>>>> the next couple of days.
>>>>
>>>> Release Candidates changelog:
>>>>    RC1: initial candidate
>>>>    RC2: bugfixes
>>>>    RC3: review SLF4J Logger names (instead of a single logger named
>>>> "Velocity", have a hierarchy of loggers with a base of
>>>> 'org.apache.velocity')
>>>>    RC4: minor fixes
>>>>    RC5:
>>>>     * the default encoding is now UTF-8 (and not the platform default)
>>>>     * commons-collections is not any more a compilation dependency
>>>>     * commons-lang3 dependency is not any more shaded
>>>>     * the configuration API doesn't reference ExtProperties
>>>>     * the events API has been optimized and reviewed: all events do
>>>> receive
>>>> the current Context
>>>>     * there has been a few optimizations in ASTStringLiteral rendering
>>>> RC6: mostly code cleaning and build process optimization ; assembly
>>>> module
>>>> has been dropped
>>>>
>>>>
>>>> Regards,
>>>>
>>>>    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: [ANNOUNCE] Velocity Engine 2.0 RC6 test build available

[Claude Brisson <cl...@renegat.net>]

Oh, and Michael Osipov suggested a much easier way:

     import java.nio.Files;
     import java.nio.charset.StandardCharsets;
     ....
     String contents = new String(Files.readAllBytes(path), 
StandardCharsets.UTF_8);


   Claude

On 26/01/2017 15:42, Claude Brisson wrote:
> Hi Greg.
>
> Just include the commons-io library [1], then do:
>
>     import org.apache.commons.io.FileUtils;
>     ....
>     String content = FiileUtils.readFileToString(new File(filename), 
> Charset.UTF_8);
>
> The charset parameter is optional but recommended. Adapt it to your 
> needs, of course.
>
> [1] https://mvnrepository.com/artifact/commons-io/commons-io/2.5
>
>
>   Claude
>
> On 26/01/2017 14:52, Greg Huber wrote:
>> Hello,
>>
>> I use the taxen task, and now have a local copy as its no longer 
>> supported.
>>
>> What would be an equivalent to .fileContentsToString(..) as its now 
>> missing?
>>
>> org.apache.velocity.util.StringUtils
>>
>> value = StringUtils.fileContentsToString(
>> getProject().resolveFile(value)
>> .getCanonicalPath());
>>
>> Cheers Greg
>>
>>
>>
>> On 26 January 2017 at 03:39, Claude Brisson <cl...@renegat.net> wrote:
>>
>>> A new test build of Velocity Engine 2.0 is available (RC6).
>>>
>>> No determination as to the quality ('alpha,' 'beta,' or 'GA') of 
>>> Velocity
>>> Engine 2.0 has been made, and at this time it is simply a "test 
>>> build". We
>>> welcome any comments you may have, and will take all feedback into 
>>> account
>>> if a quality vote is called for this build.
>>>
>>> Release notes:
>>>
>>> * https://dist.apache.org/repos/dist/dev/velocity/velocity-eng
>>> ine/2.0/release-notes.html
>>>
>>> Distribution:
>>>
>>>   * 
>>> https://dist.apache.org/repos/dist/dev/velocity/velocity-engine/2.0/
>>>
>>> Maven 2 staging repository:
>>>
>>>   * https://repository.apache.org/content/repositories/orgapache
>>> velocity-1016/
>>>
>>> A vote regarding the quality of this test build will be initiated 
>>> within
>>> the next couple of days.
>>>
>>> Release Candidates changelog:
>>>    RC1: initial candidate
>>>    RC2: bugfixes
>>>    RC3: review SLF4J Logger names (instead of a single logger named
>>> "Velocity", have a hierarchy of loggers with a base of
>>> 'org.apache.velocity')
>>>    RC4: minor fixes
>>>    RC5:
>>>     * the default encoding is now UTF-8 (and not the platform default)
>>>     * commons-collections is not any more a compilation dependency
>>>     * commons-lang3 dependency is not any more shaded
>>>     * the configuration API doesn't reference ExtProperties
>>>     * the events API has been optimized and reviewed: all events do 
>>> receive
>>> the current Context
>>>     * there has been a few optimizations in ASTStringLiteral rendering
>>> RC6: mostly code cleaning and build process optimization ; assembly 
>>> module
>>> has been dropped
>>>
>>>
>>> Regards,
>>>
>>>    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: [ANNOUNCE] Velocity Engine 2.0 RC6 test build available

[Claude Brisson <cl...@renegat.net>]

Hi Greg.

Just include the commons-io library [1], then do:

     import org.apache.commons.io.FileUtils;
     ....
     String content = FiileUtils.readFileToString(new File(filename), 
Charset.UTF_8);

The charset parameter is optional but recommended. Adapt it to your 
needs, of course.

[1] https://mvnrepository.com/artifact/commons-io/commons-io/2.5


   Claude

On 26/01/2017 14:52, Greg Huber wrote:
> Hello,
>
> I use the taxen task, and now have a local copy as its no longer supported.
>
> What would be an equivalent to .fileContentsToString(..) as its now missing?
>
> org.apache.velocity.util.StringUtils
>
> value = StringUtils.fileContentsToString(
>                                          getProject().resolveFile(value)
>                                                  .getCanonicalPath());
>
> Cheers Greg
>
>
>
> On 26 January 2017 at 03:39, Claude Brisson <cl...@renegat.net> wrote:
>
>> A new test build of Velocity Engine 2.0 is available (RC6).
>>
>> No determination as to the quality ('alpha,' 'beta,' or 'GA') of Velocity
>> Engine 2.0 has been made, and at this time it is simply a "test build". We
>> welcome any comments you may have, and will take all feedback into account
>> if a quality vote is called for this build.
>>
>> Release notes:
>>
>> * https://dist.apache.org/repos/dist/dev/velocity/velocity-eng
>> ine/2.0/release-notes.html
>>
>> Distribution:
>>
>>   * https://dist.apache.org/repos/dist/dev/velocity/velocity-engine/2.0/
>>
>> Maven 2 staging repository:
>>
>>   * https://repository.apache.org/content/repositories/orgapache
>> velocity-1016/
>>
>> A vote regarding the quality of this test build will be initiated within
>> the next couple of days.
>>
>> Release Candidates changelog:
>>    RC1: initial candidate
>>    RC2: bugfixes
>>    RC3: review SLF4J Logger names (instead of a single logger named
>> "Velocity", have a hierarchy of loggers with a base of
>> 'org.apache.velocity')
>>    RC4: minor fixes
>>    RC5:
>>     * the default encoding is now UTF-8 (and not the platform default)
>>     * commons-collections is not any more a compilation dependency
>>     * commons-lang3 dependency is not any more shaded
>>     * the configuration API doesn't reference ExtProperties
>>     * the events API has been optimized and reviewed: all events do receive
>> the current Context
>>     * there has been a few optimizations in ASTStringLiteral rendering
>> RC6: mostly code cleaning and build process optimization ; assembly module
>> has been dropped
>>
>>
>> Regards,
>>
>>    Claude
>>
>>
>>


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

Re: [ANNOUNCE] Velocity Engine 2.0 RC6 test build available

[Greg Huber <gr...@gmail.com>]

Hello,

I use the taxen task, and now have a local copy as its no longer supported.

What would be an equivalent to .fileContentsToString(..) as its now missing?

org.apache.velocity.util.StringUtils

value = StringUtils.fileContentsToString(
                                        getProject().resolveFile(value)
                                                .getCanonicalPath());

Cheers Greg



On 26 January 2017 at 03:39, Claude Brisson <cl...@renegat.net> wrote:

> A new test build of Velocity Engine 2.0 is available (RC6).
>
> No determination as to the quality ('alpha,' 'beta,' or 'GA') of Velocity
> Engine 2.0 has been made, and at this time it is simply a "test build". We
> welcome any comments you may have, and will take all feedback into account
> if a quality vote is called for this build.
>
> Release notes:
>
> * https://dist.apache.org/repos/dist/dev/velocity/velocity-eng
> ine/2.0/release-notes.html
>
> Distribution:
>
>  * https://dist.apache.org/repos/dist/dev/velocity/velocity-engine/2.0/
>
> Maven 2 staging repository:
>
>  * https://repository.apache.org/content/repositories/orgapache
> velocity-1016/
>
> A vote regarding the quality of this test build will be initiated within
> the next couple of days.
>
> Release Candidates changelog:
>   RC1: initial candidate
>   RC2: bugfixes
>   RC3: review SLF4J Logger names (instead of a single logger named
> "Velocity", have a hierarchy of loggers with a base of
> 'org.apache.velocity')
>   RC4: minor fixes
>   RC5:
>    * the default encoding is now UTF-8 (and not the platform default)
>    * commons-collections is not any more a compilation dependency
>    * commons-lang3 dependency is not any more shaded
>    * the configuration API doesn't reference ExtProperties
>    * the events API has been optimized and reviewed: all events do receive
> the current Context
>    * there has been a few optimizations in ASTStringLiteral rendering
> RC6: mostly code cleaning and build process optimization ; assembly module
> has been dropped
>
>
> Regards,
>
>   Claude
>
>
>

Re: [ANNOUNCE] Velocity Engine 2.0 RC6 test build available

[Michael Osipov <mi...@apache.org>]

Am 2017-01-26 um 04:39 schrieb Claude Brisson:
> A new test build of Velocity Engine 2.0 is available (RC6).
>
> No determination as to the quality ('alpha,' 'beta,' or 'GA') of
> Velocity Engine 2.0 has been made, and at this time it is simply a "test
> build". We welcome any comments you may have, and will take all feedback
> into account if a quality vote is called for this build.
>
> Release notes:
>
> *
> https://dist.apache.org/repos/dist/dev/velocity/velocity-engine/2.0/release-notes.html
>
>
> Distribution:
>
>  * https://dist.apache.org/repos/dist/dev/velocity/velocity-engine/2.0/
>
> Maven 2 staging repository:
>
>  *
> https://repository.apache.org/content/repositories/orgapachevelocity-1016/
>
> A vote regarding the quality of this test build will be initiated within
> the next couple of days.

Hi Claude,

first of all, great improvement. Just checked the diff and have a few 
comments:

* Left a bunch of comments on the commits on GitHub, have a look
* StringUtils#EOL is never used
* StringUtils#normalizePath() can likely be replaced with Common IO's 
FilenameUtils#normalize()
* StringUtils#nullTrim() can be replaced with Commons Lang's 
StringUtils#trim()
* StringUtils#trimStrings() can be disposed altogether because it 
iterates the list and it is iterated right after the call again. Use 
StringUtils#trim() during the real iteration directly
* OSGi metadata are gone from Core, no Bundle-SymbolicName, no Exports, 
everything is gone from MANIFEST.MF
* There are several spots where collections are iterated with a for loop 
with a counter and #get(i) or a literal (legacy code). This should 
generally be avoided. One example has been commented on GitHub.
* Terrific improvement on the JavaCC code generation!
* JavaCC tells me:
> Note: UNICODE_INPUT option is specified. Please make sure you create the parser/lexer using a Reader with the correct character encoding.
> Warning: Choice conflict in [...] construct at line 1325, column 21.
>          Expansion nested within construct and expansion following construct
>          have common prefixes, one of which is: <TEXT>
>          Consider using a lookahead of 2 or more for nested expansion.
> Warning: Choice conflict in (...)* construct at line 2157, column 5.
>          Expansion nested within construct and expansion following construct
>          have common prefixes, one of which is: <WHITESPACE>
>          Consider using a lookahead of 2 or more for nested expansion.

Is this something one needs to take care of?


Michael

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@velocity.apache.org
For additional commands, e-mail: user-help@velocity.apache.org