@Shadowfiend Shadowfiend released this May 20, 2017 · 317 commits to master since this release

Assets 2

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 NaN, PositiveInfinity, and NegativeInfinity as their respective string values (NaN, -Infinity, 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 evaling JSON as JavaScript directly---but this is a very unsafe practice. As of M3, we default to rendering these as null instead, and provide a new RenderSettings customization 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 tryo to produce a Failure in these cases).
  • (#1839) Closer to jQuery independence. Lift 3.0.0 debuted a new liftVanilla provider of JavaScript functionality on the client with an eye towards removing the Lift jQuery dependency; unfortunately, that provider was somewhat incomplete. Amongst other things, loading it still required having jQuery loaded, or at least defined. We've removed this dependency now, and continue to work to make liftVanilla a 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 fixHtmlFunc. 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 LiftRules.extractInlineJavaScript is enabled, fixHtmlFunc will not do event extraction.
  • (#1837, #1854) Removed FileInputStream and FileOutputStream usage. @eltimn moved much of Lift's internal usage of FileInputStream and FileOutputStream to their more GC-friendly java.nio equivalents. 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 Formats object with tuplesAsArrays set 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, java.lang.Integer instead of 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.onEvent returned false, we'd just return that value. Now, we now check for the existence of event.preventDefault and trigger it and stopPropagation if the handler returned false. We also return that return that false value 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 Class instance 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!