问题描述
我在使用 istack-commons-runtime-3.0.11/4.0.0 罐子时遇到以下错误。还尝试按照一些博客的建议使用较低版本的 JAR,但没有奏效。
错误: java.lang.NoSuchMethodError: com.sun.istack.localization.LocalizableMessageFactory.(Ljava/lang/String;Lcom/sun/istack/localization/LocalizableMessageFactory$ResourceBundlesupplier;)V]
任何形式的帮助将不胜感激。
解决方法
刚刚遇到了一个类似的kidda问题,我就是这样解决的。以下步骤是添加库的有效方法。我已经正确地完成了前两个步骤,但是我没有通过将“.jar”文件直接从文件系统拖到我的 eclipse 项目上的“lib”文件夹中来完成最后一个步骤。此外,我必须从构建路径和“lib”文件夹中删除先前版本的库。
步骤 1 - 添加 .jar 到构建路径 在此处输入图片说明
第 2 步 - 关联源代码和 javadoc(可选) 在此处输入图片说明
第 3 步 - 实际将 .jar 文件拖入“lib”文件夹(非可选)
,这是istack-commons-runtime-4.0.0的内容:
如您所见,它有您所需要的。因此,如果您收到 NoSuchMethod 错误,则意味着您的库中某处存在另一个冲突版本。
/*
* Copyright (c) 1997,2018 Oracle and/or its affiliates. All rights reserved.
*
* This program and the accompanying materials are made available under the
* terms of the Eclipse Distribution License v. 1.0,which is available at
* http://www.eclipse.org/org/documents/edl-v10.php.
*
* SPDX-License-Identifier: BSD-3-Clause
*/
package com.sun.istack.localization;
import java.util.Locale;
import java.util.ResourceBundle;
/**
* @author WS Development Team
*/
public class LocalizableMessageFactory {
private final String _bundlename;
private final ResourceBundleSupplier _rbSupplier;
@Deprecated
public LocalizableMessageFactory(String bundlename) {
_bundlename = bundlename;
_rbSupplier = null;
}
public LocalizableMessageFactory(String bundlename,ResourceBundleSupplier rbSupplier) {
_bundlename = bundlename;
_rbSupplier = rbSupplier;
}
public Localizable getMessage(String key,Object... args) {
return new LocalizableMessage(_bundlename,_rbSupplier,key,args);
}
public interface ResourceBundleSupplier {
/**
* Gets the ResourceBundle.
* @param locale the requested bundle's locale
* @return ResourceBundle
*/
ResourceBundle getResourceBundle(Locale locale);
}
}
如果您使用 Maven,请打开您的 IDE(Eclipse/Intellij),打开您的 pom.xml 文件,然后查看您的依赖项并过滤 istack,看看是否有包含作为传递依赖项的较低版本。
在 Eclipse 中,单击 pom.xml --> 依赖项 --> 在过滤器中输入 istack。
示例:
,NoSuchMethodError 表示您的类路径中存在不兼容的版本。
您需要检查类路径中的所有 jar 是否存在重复的类。
JAXB 的问题在于,它被许多供应商为 Java11 重新打包,现在您可以找到多个互不兼容的实现。这是一项丑陋的任务,尤其是许多第三方库鲁莽地声明对特定 JAXB 实现的依赖(在 maven 的情况下,除“提供”之外的其他范围)。
我遇到了同样的问题,就我而言,jaxb-impl 根本不应该出现在类路径中(因为我使用的是由 glassfish 打包的较新版本)。