Jim Procter

make AlignFrame the parent of FeatureEditor dialog, and have parent Component request focus after...
make AlignFrame the parent of FeatureEditor dialog, and have parent Component request focus after...
JAL-3975 forced re-focus to alignframe after Create Sequence Feature dialog.
JAL-3975 forced re-focus to alignframe after Create Sequence Feature dialog.
JAL-3691 patch toUpper/toLower to use Locale.ROOT for 2.11.2 src
JAL-3691 patch toUpper/toLower to use Locale.ROOT for 2.11.2 src
AWESOME JOB !!!! one tiny niggle I had was that Cache.debug/Cache.error doesn't read nicely, so I've abstracted the logging stuff even farther to a new jalview.bin.Console class: see https://source...

AWESOME JOB !!!! one tiny niggle I had was that Cache.debug/Cache.error doesn't read nicely, so I've abstracted the logging stuff even farther to a new jalview.bin.Console class: see https://source.jalview.org/crucible/changelog/~br=update%402fJAL-3949_jalview_bin_Console_to_cure_sanity_even_more/jalview/

the reason for conditionals is that Java won't perform the string append operation if logLevel>debug. It saves a minor amount of processing time which is important for code that is executed lots.

the reason for conditionals is that Java won't perform the string append operation if logLevel>debug. It saves a minor amount of processing time which is important for code that is executed lots.

You could have .getLogger(Class ..) rather than having to call getCanonicalName ?

You could have .getLogger(Class ..) rather than having to call getCanonicalName ?

JAL-3949 An attempt at converting to Log4j 2 -- no output achieved!
JAL-3949 An attempt at converting to Log4j 2 -- no output achieved!
JAL-3553: Create working getdown appbase and jvl file(s) for each old version of Jalview
JAL-3553: Create working getdown appbase and jvl file(s) for each old version of Jalview
I'm abandoning this review for now (see my comments on the issue). For what its worth since this is a string literal you should at least follow convention JALVIEW_LOGGER rather than a generic 'LOGG...

I'm abandoning this review for now (see my comments on the issue). For what its worth since this is a string literal you should at least follow convention JALVIEW_LOGGER rather than a generic 'LOGGER_NAME'. The code for routing logged content from other loggers should probably be a method on Cache... or even better, separate all this out into the jalview.util.Log4j class so Cache doesn't get polluted with log configuration cruft.

Does this really need to be a string constant ? (I'm not convinced) needs documenting as the log4j internal name for the log if it really needs to be external.

Does this really need to be a string constant ? (I'm not convinced) needs documenting as the log4j internal name for the log if it really needs to be external.

JAL-3949 An attempt at converting to Log4j 2 -- no output achieved!
JAL-3949 An attempt at converting to Log4j 2 -- no output achieved!
I know the problems you had with close() - you mentioned in the comments on the issue. However, you might have noticed that FileParse.close() is not called from many places, so changing its behavio...

I know the problems you had with close() - you mentioned in the comments on the issue. However, you might have noticed that FileParse.close() is not called from many places, so changing its behaviour wouldn't have too many side effects.

The intended pattern for FileParse.close() was:

ParserThing pt;
try {
pt = new <? assignable to FileParse>(data spec..)
.. do whatever needed to trigger parsing
.. then check pt's error/warning status and report any problems.
} catch (IOException ..) {
.. handle read or parse errors 
}
finally {
if (pt!=null) {
pt.close();
} // catch and report any IOErrors if desired
}
Ideally, any low level file ops should happen in the base class (FileParse) rather than here. AlignFile should call the FileParse.close() method rather than directly manipulate dataIn, which is man...

Ideally, any low level file ops should happen in the base class (FileParse) rather than here. AlignFile should call the FileParse.close() method rather than directly manipulate dataIn, which is managed by FileParse. Note that FileParse.close() nulls the dataIn reference so the stream can be garbage collected properly.

It's also good practice to try to close() in a finally {} clause, catching and reporting exceptions if needed... this is actually what the FileParse.close() method's design was intended for, since the caller should have already checked 'error' and 'errormessage' for parsing problems. Exceptions/Errors on close are not fatal for file import.

file close error will trash import of project

file close error will trash import of project

close filehandles straight after parse, without setting an error
close filehandles straight after parse, without setting an error
JAL-3933 Updated log4j jars with log4j-2.16.0 and compatibility API log4j-1.2-api-2.16.0. Stripped...
JAL-3933 Updated log4j jars with log4j-2.16.0 and compatibility API log4j-1.2-api-2.16.0. Stripped...
one class with a static factory method seems to be better than two classes and an external mutable object.

one class with a static factory method seems to be better than two classes and an external mutable object.

yes, I see that, but do you really need a nested static class ? in line with my general comments re encapsulating the Map<String,SequenceInfo> further: perhaps it might make sense to simply apply a...

yes, I see that, but do you really need a nested static class ? in line with my general comments re encapsulating the Map<String,SequenceInfo> further: perhaps it might make sense to simply apply a factory pattern rather than have an internal bean that a generic map holds references to ?

(lets not get stuck on this though, the main thing is that the implementation works fine for now, though needs more work in order to save/restore sequenceInfo objects from Jalview project files)