[英]Groovy Conversion - From Java
I have the following small part of a java class: 我有一个java类的以下小部分:
public class GBitMaskTest {
@Test
public void checkFirstBitTest() {
BitMask bm = new BitMask(0x8000000000000000L);
assertEquals(true, bm.isBitSet(63));
}
...
}
which should be compilable in Groovy as well cause it's valid Java code. 哪个应该可以在Groovy中编译,因为它是有效的Java代码。 But i get the following:
但我得到以下内容:
Groovy Bug --- exception in phase 'conversion' in source unit '/home/g-ut-example/src/test/groovy/com/soebes/training/maven/simple/GBitMaskTest.groovy' For input string: "8000000000000000"
BUG! exception in phase 'conversion' in source unit '/home/g-ut-example/src/test/groovy/com/soebes/training/maven/simple/GBitMaskTest.groovy' For input string: "8000000000000000"
May be i misunderstand a thing. 可能是我误解了一件事。 Someone an idea?
有人有想法吗?
This has happened with Groovy 2.0 in relationship with Maven. 这与Groovy 2.0与Maven的关系已经发生了。 It's this example https://github.com/khmarbaise/maui/tree/master/src/main/resources/g-ut-example which produces this problem.
这个例子是https://github.com/khmarbaise/maui/tree/master/src/main/resources/g-ut-example ,它会产生这个问题。 I'm compiling with the following part:
我正在编译以下部分:
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<configuration>
<compilerId>groovy-eclipse-compiler</compilerId>
<compilerArgument>nowarn</compilerArgument>
<verbose>true</verbose>
</configuration>
<dependencies>
<dependency>
<groupId>org.codehaus.groovy</groupId>
<artifactId>groovy-eclipse-compiler</artifactId>
<version>2.7.0-01</version>
</dependency>
<dependency>
<groupId>org.codehaus.groovy</groupId>
<artifactId>groovy-eclipse-batch</artifactId>
<version>2.0.0-01</version>
</dependency>
</dependencies>
</plugin>
</plugins>
</build>
The rest of the error message (EXception): 其余的错误消息(EXception):
GBitMaskTest.groovy' For input string: "8000000000000000"
at org.codehaus.groovy.control.CompilationUnit.applyToSourceUnits(CompilationUnit.java:1001)
at org.codehaus.groovy.control.CompilationUnit.doPhaseOperation(CompilationUnit.java:624)
at org.codehaus.groovy.control.CompilationUnit.processPhaseOperations(CompilationUnit.java:600)
at org.codehaus.groovy.control.CompilationUnit.compile(CompilationUnit.java:577)
at org.codehaus.jdt.groovy.internal.compiler.ast.GroovyCompilationUnitDeclaration.processToPhase(GroovyCompilationUnitDeclaration.java:171)
at org.codehaus.jdt.groovy.internal.compiler.ast.GroovyParser.dietParse(GroovyParser.java:455)
at org.codehaus.jdt.groovy.integration.internal.MultiplexingParser.dietParse(MultiplexingParser.java:44)
at org.eclipse.jdt.internal.compiler.Compiler.internalBeginToCompile(Compiler.java:775)
at org.eclipse.jdt.internal.compiler.Compiler.beginToCompile(Compiler.java:395)
at org.eclipse.jdt.internal.compiler.Compiler.compile(Compiler.java:485)
at org.eclipse.jdt.internal.compiler.batch.Main.performCompilation(Main.java:3829)
at org.eclipse.jdt.internal.compiler.batch.Main.compile(Main.java:1682)
at org.codehaus.groovy.eclipse.compiler.GroovyEclipseCompiler.compile(GroovyEclipseCompiler.java:243)
at org.apache.maven.plugin.AbstractCompilerMojo.execute(AbstractCompilerMojo.java:678)
at org.apache.maven.plugin.TestCompilerMojo.execute(TestCompilerMojo.java:161)
at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
at org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:320)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:141)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)
at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352)
Caused by: java.lang.NumberFormatException: For input string: "8000000000000000"
at java.lang.NumberFormatException.forInputString(NumberFormatException.java:48)
at java.lang.Long.parseLong(Long.java:422)
at org.codehaus.groovy.syntax.Numbers.parseInteger(Numbers.java:215)
at org.codehaus.groovy.antlr.AntlrParserPlugin.integerExpression(AntlrParserPlugin.java:3184)
at org.codehaus.groovy.antlr.AntlrParserPlugin.expressionSwitch(AntlrParserPlugin.java:2153)
at org.codehaus.groovy.antlr.AntlrParserPlugin.expression(AntlrParserPlugin.java:2018)
at org.codehaus.groovy.antlr.AntlrParserPlugin.expression(AntlrParserPlugin.java:2008)
at org.codehaus.groovy.antlr.AntlrParserPlugin.expressionSwitch(AntlrParserPlugin.java:2046)
at org.codehaus.groovy.antlr.AntlrParserPlugin.expression(AntlrParserPlugin.java:2018)
at org.codehaus.groovy.antlr.AntlrParserPlugin.expression(AntlrParserPlugin.java:2008)
at org.codehaus.groovy.antlr.AntlrParserPlugin.addArgumentExpression(AntlrParserPlugin.java:3071)
at org.codehaus.groovy.antlr.AntlrParserPlugin.arguments(AntlrParserPlugin.java:2994)
at org.codehaus.groovy.antlr.AntlrParserPlugin.constructorCallExpression(AntlrParserPlugin.java:2932)
at org.codehaus.groovy.antlr.AntlrParserPlugin.expressionSwitch(AntlrParserPlugin.java:2069)
at org.codehaus.groovy.antlr.AntlrParserPlugin.expression(AntlrParserPlugin.java:2018)
at org.codehaus.groovy.antlr.AntlrParserPlugin.expression(AntlrParserPlugin.java:2008)
at org.codehaus.groovy.antlr.AntlrParserPlugin.declarationExpression(AntlrParserPlugin.java:1776)
at org.codehaus.groovy.antlr.AntlrParserPlugin.variableDef(AntlrParserPlugin.java:1792)
at org.codehaus.groovy.antlr.AntlrParserPlugin.statement(AntlrParserPlugin.java:1513)
at org.codehaus.groovy.antlr.AntlrParserPlugin.statementListNoChild(AntlrParserPlugin.java:1599)
at org.codehaus.groovy.antlr.AntlrParserPlugin.statementList(AntlrParserPlugin.java:1574)
at org.codehaus.groovy.antlr.AntlrParserPlugin.methodDef(AntlrParserPlugin.java:1045)
at org.codehaus.groovy.antlr.AntlrParserPlugin.objectBlock(AntlrParserPlugin.java:800)
at org.codehaus.groovy.antlr.AntlrParserPlugin.innerClassDef(AntlrParserPlugin.java:783)
at org.codehaus.groovy.antlr.AntlrParserPlugin.classDef(AntlrParserPlugin.java:677)
at org.codehaus.groovy.antlr.AntlrParserPlugin.convertGroovy(AntlrParserPlugin.java:361)
at org.codehaus.groovy.antlr.AntlrParserPlugin.buildAST(AntlrParserPlugin.java:269)
at org.codehaus.groovy.control.SourceUnit.convert(SourceUnit.java:302)
at org.codehaus.groovy.control.CompilationUnit$3.call(CompilationUnit.java:706)
at org.codehaus.groovy.control.CompilationUnit.applyToSourceUnits(CompilationUnit.java:992)
... 35 more
I'm surprised this compiles in Java, since 0x8000000000000000L is larger than Long.MAX_VALUE
. 我很惊讶这是用Java编译的,因为0x8000000000000000L大于
Long.MAX_VALUE
。 It looks like Java treats it as an unsigned value. 看起来Java将其视为无符号值。 I'd recommend using -0x8000000000000000L instead, since it's the same bit value, but falls within the legal range for longs and works in both Java and groovy.
我推荐使用-0x8000000000000000L,因为它是相同的位值,但是在long的合法范围内并且在Java和groovy中都有效。
Edit: According to the Java Language Specification §3.10.1 , decimal literals above Long.MAX_VALUE
are illegal but hexidecimal literals aren't , so long as they fit in 64 bits. 编辑:根据Java语言规范§3.10.1 ,上述小数文字
Long.MAX_VALUE
是非法的,但十六进制文字都没有 ,只要他们适合在64位。 So this appears to be valid Java. 所以这似乎是有效的Java。
声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.