Search before asking
Fesod version
1.3.0
JDK version
17
Operating system
macOS 14.6
Steps To Reproduce
ExcelWriter writerA = FesodSheet
.write(new File(TestFileUtil.getPath() + "first.xlsx"), TestData.class)
.registerConverter(new ConverterA())
.build()
.finish();
ExcelWriter writerB = FesodSheet
.write(new File(TestFileUtil.getPath() + "second.xlsx"), TestData.class)
.build();
boolean hasCustomConverter = writerB.writeContext()
.currentWriteHolder()
.converterMap()
.values()
.stream()
.anyMatch(c -> c instanceof ConverterA);
writerB.finish();
assertFalse(hasCustomConverter, "Unregistered writer inherited converter from previous writer");
Current Behavior
Converters registered in one ExcelWriter leak to other ExcelWriter instances, even when the second writer doesn't register any custom converters.
Expected Behavior
Each ExcelWriter instance should have isolated converters. The second writer should only have default converters, not custom converters from the first writer.
Anything else?
Root cause
DefaultConverterLoader returns a direct reference to a static mutable map.
This shared reference gets mutated by AbstractWriteHolder when custom converters are registered, affecting all ExcelWriter instances.
Proposed fix
Fixing AbstractWriteHolder would address the symptom, but DefaultConverterLoader should return safe copies to prevent this class of bugs wherever the API is called.
- Make static maps immutable
private static final Map<ConverterKey, Converter<?>> defaultWriteConverter;
static {
Map<ConverterKey, Converter<?>> map = new HashMap<>();
// ...
defaultWriteConverter = Collections.unmodifiableMap(map);
}
- Return defensive copies:
public static Map<ConverterKey, Converter<?>> loadDefaultWriteConverter() {
return new HashMap<>(defaultWriteConverter);
}
Same issue exists in AbstractReadHolder.
Are you willing to submit a PR?
Search before asking
Fesod version
1.3.0
JDK version
17
Operating system
macOS 14.6
Steps To Reproduce
Current Behavior
Converters registered in one
ExcelWriterleak to otherExcelWriterinstances, even when the second writer doesn't register any custom converters.Expected Behavior
Each
ExcelWriterinstance should have isolated converters. The second writer should only have default converters, not custom converters from the first writer.Anything else?
Root cause
DefaultConverterLoaderreturns a direct reference to a static mutable map.This shared reference gets mutated by
AbstractWriteHolderwhen custom converters are registered, affecting allExcelWriterinstances.Proposed fix
Fixing
AbstractWriteHolderwould address the symptom, butDefaultConverterLoadershould return safe copies to prevent this class of bugs wherever the API is called.Same issue exists in
AbstractReadHolder.Are you willing to submit a PR?