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

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

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

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

SlimerDude Mon 1 Feb

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()

Login or Signup to reply.