Chris, ensure that the filter has both a default, no args constructor and both getter and setter methods. The change made since v23.1 is that we now make a clone of the filter for each execution thread. For the cloning to work, there needs to be a no-args constructor and getter and setter methods corresponding to the JavaBeans spec.

The cloning is done to ensure that filters that contain state won't bug things when executed over multiple threads. Prior to v23 we used one single filter instance and synchronized the filter call, but this doesn't scale well when users have multiple CPU cores. v23 removed the synchronization and gained performance, but broke XBorderFilter (that contains state). v23.1 solved this by cloning filters for each execution thread.

The only side effect of this change I can imagine now (apart from filters needing to follow the JavaBean spec with regards to no-args constructor and getter/setter methods) is that no state is kept BETWEEN each filter() invocation (a new clone is used every time)

Edited by: davidekholm on 16-Feb-2021 20:06

Hi Chris,

The sample filter doesn't have any explicit constructor at all, that means that a no-args constructor is added implicitly by Java, but as soon as one adds one explicit constructor, the implicit no-args constructor is no longer added. To add one manually, simpy write public BppFrameHandler() {}

All filters under "plugins" work with the new scheme.

Chris, the code fails cause your BPPFrameHandler filter doens't follow the JavaBean specification. The full state of an instance of this class needs to be replicated by cloning the instance by calling getter and setter methods. Each class member variable needs a pair of getters and setters. Add the following to your source code and it should work:

    public Map<String, BPPFilterGroup> getFilterGroupMap() {
        return filterGroupMap;
    }
 
    public void setFilterGroupMap(Map<String, BPPFilterGroup> filterGroupMap) {
        this.filterGroupMap = filterGroupMap;
    }
 
    public int getApplyLevel() {
        return applyLevel;
    }
 
    public void setApplyLevel(int applyLevel) {
        this.applyLevel = applyLevel;
    }
 
    public int getApplyRatio() {
        return applyRatio;
    }
 
    public void setApplyRatio(int applyRatio) {
        this.applyRatio = applyRatio;
    }
 
    public File getConfigDir() {
        return configDir;
    }
 
    public void setConfigDir(File configDir) {
        this.configDir = configDir;
    }
 
    public AlbumBean getEngine() {
        return engine;
    }
 
    public void setEngine(AlbumBean engine) {
        this.engine = engine;
    }
 
    public Base getBase() {
        return base;
    }
 
    public void setBase(Base base) {
        this.base = base;
    }
 
    public File getSkinDirectory() {
        return skinDirectory;
    }
 
    public void setSkinDirectory(File skinDirectory) {
        this.skinDirectory = skinDirectory;
    }

Now that's a lot of code, but it's also how the JavaBean spec looks. Future Java versions will have shorter syntax for such simple getters/setters. Note, jAlbum has always documented requirement to follow this specification, but it's perhaps only with v23.1 that things break if your don't.

As it's so laborious to manually write these getters and setters, Netbeans automates it for you if you keep the cursor on the line where a class member variable is declared and then hit CTRL+I and select "getter and setter" from the popup menu. That's how I had this code generated.

I saw your instruction to add "getter and setter methods corresponding to the JavaBeans spec" but I didn't know what that meant.

I use Eclipse. I checked the menus and found an option "Source / Generate getters and setters". I chose this and now the code is updated.

Now it is time to test.

I tested the updated class with the additional getters and setters. I tested in 23.2 and 23.0.0. In both cases it failed with the same errors. These are the errors in 23.2

An unexpected error occurred. Please see detailed description below:
 
java.lang.RuntimeException: java.io.IOException: java.io.IOException: java.io.IOException: java.lang.NullPointerException
	at se.datadosen.jalbum.AlbumBean.getImageSettingsHash(AlbumBean.java:916)
	at se.datadosen.jalbum.AlbumBean.makeAlbum(AlbumBean.java:2874)
	at se.datadosen.jalbum.AlbumBean.makeAlbum(AlbumBean.java:2823)
	at se.datadosen.jalbum.JAlbumFrame$6.run(JAlbumFrame.java:1128)
