Be notified of new releases
Create your free GitHub account today to subscribe to this repository for new releases and build software alongside 28 million developers.Sign up
The Lift Committers are pleased to announce the release of Lift 3.1.0-M3 on May 18, 2017. This release continues our new release cadence of bimonthly milestone builds, and is the last milestone build of the 3.1.0 series. One more pre-release build will be made, 3.1.0-RC1, around June 15th, with an eye towards a 3.1.0 final release near the end of June (depending on how the RC cycle goes). These will lead up to the final 3.1.0 milestone at the start of June. 3.1.0-RC1 is currently targeted for June 15, and the final 3.1.0 release targeted for the end of June. After that we'll start the release cycle over for 3.2.0 for the latter part of the year. You can follow the milestone progress in the Github milestone view.
With that, 3.1.0-M3 contains a few delicious nuggets:
- (#1845) Custom rendering of special Double values. Prior to M3, lift-json always serialized
NegativeInfinityas their respective string values (
Infinity). This is actually not correct JSON, as these are not supported JSON numeric values. Many if not most JSON parsers will choke on this output, including browser parsers. One notable exception is if anyone is
nullinstead, and provide a new
RenderSettingscustomization that allows you to switch back to the old rendering approach, or to switch to an approach that throws an exception if these special values are found (which can be paired with
tryoto produce a
Failurein these cases).
- (#1839) Closer to jQuery independence. Lift 3.0.0 debuted a new
liftVanillaa fully functional replacement for the jquery-dependent functionality needed for core Lift operations.
- (#1841) Fixed event extraction for page fragments. When event extraction was introduced in Lift 3, it did not take into account the possibility that a page fragment might be processed---for example, as a response to an AJAX request. As a result, in these cases, the events were extracted… But they were not re-transmitted through a separate channel. Instead, they were lost entirely. We now fix that, and page fragments with extracted events will properly reference the detached event handler code that will set those handlers up properly on the client.
- (#1842) Disabled event extraction for
JsExps that handle HTML go through
fixHtmlFunc, which is charged with preprocessing any embedded JS so it can be served correctly for client interpretation. Unfortunately, the interaction between this preprocessing and event extraction led to some broken and unexpected behavior. We're reasoning through a deeper fix, but in the meantime even when
fixHtmlFuncwill not do event extraction.
- (#1837, #1854) Removed
FileOutputStreamusage. @eltimn moved much of Lift's internal usage of
FileOutputStreamto their more GC-friendly
java.nioequivalents. See this Cloudbees post for the GC impact of the old streams. This change should have no impact on your code. If you find yourself having to recompile your code to work with this change, please let us know on the mailing list, as this is meant to be a purely internal change.
- (#1832) Fixed snippet class cache. Resolved a bug in how we cache snippet class instances that caused a performance hit when using the same snippet multiple times.
- (#1768) Improved handling of tuples in lift-json. Tuples can now be serialized and deserialized as heterogenous arrays in JSON instead of as objects. This feature is disabled by default to ensure we're not changing default behavior in Lift 3.1, but can be enabled by providing a
tuplesAsArraysset to true. The one caveat with this functionality is that it doesn't consistently support Scala primitives, so if you're using tuples inside a larger, more complex structure you'll want to use the Java boxed types instead of Scala primitives where applicable (so,
Int). However, if the tuple contains case classes you should be able to use primitives inside those without issue: this caveat only affects primitives directly in the tuple. The README for lift-json documents all of this, and Matt Farmer wrote a blog post demonstrating it in a more narrative style if that's more your thing.
- (#1791) Event return normalization. If handlers to
liftVanilla.onEventreturned false, we'd just return that value. Now, we now check for the existence of
event.preventDefaultand trigger it and
stopPropagationif the handler returned
false. We also return that return that
falsevalue for older browsers to work with.
- (#1838) Removed some deprecated rendering methods in lift-json.
- (#1853) Added Class caching for type hints in lift-json. This change should improve performance when the same type hint is seen multiple times by caching the
Classinstance we use for a particular type hint instead of invoking a class lookup each time.
The RC has a few more tidbits geared up to be included, and we're already planning for some good updates that will go into Lift 3.2 as well.
This release is immediately available on Maven Central (meaning it's actually been available since Thursday...) ;) Please let us know what you think on the mailing list!