java.awt.FontFormatException: java.nio.BufferUnderflowException

文章讨论了在Java中使用Font.createFont方法时遇到BufferUnderflowException的问题,原因在于同一输入流被两次用于创建不同大小的字体,导致输入流耗尽。解决办法是为每次创建新的字体分配独立的输入流。
Font awardFont = Font.createFont(Font.TRUETYPE_FONT, awardFontFile).deriveFont(120f).deriveFont(Font.BOLD);

使用如上语句创建字体时出现问题。java.awt.FontFormatException: java.nio.BufferUnderflowException异常表明在处理字体数据时出现了缓冲区下溢(Buffer Underflow)的情况。这通常发生在尝试读取字体数据时,缓冲区的容量比所需数据少,导致无法从缓冲区中读取足够的字节。可能问题如下:

  • 字体文件损坏:字体文件可能已损坏或不完整,导致字体数据无法完全读取。尝试使用其他字体文件,或者重新下载/获取字体文件。

  • 字体加载方式:检查字体文件的加载方式。您可以尝试使用不同的方式加载字体文件,例如直接从文件系统加载而不是从JAR文件中加载,或者通过URL加载字体文件。

  • 字体格式不兼容:确保字体文件的格式受Java支持。常见的受支持格式包括TrueType (.ttf)和OpenType (.otf)。如果字体文件不是这些格式之一,可能会导致异常。

我的错误均不是这些问题,比较低级。原本是根据文件创建字体,改为输入流后对应代码逻辑没有进行更改,导致某一段代码中,使用同一个流创建了两个字体,这会导致第一个输入流创建完之后遇到了输入流的尾部,导致第二个字体无法被正确创建。

【修改前】

InputStream footSongFontFile = getClass().getResourceAsStream(Constants.FONT_PATH + "SanJiZiHaiSongGBK-2.ttf");
Font footSongFont = Font.createFont(Font.TRUETYPE_FONT, footSongFontFile).deriveFont(60f);
Font _footSongFont = Font.createFont(Font.TRUETYPE_FONT, footSongFontFile).deriveFont(50f);

【修改后】

