Blog Post

#2813 Build 1.0.75

brian Mon 24 Aug 2020

We have posted a new Fantom build.

This is the first complete build cycle since moving from BitBucket+Mercurial to GitHub+Git.

Actor Framework

Several improvements have been made to the concurrent APIs.

The Future API is now abstract to allow custom implementations. A static factory named makeCompletable will create a future which you can call complete on yourself. We are using Java's terminology of CompletableFuture but with only one public class. Java's CompletableFuture API roughly corresponds to JavaScript promises. The Java implementation of Future now implements java.util.concurrent.Future so it can be used interchangeably with Java native code. There is now another separate internal subclass of Future used for actor sends.

The cooperative multi-tasking scheduler used by Actors has been redesigned. Previously actors yielded their thread whenever a certain number of messages had been processed. Now actors yield their thread based on processing time and only when other actors are waiting for access to a thread. There is a nodoc option ActorPool.maxTimeBeforeYield which defaults to 5sec. This should provide more equitable and performant throughput for messages when actors are contending for a limited number of threads.


We are introducing a new class web::FilePack to make it easier to deploy Fantom JS files to the browser. The heart of this new API is a suite of static utility methods to build up a list of CSS and JS files for deployment. Depending your deployment you can use these files however you want. To make it easy use web::FilePack.makeFiles to serve up one or more files as a single HTTP URI with built-in support for ETag/Last-Modified for 304 optimization.

Change Log

Build 1.0.75 (24 Aug 2020)

  • Move repo from BitBucket to GitHub
  • List addNotNull, mapNotNull, findNotNull
  • Map addNotNull, mapNotNull, findNotNull
  • Deprecated List.addIfNotNull, Map.addIfNotNull
  • domkit: Add DropTarget.onLeave callback
  • Updates to original documentation
  • Actors now yield based on time instead of msg count
  • Actor improved diagnostics
  • ActorPool.balance experimental method
  • Future is now abstract
  • Pod flattenDepends, orderByDepends
  • Remove JS fixed sourceMappingURL in favor of SourceMap header
  • New web::FilePack class
  • Add opts to Zip.writeNext
  • New math pod
  • #2428: Remove actor message serialization
  • #2669: js: Ordered map is unordered after serialization
  • #2726: Serialising Nested Maps
  • #2770: JS: Type methods (undefined)
  • #2781: Proposal to remove Xmx512M as default option
  • #2809: JS: Depend.equals()
  • #2810: JS: Decimal.toStr()

SlimerDude Sat 30 Jan 2021

Should the new methods:

  • List.findNotNull()
  • Map.findNotNull()

perhaps instead be called:

  • List.findAllNotNull()
  • Map.findAllNotNull()

as the current find() method returns a single item whereas findAll() returns a new list with multiple items.

It would also help those using autocomplete to find the new findAllNotNull() when they've typed findAll.

brian Sun 31 Jan 2021

Maybe, although I certainly don't feel strong enough about it personally to deprecate those and rename them all. We've always had findType too - pretty much every findXXX is going to be a list result. But if everyone else thinks its worth trying to make more consistent, I'm open to changing them

andy Mon 1 Feb 2021

Seems like they ought to be prefixed. But the naming convention ship might have already sailed for the List class...

SlimerDude Mon 1 Feb 2021

With the magic of @NoDoc, nobody need ever know!

@NoDoc @Deprecated { msg="Use findAllNotNull() instead" }
List findNotNull()

** Return a new list with all null items removed. 
List findAllNotNull()

brian Fri 7 May 2021

I did some more brainstorming with Matthew on the findNotNull vs findAllNotNull. Some pros and cons:

  • findAllNotNull: more technically correct
  • findAllNotNull: could potentially free up findNotNull for finding the first non-null single value (if we wanted both versions)
  • findNotNull: but is there ever a use case for finding just a first single non-null value?
  • findNotNull: slightly more terse and easier to read
  • findNotNull: consistent with findType which has been in the API forever
  • findNotNull: what is already there and working today

All said, we both lean slightly towards keeping it as findNotNull. More thoughts?

go4 Fri 7 May 2021

removeNull, filterOutNull

Login or Signup to reply.