TagOptionSingleton in a multithreaded environment

Issue #224 new
Dan Gravell created an issue

Just came up against an issue when setting genres in ID3 files. In some cases, I want to set the genre to a lower case format of a standard ID3 genre. For example "dance" instead of "Dance". By default, JAT will perform a case insensitive lookup for "dance", resolve "(3)" as the code and write that... which means the standard reading of the field will still be "Dance".

It is possible to control this and set TagOptionSingleton.getInstance().setWriteMp3GenresAsText(true). This way the field will be set to "dance".

The trouble with this is in a multi threaded environment, multiple threads may be calling the API at the same time, and not all of those threads might want this setting.

I guess what'd be good is some sort of API that allows this to be passed down as an option for each call.

Comments (5)

  1. IJabz repo owner

    First I have to ask why do you want to write lower case versions ?

    The trouble with passing it as an option, is you end up having to pass it through too alot of classes/methods. The multithreadig argument could be applied to almost all the options in the TagOptionSingleton class, but really is there a real world case where your multi threaded application wants to write as text for some files and not text for others, its seems to me you would want the consistency of same approach for all your files.

  2. Dan Gravell reporter

    Because that's what some people want to do! The example above is "real world" - it comes from a support email. Another model may be to prefer ID3 IDs where possible, and use custom text in other cases.

    Yeah, agree, it makes the API less elegant. Would be nice if Java had Scala's implicits. But on the other side I consider singleton an anti-pattern because of issues around concurrency and coupling, and I think in non-trivial cases we're going to run into issues using them.

    I'm not necessarily advocating an important, immediate change, more just recording this in case others think the same.

  3. IJabz repo owner

    Its theoretical in the sense that you don't seem to have an a sensible usecase for needing this. The TagOptionSingleton is designed be called once to specify options before read/writing a sense of files, it shoud n't be called every time you read/write a file. It shoud n't be called by more than one thread at a time.

  4. Log in to comment