jAlbum 17.1 is underway. Here's a beta for testing.
Changes:

• Introduced Groovy as scripting language. Once compiled, Groovy is faster than BeanShell, but initial textual parsing is far slower than BeanShell. For this reason I currently recommend using BeanShell or compiled Java for user interfaces, but Groovy at least makes Minimal skin process twice as fast (Groovy port of Minimal skin attached). Luckily you can use BeanShell or compiled Java for the UI and another scripting language (Groovy for instance) for the page processing. It's the name of the init file that determines the scripting language to use.
• Completely rewritten skin template parser. Potentially faster as templates are now parsed once to an internal object tree (Abstract Syntax Tree) and from there evaluated to final pages multiple times. The new parser not only caches the internal object tree, it also caches compiled scriptlets for scripting languages supporting this (JavaScript and Groovy. BeanShell doesn't compile well)
• Update image reading library to TwelveMonkeys 3.5 . Problematic CMYK JPEG images should now work again.

I've tested jAlbum's new template parser extensively, but as it is a complete rewrite, there may be bugs left, so please test this jAlbum version against your skins. So far I've only noticed that Chameleon breaks as the new template parser requires the new ${var} syntax for variables. The old $var syntax is from now on ONLY allowed for constants, like $text.textKey. We will release an updated Chameleon that runs on jAlbum 17.1.

The new template parser should be faster as it redoes less work than the old one. Please benchmark against your favorite projects. You should especially benefit from remaking albums with skins that produce separate slide pages.

Groovy support
The new Groovy support is a test. I'll decide later if we're going to keep it, and taking your input on it. It's an alpha release of Groovy 3.0, meaning that it nearly allows 100% of Java's syntax, so moving from BeanShell or plain Java to Groovy should be straight forward. Groovy 3 supports both Java's syntax for array initialization and lambda expressions as well as its own syntax. For other differences please see this page . Being a scripting language, Groovy just like BeanShell, has a syntax for checking the existence of a variable. The syntax is

binding.hasVariable("var")

. In BeanShell, the equivalent is like this:

var != void

. There is also another important difference that affects skin developers. Creating a typed variable, like this:

String author="David"

will create a local variable that is gone when the script is done executing. If you wish to be able to refer to that variable in other scriptlets, simply drop the type, so it becomes like this:

author="David"

You will notice that with Groovy, everything is shorter:

• You don't have to add semicolons between statements.
• Printing to the system console is as easy as writing

  println "That's cool"
  

  , but you can naturally use ordinary java syntax too:

  System.out.println("That's cool");
  

• Setter methods can be called using an "attribute" syntax, so instead of writing:

  window.setSize(new Dimension(400,400));
  

  you can write:

  window.size = new Dimension(400,400)
  

Those were just some small teasers. Open jAlbum's system console window to play around with Groovy!

Installers:
Windows: http://jalbum.net/download/jAlbum-install.exe
Mac: http://jalbum.net/download/jAlbum.dmg
Other: http://jalbum.net/download/jAlbum.zip

If you get errors making albums, patch your lib/jalbum-core.jar with this b2: http://jalbum.net/download/beta/jalbum-core.jar

(I don't get any errors, but Laza does)

I get an error when running external tools

Exception in thread "ScriptingThread" java.lang.NullPointerException
	at se.datadosen.jalbum.AlbumBean.processScript(AlbumBean.java:2465)
	at se.datadosen.jalbum.JExternalToolsMenu$ToolAction$1.run(JExternalToolsMenu.java:73)

This is with both the 17.1 beta and the update core (17.1B2)

That nullpointer bug should be fixed in b3 now. Get it from http://jalbum.net/download/beta/jalbum-core.jar

Tested with my two skins and also a bunch of others such as Hydrogen, MySkin, Fully, Responsive, Blu++ and not had a single error message.
I don't have massive projects but the ones I have are processed faster.

Had a little play with Groovy, using an example straight out of the documentation, I like it, could be a good alternative for writing external tools.

For your information, I remade some of my large folder albums with jAlbum v17 and v17.1b3 on a Windows 10 system and recorded the processing times:

My Frankrijk album made with the Slide Show 4 skin v17: 0:01:36 v17.1b3 0:01:32 (1035MB)
My Algarve album made with the FancyBox skin v17: 0:02:25 v17.1b3: 0:02:24 2nd time: 0:01:53 (2567MB)

In these cases no new images were made I think.

I did also some makes where the output directory was empty at the start:

Pieterpad album made with the PhotoSwipe skin : v17: 0:02:36 v17.1b3: 0:02:33 (241 MB)
Pieterpad album made with Minimal skin v17: 0:01:11 v17.1b3: 0:01:22
Pieterpad album made with MinimalGroovy skin en : v17.1b3: 0:01:19

But there is a problem with the new version:

I have in my skins in index.htt this statement:

<ja:include page="buttons.inc" />

Only the root album contains a file buttons.inc
In version 17 is this file only included in the top album, but in version v17.1b3 it is also included in the folder albums, which is incorrect. See this error in my Algarve album.

Another inconvenience:

If the album is ready, the ready window with the 3 buttons disappears sometimes if the album is ready.
To get it in view you have to click in the Explorer

Edited by: AndreWolff on 18-Nov-2018 11:25

Possible, but that is not the point:

A new version should be compatibel with the previous version.

And I could have a button.inc file in the root directory and in some folders with a different contents of buttons.inc

It is better that this is corrected once in the jAlbum program instead that it should be corrected in all skins using .inc-files.