Caused by: java.io.IOException: java.io.IOException: java.io.IOException: java.lang.NullPointerException
	at se.datadosen.jalbum.JSONEncoder.serialize(JSONEncoder.java:89)
	at se.datadosen.jalbum.JSONEncoder.serialize(JSONEncoder.java:61)
	at se.datadosen.jalbum.JSONEncoder.serialize(JSONEncoder.java:52)
	at se.datadosen.jalbum.JSONEncoder.serialize(JSONEncoder.java:24)
	at se.datadosen.jalbum.AlbumBean.getImageSettingsHash(AlbumBean.java:914)
	... 3 more
Caused by: java.io.IOException: java.io.IOException: java.lang.NullPointerException
	at se.datadosen.jalbum.JSONEncoder.serialize(JSONEncoder.java:89)
	at se.datadosen.jalbum.JSONEncoder.serialize(JSONEncoder.java:80)
	... 7 more
Caused by: java.io.IOException: java.lang.NullPointerException
	at se.datadosen.jalbum.JSONEncoder.serialize(JSONEncoder.java:89)
	at se.datadosen.jalbum.JSONEncoder.serialize(JSONEncoder.java:80)
	... 8 more
Caused by: java.lang.NullPointerException
	at se.datadosen.jalbum.JSONEncoder.serialize(JSONEncoder.java:74)
	... 9 more

I have given up on this.

BPPFilterGroup also implements JAFilter. It is in a hierarchy that has CompiledBase at the top; which doesn't have a no-args constructor.

Untangling all this would take time and require a complete re-test.

Anybody who uses BPP will have to install jAlbum 23.

Well my skin which has several filters (some of which are quite complex when it comes to options) is now broken too. See below for my comments (I'll possibly reply to other comments too).

Note that I don't have any errors in the log. I also already have a no-args constructor. I also have getters and setters but I don't known if they're all used. Is this required? For example do I have to use a getter every time I refer to a variable in the class? That seems silly to me and would make the code even uglier yet looking at it I think I do do that at least in the one filter I am testing (the others I know don't work but I am pretty sure I also use setters and getters).


Well as I said my ReflectionFilter does have getters and setters and a no args constructor and it's not working correctly (it does filter images but it's really weird and definitely wrong). Now I can upload it here or in a different post if you wan though I warn you it's kind of big and it does refer to another filter or maybe two that are much more complicated (well one is much more complicated) and I don't think you'd want to look at them anyway.

Would you please implement a feature that this will work on single threads? Because as you can see it's not only Chris's filter that is broken; I have several that are broken and I imagine there are others that are also broken. I find it very annoying and all the more since I also just updated my subscription when now it seems useless and pointless to even have the option of updating jAlbum; it's as if I spent the money for no reason.

Additionally I already do have getters/setters and no arg constructor and unless I'm doing something wrong (and I wasn't doing anything wrong before!) I don't see what else I'm supposed to do. Frustratingly you don't seem to have the documentation updated as Chris pointed out. That's not good.

I'm too tired to tell right now but this might actually affect one of my filters... Which is also annoying.

So to recap:

• Would you please implement a feature that allows the old style to work?
• What do I do if I already have what you say is needed and it still does not work? Something seems off again unless I have missed something. Do you want me to upload the filter source code here or in another thread?
• I'm really upset that I just spent the money to renew my subscription only for it to be that my filters no longer work due to (one can assume) no longer allowing single thread execution (and almost immediately making the marking of synchronization pointless). That's very annoying as I don't have a lot of money to begin with and last year when I returned it was only for the filters I wrote!
• Why wasn't this in the changelog? Or did I miss it? I don't think I did but I did see the synchronization keyword (or whatever it is called in Java) needed to be done and I did that. But this change wasn't added to changelog which means that filters silently stopped working on newer versions of jAlbum. Not really a good thing.

If I seem annoyed it's because I am both annoyed and frustrated. I don't mean the above to be aggressive and if it sounds like it is I apologise but I do have a lot going on and I am rather annoyed that I spent money for something that appears to be a waste of not only money but time fixing code that isn't actually broken (or wasn't broken).

Please advise.