Thread Locked This thread is locked - replies are not allowed.



Permlink Replies: 150 - Pages: 11 [ Previous | 1 ... 4 5 6 7 8 9 10 | Next ] - Last Post: 27 Sep 22, 21:55 Last Post By: davidekholm Threads: [ Previous | Next ]
ctwist

Posts: 471
Registered: 27-Sep-2003
Re: jAlbum on Java 18
Posted: 22 Sep 22, 01:03   in response to: JeffTucker in response to: JeffTucker
JeffTucker wrote:
ctwist wrote:
Would a Groovy-compatible version of jAlbum automatically choose the Groovy scripts?

It already does. If the template files are, e.g., init.bsh, it runs BeanShell. If they're init.groovy, it runs Groovy. It takes its cue solely from the file names.

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
JeffTucker

Posts: 7,994
Registered: 31-Jan-2006
Re: jAlbum on Java 18
Posted: 22 Sep 22, 02:10   in response to: ctwist in response to: ctwist
Let's wait and see what David has in mind. Otherwise, this is all just idle speculation.
davidekholm

Posts: 3,432
Registered: 18-Oct-2002
Re: jAlbum on Java 18
Posted: 22 Sep 22, 12:12   in response to: ctwist in response to: ctwist
ctwist wrote:
If you move to Groovy, which versions of jAlbum are compatible with a Groovied skin?

Can a skin contain both Groovy and Beanshell scripts, for compatibility with old versions of jAlbum? Would a Groovy-compatible version of jAlbum automatically choose the Groovy scripts?


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

Posts: 3,432
Registered: 18-Oct-2002
Re: jAlbum on Java 18
Posted: 22 Sep 22, 12:13   in response to: RobM in response to: RobM
RobM wrote:
JeffTucker wrote:
ctwist wrote:
If you move to Groovy, which versions of jAlbum are compatible with a Groovied skin?

Groovy was introduced in jAlbum 17.1, but with the caveat that it was an experimental version of Groovy. I'd be cautious with it before jAlbum 19 or 19.2.

I'd go for jAlbum 25.1 as a minimum, that was the last update of Groovy.

The older Groovy versions were pretty good too, so I'd be optimistic and say that skins that move to Groovy will probably only require v17.1
davidekholm

Posts: 3,432
Registered: 18-Oct-2002
Re: jAlbum on Java 18
Posted: 22 Sep 22, 12:47   in response to: davidekholm in response to: davidekholm
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.
RobM

Posts: 3,802
Registered: 4-Aug-2006
Re: jAlbum on Java 18
Posted: 22 Sep 22, 12:47   in response to: davidekholm in response to: davidekholm
davidekholm wrote:
The older Groovy versions were pretty good too, so I'd be optimistic and say that skins that move to Groovy will probably only require v17.1
Can I interest you in updating to Groovy 4?
davidekholm

Posts: 3,432
Registered: 18-Oct-2002
Re: jAlbum on Java 18
Posted: 22 Sep 22, 13:24   in response to: RobM in response to: RobM
RobM wrote:
davidekholm wrote:
The older Groovy versions were pretty good too, so I'd be optimistic and say that skins that move to Groovy will probably only require v17.1
Can I interest you in updating to Groovy 4?

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

Posts: 1,292
Registered: 14-Dec-2007
Re: jAlbum on Java 18
Posted: 22 Sep 22, 13:28   in response to: JeffTucker in response to: JeffTucker
JeffTucker wrote:
Edited by: JeffTucker on 21 Sep 2022, 13:29 to make it clear that I'm not volunteering to convert anyone else's skins!
No, you have only to give a good recipe how to do that!
davidekholm

Posts: 3,432
Registered: 18-Oct-2002
Re: jAlbum on Java 18
Posted: 22 Sep 22, 14:25   in response to: AndreWolff in response to: AndreWolff
Attachment bsh-2.2.1.jar (390.3 KB)
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.
RobM

Posts: 3,802
Registered: 4-Aug-2006
Re: jAlbum on Java 18
Posted: 22 Sep 22, 15:03   in response to: davidekholm in response to: davidekholm
davidekholm wrote:
RobM wrote:
davidekholm wrote:
The older Groovy versions were pretty good too, so I'd be optimistic and say that skins that move to Groovy will probably only require v17.1
Can I interest you in updating to Groovy 4?

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

Short term memory failure, rebooting the OS. ;)
AndreWolff

Posts: 1,292
Registered: 14-Dec-2007
Re: jAlbum on Java 18
Posted: 22 Sep 22, 15:12   in response to: davidekholm in response to: davidekholm
davidekholm wrote:
I might have a working BeanShell fix for you.
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?
davidekholm

Posts: 3,432
Registered: 18-Oct-2002
Re: jAlbum on Java 18
Posted: 22 Sep 22, 15:35   in response to: AndreWolff in response to: AndreWolff
AndreWolff wrote:
davidekholm wrote:
I might have a working BeanShell fix for you.
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?


I'd recommend that, but check out whether the fix I made is enough.
JeffTucker

Posts: 7,994
Registered: 31-Jan-2006
Re: jAlbum on Java 18
Posted: 22 Sep 22, 15:44   in response to: RobM in response to: RobM
RobM wrote:
...rebooting the OS. ;)

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

Posts: 7,994
Registered: 31-Jan-2006
Re: jAlbum on Java 18
Posted: 22 Sep 22, 15:47   in response to: JeffTucker in response to: JeffTucker
Some thoughts about the path forward, part I....

The Prime Directive: BeanShell is heading for "abandonware" status. BeanShell 2 has problems with newer Java versions, and BeanShell 3 seems to be a unicorn. jAlbum should move towards eliminating it from its codebase, and rely on compiled Java, Groovy, and maybe Javascript. Laza is using Javascript for a lot of his stuff, but Java support seems to fall into the "Gee, which JS engine will we try this time?" category.

For the truly active skins (developer still present, new versions coming out at least once in a while), that leaves two things that need to be addressed.

  • The remaining interpreted onload.bsh routines need to be redone as compiled Java. BeanShell is a dog for UI's (especially if you use anonymous inner classes), and the rumor is that Groovy is even worse at it, so probably no one should go there. Among the active skins, there's only a handful of these, and they're pretty simple, with one glaring exception. H-P once indicated that he'd like to compile the CA2 onload.bsh - I took a look at it, felt woozy, and had to go lie down in a darkened room with a damp washcloth on my forehead.
  • The BeanShell templates need to be revised for Groovy. Note that I say "revised," and not "rewritten." From what I've seen so far, 99% of the code can remain untouched, and the remaining 1% falls into no more than half-a-dozen types, each of which can be quickly fixed (defining utility methods, checking for void, using arrays, etc.). David is right - it's easier than anyone thinks.
JeffTucker

Posts: 7,994
Registered: 31-Jan-2006
Re: jAlbum on Java 18
Posted: 22 Sep 22, 15:49   in response to: JeffTucker in response to: JeffTucker
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).
Legend
Forum admins
Helpful Answer
Correct Answer

Point your RSS reader here for a feed of the latest messages in all forums