InputStream footSongFontFile = getClass().getResourceAsStream(Constants.FONT_PATH + "SanJiZiHaiSongGBK-2.ttf");
InputStream _footSongFontFile = getClass().getResourceAsStream(Constants.FONT_PATH + "SanJiZiHaiSongGBK-2.ttf");
Font footSongFont = Font.createFont(Font.TRUETYPE_FONT, footSongFontFile).deriveFont(60f);
Font _footSongFont = Font.createFont(Font.TRUETYPE_FONT, _footSongFontFile).deriveFont(50f);
Exception in thread "AWT-EventQueue-0" java.lang.NullPointerException at java.awt.Container.addImpl(Container.java:1095) at java.awt.Container.add(Container.java:975) at nc.starter.ui.AppletViewer$3.done(AppletViewer.java:123) at javax.swing.SwingWorker$5.run(SwingWorker.java:737) at javax.swing.SwingWorker$DoSubmitAccumulativeRunnable.run(SwingWorker.java:832) at sun.swing.AccumulativeRunnable.run(AccumulativeRunnable.java:112) at javax.swing.SwingWorker$DoSubmitAccumulativeRunnable.actionPerformed(SwingWorker.java:842) at javax.swing.Timer.fireActionPerformed(Timer.java:313) at javax.swing.Timer$DoPostEvent.run(Timer.java:245) at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:311) at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:758) at java.awt.EventQueue.access$500(EventQueue.java:97) at java.awt.EventQueue$3.run(EventQueue.java:709) at java.awt.EventQueue$3.run(EventQueue.java:703) at java.security.AccessController.doPrivileged(Native Method) at java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:74) at java.awt.EventQueue.dispatchEvent(EventQueue.java:728) at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:205) at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:116) at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:105) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:93) at java.awt.EventDispatchThread.run(EventDispatchThread.java:82)
最新发布
10-12
<think>我们正在处理一个NullPointerException异常,该异常出现在线程"AWT-EventQueue-0"中,堆栈涉及nc.starter.ui.AppletViewer。用户之前启用了安全管理器来限制NC65访问Windows目录,因此这个异常可能与权限限制有关。 分析: 1. NullPointerException通常发生在尝试访问一个空引用的成员(方法或字段)时。 2. 由于启用了安全管理器,可能导致某些资源(如文件、网络等)访问被拒绝,进而导致某些对象未能正确初始化,最终引发空指针。 解决步骤: 步骤1:确认异常发生的位置 查看完整的异常堆栈,确定是AppletViewer的哪一行代码抛出了NullPointerException。例如,堆栈中会显示类似“at nc.starter.ui.AppletViewer.someMethod(AppletViewer.java:123)”的信息。 步骤2:分析堆栈中的代码 在出现异常的代码行,检查哪些对象可能为null。常见的可能包括: - 文件读取返回null(因为安全管理器阻止了文件访问) - 网络连接返回null - 其他受安全管理器影响的资源获取 步骤3:检查安全管理器的策略文件 由于我们之前添加了禁止访问Windows目录的策略,可能过度限制了NC65正常运行所需的权限。需要检查策略文件(nc65.policy)是否包含了必要的权限。 步骤4:添加必要的权限 根据NC65的需求,在策略文件中添加相应的权限。例如: - 如果NC65需要读取某些配置文件,则添加读取这些文件的权限。 - 如果NC65需要访问网络,则添加SocketPermission。 步骤5:启用安全管理器的调试信息 在启动参数中添加安全调试参数,以获取更详细的信息: - `-Djava.security.debug=access,failure` 这将输出安全管理器检查权限的详细信息,帮助定位被拒绝的权限。 步骤6:测试与验证 重新启动NC65,观察是否还会出现NullPointerException。如果异常消失,则说明问题解决;如果仍有异常,则根据新的堆栈信息继续调整策略文件。 具体到当前问题,NullPointerException发生在AppletViewer中,可能与加载资源(如音频文件、图片或其他文件)有关。因为之前我们禁止了Windows目录的访问,而NC65可能需要访问其他目录(如临时目录、用户主目录等)来加载资源。 建议在策略文件中添加以下权限(根据实际需要调整): - 允许读取用户主目录(通常是启动NC65的用户的主目录): permission java.io.FilePermission "${user.home}/-", "read"; - 允许读取临时目录: permission java.io.FilePermission "${java.io.tmpdir}/-", "read"; permission java.io.FilePermission "${java.io.tmpdir}", "read"; - 允许访问代码库和类路径相关的资源(通常需要读取JAR文件所在目录): permission java.io.FilePermission "<<ALL FILES>>", "read"; // 谨慎使用,或者替换为具体路径 // 或者指定NC65安装目录: permission java.io.FilePermission "C:/path/to/nc65/-", "read"; 注意:不要过度授权,遵循最小权限原则。 另外,如果异常是由于音频文件加载失败引起的(参考用户之前提供的Applet例子),那么可能需要添加对音频文件所在目录的读取权限。但在NC65中,可能不是音频文件,而是其他资源。 由于堆栈涉及AppletViewer,考虑可能是小程序在初始化时加载资源失败。因此,我们需要在策略文件中添加对资源目录的访问权限。 示例策略文件(nc65.policy)调整: ```java grant { // 基础权限 permission java.util.PropertyPermission "user.home", "read"; permission java.util.PropertyPermission "java.io.tmpdir", "read"; permission java.util.PropertyPermission "user.dir", "read"; // 允许读取用户主目录和临时目录 permission java.io.FilePermission "${user.home}/-", "read"; permission java.io.FilePermission "${java.io.tmpdir}/-", "read"; permission java.io.FilePermission "${java.io.tmpdir}", "read"; // 允许读取NC65安装目录(假设安装在D:/nc65) permission java.io.FilePermission "D:/nc65/-", "read"; // 允许必要的网络访问(如果需要) permission java.net.SocketPermission "*", "connect"; // 其他必要的权限,如运行时权限 permission java.lang.RuntimePermission "modifyThread"; permission java.lang.RuntimePermission "accessClassInPackage.sun.*"; // 禁止访问Windows目录 permission java.io.FilePermission "C:\\Windows\\-", "deny"; }; ``` 步骤7:如果问题仍然存在 如果NullPointerException仍然出现,则可能是由于安全管理器阻止了某些操作,导致对象初始化失败。此时,需要查看安全管理器的调试输出(通过启动参数`-Djava.security.debug=access,failure`),找到被拒绝的权限,然后在策略文件中添加相应的权限(如果该权限是安全的且必要的)。 另一种方法:在策略文件中暂时移除deny规则,观察问题是否消失。如果消失,则说明确实是deny规则导致资源访问失败,需要仔细调整deny规则的范围,或者通过更精确的allow规则来替代全局deny。 重要:在调整策略文件后,务必重新启动NC65应用。 总结:NullPointerException可能是由于安全管理器阻止了NC65加载某些资源导致的,需要逐步添加必要的权限,并观察异常是否消失。 §§相关问题§§ 1. 如何获取Java安全管理器的详细调试信息? 2. 如何编写最小权限的Java策略文件? 3. 除了安全管理器,还有哪些方法可以限制Java应用的权限? </think>### 解决 `NullPointerException` 与安全管理器限制问题分析 该异常发生在 `nc.starter.ui.AppletViewer` 线程中,结合安全管理器限制策略,问题可能由以下原因引起: #### 1. **关键权限缺失导致初始化失败** ```java // 示例策略文件缺失的权限 grant { permission java.lang.RuntimePermission "accessClassInPackage.sun.*"; // 缺失AWT所需权限 permission java.util.PropertyPermission "java.home", "read"; // 缺失JRE路径读取权限 }; ``` - **问题本质**:安全管理器阻止了AWT组件访问`sun.*`包或JRE系统属性,导致`AppletViewer`初始化时核心对象为`null` - **验证方法**:在启动参数添加调试标志 `-Djava.security.debug=access,failure` 观察日志中是否有`access denied`警告 #### 2. **Windows目录限制引发的连锁反应** ```java // 过度限制的策略 permission java.io.FilePermission "C:\\Windows\\-", "deny"; ``` - **潜在冲突**:NC65可能需访问Windows系统目录下的字体文件(如`C:\Windows\Fonts`)或临时文件 - **解决方案**:细化权限控制 ```java // 放行字体目录但禁止其他 permission java.io.FilePermission "C:\\Windows\\Fonts\\-", "read"; permission java.io.FilePermission "C:\\Windows\\-", "deny"; ``` #### 3. **AWT事件队列初始化失败** 异常堆栈显示在`AWT-EventQueue-0`线程,需检查: 1. 是否缺少UI组件所需权限: ```java permission java.awt.AWTPermission "accessEventQueue"; permission java.awt.AWTPermission "showWindowWithoutWarningBanner"; ``` 2. 是否因文件访问拒绝导致资源加载失败: ```java // 示例错误代码 Image icon = Toolkit.getDefaultToolkit().getImage("C:\\Windows\\system.ini"); // 被阻止访问 ``` ### 解决步骤 1. **临时禁用安全管理器验证** 移除启动参数中的`-Djava.security.manager`,确认NC65能否正常运行 2. **添加必要权限到策略文件** ```java grant { // AWT核心权限 permission java.awt.AWTPermission "*"; permission java.lang.RuntimePermission "accessClassInPackage.sun.*"; // 文件系统最小权限 permission java.io.FilePermission "${user.home}${/}-", "read"; permission java.io.FilePermission "${java.io.tmpdir}${/}-", "read,write"; // 系统属性读取 permission java.util.PropertyPermission "java.home", "read"; permission java.util.PropertyPermission "os.name", "read"; }; ``` 3. **增量式权限调试(关键步骤)** ```bash java -Djava.security.manager \ -Djava.security.debug=access:failure \ -Djava.security.policy==nc65.policy \ -jar nc65.jar ``` - 根据输出的`access denied`记录逐个添加权限 - 重点关注涉及`java.awt.`和`sun.awt.`的权限请求 4. **修复空指针的具体代码位置** 在异常堆栈指向的类中(如`AppletViewer.java:123`)添加空值检查: ```java // 修复示例 public void initView() { if (SecurityManager != null) { SecurityManager.checkPermission(new AWTPermission("accessEventQueue")); } // 原始初始化代码 } ``` ### 替代方案 如果权限配置过于复杂,可改用系统级限制: ```powershell # Windows目录访问限制(需管理员权限) icacls C:\Windows /deny "Netease\NC65_User:(RX)" ``` 此方法不影响JVM内部权限模型,但需协调系统管理员操作[^1]。 > **根本解决路径**:通过安全调试日志定位被拒绝的具体操作,在策略文件中精确添加最小必要权限,避免使用全局`deny`规则阻断核心功能依赖[^2]。 ---
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

Insight.

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值