【问题标题】:using iajc with java 1.8 JDK -- Comparator cannot be resolved to a type将 iajc 与 java 1.8 JDK 一起使用——无法将比较器解析为类型
【发布时间】:2015-02-24 08:38:52
【问题描述】:

我从事的项目的源代码在 Eclipse 中进行管理,但我们实际使用和发布的 .class 和 .war 文件是使用 ant 通过 build.xml 文件构建的。该代码在 Spring 环境中工作,并使用 AspectJ 进行一些编译时编织。我们使用 AspectJ 1.6 和 Java 1.6 已经有好几年了,但我们现在正在尝试转向使用 Java 1.8(我们一直在其中安装的一个 jboss 环境一直在使用 Java 1.6,但正在被迁移到 1.8;此外,我们还在努力将我们的应用程序与其他应用程序解耦,以便我们可以在提供 Java 1.8 的码头容器内独立运行),但在使用 AspectJ 和 Java 1.8 之间似乎存在问题。我发现了一些似乎与我们所看到的问题相关的帖子,尽管我没有发现其中任何一个提供了一个似乎符合我们特定构建情况的简单解决方案(那些确实有潜在解决方案的总是指代 maven 之类的东西或我们不使用的其他东西)。

这是我们在尝试使用 Zulu 的 Open JDK 8(Windows 为 8u31)进行编译时看到的错误输出:

 [iajc] C:\GitRepos\NSE_decouple\client\src\com\hp\nonstop\nse\test\cli\sort\PhysicalTargetListByName.java:5 [error] Comparator cannot be resolved to a type
 [iajc] public class PhysicalTargetListByName implements Comparator<String>
 [iajc]                                                  ^^^^^^^^^
 [iajc] C:\GitRepos\NSE_decouple\client\src\com\hp\nonstop\nse\test\cli\sort\PhysicalTargetListByName.java:5 [error] The type java.util.Comparator cannot be resolved. It is indirectly referenced from required .class files
 [iajc] public class PhysicalTargetListByName implements Comparator<String>

此错误中引用的特定代码(我怀疑其他代码也会失败,但此失败似乎会停止编译)是:

public class PhysicalTargetListByName implements Comparator<String>
{
<code not included; the declaration itself seems to be the failure point>
}

如果问题与使用aspectj1.6有关,我也安装了最新版本的AspectJ,即AspectJ 1.8.5,但没有任何区别。

在 Eclipse 本身内构建正常,但在尝试使用 ant 构建时出现错误,JAVA_HOME 设置为“c:\Program Files\Zulu\zulu-8”,IAJC_HOME 设置为“c:\aspectj1.8 " 在命令行执行“ant build”之前。在 build.xml 文件中,我们在构建目标任务中有以下步骤来执行 iajc 编译:

 <iajc destdir="${build.dir}" failonerror="true" 
     showWeaveInfo="${showWeaveInfo.isEnabled}" source="1.6" target="1.6"  
     debug="true"  fork="true"  maxmem="256m">
    <src path="${instsrc.dir}" />
    <exclude name="**/junit/*"/>
    <exclude name="**/install/*"/>
    <classpath refid="master-classpath"/>
    <aspectPath refid="aspectPath"/>
 </iajc>

我也尝试过将源和目标都设置为“1.8”,但这也没有区别。

build.xml 文件还包含:

<path id="aspectPath">
   <pathelement location="${lib.dir}/spring-aspects.jar"/>
</path>

<path id="master-classpath">
    <fileset dir="${lib.dir}">
        <include name="*.jar"/>
    </fileset>
    <fileset dir="${jetty.dir}/lib">
        <include name="servlet-api-3.0.jar"/>
        <include name="jetty-servlet-8.1.16.v20140903.jar"/>
        <include name="jetty-util-8.1.16.v20140903.jar"/>
    </fileset>
    <fileset dir="${jetty.dir}/lib/jsp">
        <include name="javax.servlet.jsp-2.2.0.v201112011158.jar"/>
    </fileset>
    <pathelement location="${clover.jar}"/>
    <pathelement path="${build.dir}"/>
</path>

我用 任务替换了 任务的实验,而是允许构建工作而没有错误(尽管生成的代码不会被编织),所以看起来错误与AspectJ 与 java 1.8 的混合(另一个实验表明我们可以在使用 Open JDK 7 和 AspectJ 时构建而不会出现错误)。

非常感谢您指出我们可能需要做些什么才能让 AspectJ 与 Java 1.8 构建一起工作!

【问题讨论】:

    标签: java ant aspectj


    【解决方案1】:

    经过一番摸索和一点点意外,我终于设法找到了导致我尝试的修复无法解决问题的原因。

    归结为我的%ANT_HOME%\lib 文件夹中存在 aspectjtools.jar 的副本。这个 JAR 已经在很多很多年(很多!)年前被放置在那里。它恰好是 JAR 的 AspectJ 1.6 版本,它的存在导致 ant 使用该版本,即使我们的 build.xml 文件在某些​​时候已被修改以指定 AspectJ 的路径,因此在 ant lib 下存在 JAR不需要确定要使用的版本(我最近改为指向 AspectJ 1.8,尽管文件的存在使我对 build.xml 的更改被忽略)。尽管我认为我现在将 AJ 1.8 与 Java 1.8 一起使用,但我没有,所以旧 AJ 和 Java 1.8 之间不兼容的所有基本问题仍然存在。

    从 ant lib 文件夹中删除该 JAR 后,我的 ant 构建按预期工作,没有错误!

    因此解决方法是删除一个不需要的文件,但到目前为止还没有引起明显的问题,因为我们多年前一直在使用 AJ 1.6。由于杂散文件的存在,更新到较新版本并没有真正生效。没有文件 ==> build.xml 配置生效 ==> 编译成功!

    【讨论】:

      猜你喜欢
      • 1970-01-01
      • 1970-01-01
      • 2019-11-21
      • 1970-01-01
      • 2018-06-30
      • 2012-01-09
      • 1970-01-01
      • 1970-01-01
      相关资源
      最近更新 更多