New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Catch Throwable
when using the AWT classes
#425
Conversation
`ERROR: java.lang.UnsatisfiedLinkError: no awt in java.library.path` is thrown when attempting to build a native image that depends on AWT on macOS. See the following issue for more details: - oracle/graal#4124
@@ -63,7 +63,7 @@ protected SXSSFSheet(SXSSFWorkbook workbook, XSSFSheet xSheet, int randomAccessW | |||
setRandomAccessWindowSize(randomAccessWindowSize); | |||
try { | |||
_autoSizeColumnTracker = new AutoSizeColumnTracker(this); | |||
} catch (InternalError e) { | |||
} catch (Throwable e) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this code should not affect poi-scratchpad - but I agree that Throwable is a safer type to catch here
git-svn-id: https://svn.apache.org/repos/asf/poi/trunk@1907308 13f79535-47bb-0310-9956-ffa450edef68
Can you close this? - I committed 040181c and there are a few more similar cases in the code that should probably be changed |
The catch you modified - that was only added recently and no release has ever included it. Are you sure that InternalError catch was not enough? |
Thanks, I noticed that |
Can you share the stack traces you are getting? I'd prefer not to be catch Throwables all over the place. |
Yes, I am sure. The thrown exception is |
Here is the stacktrace without the system property set:
|
Thanks - the exception name is enough for me - so UnsatisfiedLinkError is the issue |
Yes, as I mentioned in the first comment of this PR 😄 |
So I updated SheetUtil in 040181c - is that enough? That code had already been modified to catch UnsatisfiedLinkError (in April 2022). |
This is the stacktrace when the Caused by: java.lang.NoClassDefFoundError: Could not initialize class java.awt.Font
at java.desktop@17.0.5/java.awt.font.TextLayout.singleFont(TextLayout.java:468)
at java.desktop@17.0.5/java.awt.font.TextLayout.<init>(TextLayout.java:530)
at org.apache.poi.ss.util.SheetUtil.getCellWidth(SheetUtil.java:224)
at org.apache.poi.ss.util.SheetUtil.getCellWidth(SheetUtil.java:185)
at org.apache.poi.ss.util.SheetUtil.getColumnWidthForRow(SheetUtil.java:336)
at org.apache.poi.ss.util.SheetUtil.getColumnWidth(SheetUtil.java:280)
at org.apache.poi.ss.util.SheetUtil.getColumnWidth(SheetUtil.java:257)
at org.apache.poi.xssf.streaming.SXSSFSheet.autoSizeColumn(SXSSFSheet.java:1621)
at org.apache.poi.xssf.streaming.SXSSFSheet.autoSizeColumn(SXSSFSheet.java:1567) |
I think you also need to add catch any AWT operations in it, like |
Can you provide a stack trace where getFontAt fails? If that is failing, I think there will be loads of changes needed. Would it not be easier to install fonts yourself? |
The problem is that AWT is not available in a GraalVM native image built in MacOS because of oracle/graal#4124, so I get |
Wouldn't it be better to guard awt calls by checking for headless mode instead of catching UnsatisfiedLinkError? |
@xzel23 this issue is hard to test. I ran the SXSSF tests with GraalVM on my Mac and had no issues (with and without this code change). We have no POI road map for a POI 6 release that would allow us some latitude to refactor some code. Right now, we are sort of stuck with putting sticky plasters on the existing code base. In the end of the day catching Throwable instead of specific Errors means we are less likely to have someone with a different funky setup come along and say they have a different special Error happening. Since Errors are not declared in throws declarations, I think it is risky to depend on catching precise Errors. For me, SXSSFWorkbook should never have had a hard dependency on java.awt code. The auto column sizing feature should have been something that users should have had to enable explicitly. But introducing new API methods has its own problems. Stackoverflow questions for POI indicate a very large proportion of the user base are using very old versions of the libs. |
@pjfanning I see this as rather a GraalVM problem than a POI one. If you couldn't reproduce the problem on your Mac (the GraalVM issue has already been fixed on Windows but not on MacOS), it's probably because you used another GraalVM distribution. AFAIK, Bellsoft's has some support for AWT and this should work. If OP could confirm this works using Bellsoft's NIK (their GraalVM distribution), I would rather recommend not making these changes in POI. GraalVM folks seem to be working on fixing this in the original distribution, but so far it's not know what release it might get in. |
I managed to bypass the AWT issues by replacing the methods in the classes that use it. |
I reverted the bulk of my recent changes with 43551ba - the new code still treats UnsatisfiedLinkError as meaning AWT is not set up - as well as the pre-existing InternalError check. |
ERROR: java.lang.UnsatisfiedLinkError: no awt in java.library.path
is thrown when attempting to build a native image that depends on AWT on macOS.See the following issue for more details: