java.lang.String is immutable and cannot be overwritten by user.
When passing sensitive data as context variable String remains in memory until GC removes it.
CharSequence allows user to provide his own implementation and overwrite data as needed.
I'm not disabling it by default because that would change behavior for anyone
who was using reflection, which seems like annoying breakage. People who are
using JMustache with Java 9 can configure a non-coercing DefaultCollector to
eliminate the illegal access warnings.
We now have to build with JDK9 or above, but I believe that the built jar files
continue to be compatible with JDK 1.7 or above. If this turns out not to be
the case, please let me know.
First, I missed some reference checks when I stopped interning names. Fixed
those.
Second, when iterating over an array which contained null elements, the wrong
thing was happening.
Me, on the blackboard:
"I will not optimize code without using a profiler."
"I will not optimize code without using a profiler."
"I will not optimize code without using a profiler."
"I will not optimize code without using a profiler."
"I will not optimize code without using a profiler."
...
Allows a lambda to execute a template in the lambda's own context. This enables
'late bound' template inclusion where the lambda can select a template based on
dynamic data in the context at the time it is executed.
Closes#92.
This ensures that if you enter a conditional block while inside a list
block, the list "state" from the outer list will still be visible. For
example (somewhat contrived, but gets the point across):
{{#list}}
{{#name}}{{-index}}. {{.}}{{/name}}
{{^name}}{{-index}}. No name!{{/name}}
{{/list}}
Yields something like:
1. Bob
2. Mary
3. No name!
4. Jim
Fixes#90.
You can't normally reflectively access methods on Map because it has a
special fetcher, but being able to reflectively access 'entrySet' is
super useful when you want to iterate over the keys+values of a map, so
we're going to hack it in there. Ha!
There's unfortunately no sane way to do the same reflection-like array access
in GWT, so we just have to enumerate all of the primitive types.
I could have just left this only in the Java backend, but I would prefer to
avoid differences between behavior on the JVM and behavior in GWT whenever
possible.
Fortunately this did not require using any JDK 1.8-specific APIs, just
searching (via reflection) through the set of interfaces implemented by a class
in addition to its super-classes.
One downside is that the transitive set of all implemented interfaces could be
much larger than the super-class chain, but this is the last thing we search,
so in theory we only even get here if we were about to fail to find the getter
entirely.
This also means that our tests have to be compiled and run with Java 8, because
I was not in the mood to figure out how to do all the complex Maven jockeying
to have a special JDK8 profile and disable JDK8 tests in the normal profile and
re-enable them in the JDK8 profile and blah blah blah, just shoot me now.
Section behavior used to be somewhat hackily determined from nullValue and
defaultValue, but it was messy. Now it has its own configuration and things are
more explicit.
Previously missing/null sections were treated as false, but if you set
nullValue to something, then missing sections became an error, but null
sections remained false. If you set defaultValue to something, missing sections
went back to being omitted. Kooky.
Now missing sections are omitted, unless you set strictSections to true, in
which case they become an error. nullValue and defaultValue have no impact on
section behavior.
There is no way to make null sections an error, but I don't see any demand for
that, so I'm going to leave that as a TODO.
Closes#60.
Mainly we also needed to trim around comment tags, but also there were a bunch
of tricky edge cases that were only partially addressed. This is some edgy
business!
Michael Bayne