No, I meant if the skin has Beanshell scripts (for old jAlbums) and Groovy scripts (for recent jAlbums), will the correct scripts be chosen automatically?
It seems like this would be an unreliable technique, since early versions of Groovy were unreliable.

Edited by: ctwist on 21 Sep 2022, 19:06

However, if old versions of jAlbum give preference to Beanshell scripts (when Groovy scripts are also provided), this behaviour should be changed in future versions of jAlbum to give preference to Groovy scripts.
This would allow a skin to provide Beanshell scripts for jAlbum pre-29, and Groovy scripts for 29+.

Edited by: ctwist on 21 Sep 2022, 19:13
And an old unmaintained skin without Groovy scripts would work with jAlbum 29+ (unless it uses a Java feature that is incompatible with Beanshell in Java 18).

Edited by: ctwist on 21 Sep 2022, 19:22
https://www.youtube.com/watch?v=UOHMg7IkzHU

You can currently have one script language for the UI and another for album processing, but there's no fallback.

What seems to trigger the problem with BeanShell is the tighter module system of Java 18.
Take this piece of code for instance that executes fine in Groovy, but not in BeanShell:

ge = GraphicsEnvironment.getLocalGraphicsEnvironment();
for (String s: ge.getAvailableFontFamilyNames()) {
	System.out.println(s);
}

The "ge" object is an instance of the public class sun.awt.CGraphicsEnvironment, but it resides in the now private module "sun.java2d" so access to public classes within it from the outside is forbidden, BUT as it implements an open abstract class called java.awt.GraphicsEnvironment, it should be possible to call methods declared in java.awt.GraphicsEnvironment on it. getAvailableFontFamilyNames() is one such call. Unfortunately, BeanShell tries to call getAvailableFontFamilyNames via the closed class sun.awt.CGraphicsEnvironment instead of doing it via its open abstract class java.awt.GraphicsEnvironment.

Here are possible solutions:

• Wrap such objects inside Java compiled wrappers
• Move to Groovy (recommended). It's usually easier than you think
• Add a command line flag. In this case: --add-exports sun.java2d/sun.awt=UNNAMED_MODULE

I'm not particularly keen on solving this by adding these --add-exports calls. They break the very idea with Java's module system and may eventually be disallowed, + I don't know just how many such statements will be needed.

jAlbum 29, and this beta should already be running Groovy 4

I might have a working BeanShell fix for you.

I took a deep plunge in the BeanShell internals and made a quick hack. The hack at least covers this case that has shown up, and hopefully that's enough. The change I've made is to modify the code that figures out that method to call. BeanShell usually tries to call the most specific method (that's what object orientation dictates), but in case the super class's method is abstract (i.e. not implemented) I return that one instead. I don't see any harm in this as the call will eventually end up in the implementation. It's only if you have a hierarchy of real overloaded methods that you wish the sub class's version to be called.

This hack might have some side effect that I'm not able to foresee, so please test it with various skins. It seems to behave here

To try it, remove (or move to another location) lib/bsh-2.2.0.jar and add the attached version instead.

I think you replied to the wrong poster, because I have no BeanShell problem.

I don’t follow completely what is discussed here, should all skins using BeanShell now be converted to Groovy if you release this beta?

A.k.a. "taking a nap."

Some thoughts about the path forward, part II....

This leaves the problem of the orphaned and otherwise abandoned skins that are still, nevertheless, in the non-legacy skin repository. If, say, jAlbum 30 has no BeanShell support, they just won't work. I would suggest that any skin whose developer won't step up to the plate and revise it, should be moved to the legacy bin (there are already good reasons for moving a lot of them now, in any case).

What about the user who wants the latest and greatest jAlbum, and the lastest and greatest skins that work with it, but still wants to use one of the old dogs for a few old projects? Running multiple versions of jAlbum on a Mac is simple, so that user could have jAlbum 28 and jAlbum 30, and just launch jAlbum 28 when he wants to tinker with an old project.

It's a little messier on Windows because of some colliding registry entries, but I think I've ID'ed the one situation in which it actually causes problems. If you install both jAlbum 19 and jAlbum 29, then decide to remove jAlbum 19, suddenly jAlbum 29 doesn't know what a .jap file is, or a .jaskin file. In short, it loses its file associations. Quickly remedied by reinstalling jAlbum 29, but it's a pain.

The other potential problem with running multiple versions of jAlbum is that they're all sharing a common config directory. I haven't encountered any misbehavior there, but if a future version of jAlbum makes some radical changes to the way the config directory is handled, it could be a problem.

Another solution would be to retain some trace of BeanShell, just to handle the legacy skins. Not available in the console, not mentioned in the documentation anywhere, but lurking quietly. Frankly, I prefer a clean sweep.

Or here's a radical idea: a separate app, called jAlbumBS (I like it! ). It would really just be a clone of jAlbum 28, riding on Java 14. It would never be updated - it would just remain available for the user of a legacy skin. It would have its own config directory, so a user could install only the skins that work with it (and wouldn't "pollute" jAlbum 30 with old skin installs).