Parsing problem of number literal 0x8000000000000000L

Details

Type: Bug
Status: Closed
Priority: Major
Resolution: Fixed
Affects Version/s: 2.0.0
Fix Version/s: 2.0.1, 2.1.0-beta-1
Component/s: Compiler
Labels:
None
Environment:
All

Number of attachments :
0

Description

I have the following small part of a java class:

    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. 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"

This has happened with Groovy 2.0 in relationship with Maven. It's this example https://github.com/khmarbaise/maui/tree/master/src/main/resources/g-ut-example which produces this problem. 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):

    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

Activity

Ascending order - Click to sort in descending order

Hide

Permalink

Tim Yates added a comment - 11/Jul/12 3:27 AM - edited

I guess this could be fixed by replacing

case 'l':
  return new Long( Long.parseLong(text, radix) );

with

case 'l':
  return new Long( new BigInteger( text, radix ).longValue() );

in org.codehaus.groovy.syntax.Numbers.parseInteger

But I always worry I've missed some sort of breaking change with low level stuff like this.

BTW: Andrew Taylor's answer to this question on Stackoverflow has links to the relevant part of the Java spec that allows this

Show

Tim Yates added a comment - 11/Jul/12 3:27 AM - edited I guess this could be fixed by replacing case 'l': return new Long ( Long .parseLong(text, radix) ); with case 'l': return new Long ( new BigInteger( text, radix ).longValue() ); in org.codehaus.groovy.syntax.Numbers.parseInteger But I always worry I've missed some sort of breaking change with low level stuff like this. BTW: Andrew Taylor's answer to this question on Stackoverflow has links to the relevant part of the Java spec that allows this

Hide

Permalink

Guillaume Laforge added a comment - 11/Jul/12 4:35 AM

Just for further look at the issue, just this simple example fails parsing in Groovy (no need for using Maven and/or the Eclipse compiler as indicated in the stacktrace):

long longNumber = 0x8000000000000000L

Show

Guillaume Laforge added a comment - 11/Jul/12 4:35 AM Just for further look at the issue, just this simple example fails parsing in Groovy (no need for using Maven and/or the Eclipse compiler as indicated in the stacktrace): long longNumber = 0x8000000000000000L

Hide

Permalink

Guillaume Laforge added a comment - 11/Jul/12 4:48 AM

Something that puzzles me... this number can't be a long, can it?
It won't fit in a long, so you'll get an overflow, and the number you actually get is some negative long number like -9223372036854775808.
Shouldn't Java and Groovy disallow that?

Show

Guillaume Laforge added a comment - 11/Jul/12 4:48 AM Something that puzzles me... this number can't be a long, can it? It won't fit in a long, so you'll get an overflow, and the number you actually get is some negative long number like -9223372036854775808. Shouldn't Java and Groovy disallow that?

Hide

Permalink

Tim Yates added a comment - 11/Jul/12 4:53 AM

The Java Specification specifically allows it though

The most negative hexadecimal, octal, and binary literals of type long - each of which represents the decimal value -9223372036854775808L (-2^63^) - are respectively:

0x8000_0000_0000_0000L, and

010_0000_0000_0000_0000_0000L, and

0b1000_0000_0000_0000_0000_0000_0000_0000_0000_0000_0000_0000_0000_0000_0000_0000L

Show

Tim Yates added a comment - 11/Jul/12 4:53 AM The Java Specification specifically allows it though The most negative hexadecimal, octal, and binary literals of type long - each of which represents the decimal value -9223372036854775808L (-2^63^) - are respectively: 0x8000_0000_0000_0000L, and 010_0000_0000_0000_0000_0000L, and 0b1000_0000_0000_0000_0000_0000_0000_0000_0000_0000_0000_0000_0000_0000_0000_0000L

Hide

Permalink

Guillaume Laforge added a comment - 11/Jul/12 4:54 AM

Actually Java allows that overflow, so I guess we should just do the same.

Show

Guillaume Laforge added a comment - 11/Jul/12 4:54 AM Actually Java allows that overflow, so I guess we should just do the same.

Hide

Permalink

Guillaume Laforge added a comment - 11/Jul/12 4:57 AM

I'll go with your proposed change Tim.

Show

Guillaume Laforge added a comment - 11/Jul/12 4:57 AM I'll go with your proposed change Tim.

Hide

Permalink

Tim Yates added a comment - 11/Jul/12 5:06 AM - edited

My proposed change might go too far as won't it allow:

long longNumber = 9223372036854775808L
// -9223372036854775808

Wheras Java would give:

long num = 9223372036854775808L ;
// EXCEPTION: Integer number too large

Show

Tim Yates added a comment - 11/Jul/12 5:06 AM - edited My proposed change might go too far as won't it allow: long longNumber = 9223372036854775808L // -9223372036854775808 ? Wheras Java would give: long num = 9223372036854775808L ; // EXCEPTION: Integer number too large

Hide

Permalink

Guillaume Laforge added a comment - 11/Jul/12 5:10 AM

Do you have a better suggestion?

Show

Guillaume Laforge added a comment - 11/Jul/12 5:10 AM Do you have a better suggestion?

Hide

Permalink

Tim Yates added a comment - 11/Jul/12 5:15 AM

Not without doing something like:

return radix == 10 ? 
                  new Long( Long.parseLong(text) ) :
                  new Long( new BigInteger(text, radix).longValue() ) ;

Or maybe Groovy should just handle overflows more leniently than Java?

Show

Tim Yates added a comment - 11/Jul/12 5:15 AM Not without doing something like: return radix == 10 ? new Long ( Long .parseLong(text) ) : new Long ( new BigInteger(text, radix).longValue() ) ; Or maybe Groovy should just handle overflows more leniently than Java?

Hide

Permalink

Guillaume Laforge added a comment - 11/Jul/12 5:21 AM

Yeah, it should allow at least what Java allows, and if it accepts more, it's okay I believe.

Show

Guillaume Laforge added a comment - 11/Jul/12 5:21 AM Yeah, it should allow at least what Java allows, and if it accepts more, it's okay I believe.

Hide

Permalink

Guillaume Laforge added a comment - 11/Jul/12 5:22 AM

Is there a similar change we should be doing to the integer case as well btw?

Show

Guillaume Laforge added a comment - 11/Jul/12 5:22 AM Is there a similar change we should be doing to the integer case as well btw?

Hide

Permalink

Tim Yates added a comment - 11/Jul/12 5:28 AM

Yeah, doing this:

int a = 0x80000000 // -2147483648

Works, but specifying an int in the number:

int a = 0x80000000i // BUG! exception in phase 'conversion'

Same problem... I guess here we'd need to parse as a Long and then drop it back to an Integer

My only concern is that I have a history of coming up with solutions like this, to later be shown by Paul or Jochen that the solution breaks existing stuff for a reason I didn't consider

Show

Tim Yates added a comment - 11/Jul/12 5:28 AM Yeah, doing this: int a = 0x80000000 // -2147483648 Works, but specifying an int in the number: int a = 0x80000000i // BUG! exception in phase 'conversion' Same problem... I guess here we'd need to parse as a Long and then drop it back to an Integer My only concern is that I have a history of coming up with solutions like this, to later be shown by Paul or Jochen that the solution breaks existing stuff for a reason I didn't consider

Hide

Permalink

Tim Yates added a comment - 11/Jul/12 5:39 AM

Would a neater solution be to change the switch at line 209 to:

BigInteger value = new BigInteger( text, radix );

switch (type)
{
    case 'i':
        return Integer.valueOf( value.intValue() );
    case 'l':
        return new Long( value.longValue() );
    case 'g':
        return value ;
    default:
        // If not specified, we will return the narrowest possible
        // of Integer, Long, and BigInteger.
        if( value.compareTo(MAX_INTEGER) <= 0 && value.compareTo(MIN_INTEGER) >= 0 )
        {
            return Integer.valueOf(value.intValue());
        }
        else if( value.compareTo(MAX_LONG) <= 0 && value.compareTo(MIN_LONG) >= 0 )
        {
            return new Long(value.longValue());
        }
        return value;
}

But as I said above, this will make the Groovy numeric specification more lenient with regards overflow than the Java one.

PS: Not sure why Integer.valueOf is used for Integers, but new Long for Longs (rather than Long.valueOf in the existing code (I have duplicated this style here as I assume there's a reason)

Show

Tim Yates added a comment - 11/Jul/12 5:39 AM Would a neater solution be to change the switch at line 209 to: BigInteger value = new BigInteger( text, radix ); switch (type) { case 'i': return Integer .valueOf( value.intValue() ); case 'l': return new Long ( value.longValue() ); case 'g': return value ; default : // If not specified, we will return the narrowest possible // of Integer , Long , and BigInteger. if ( value.compareTo(MAX_INTEGER) <= 0 && value.compareTo(MIN_INTEGER) >= 0 ) { return Integer .valueOf(value.intValue()); } else if ( value.compareTo(MAX_LONG) <= 0 && value.compareTo(MIN_LONG) >= 0 ) { return new Long (value.longValue()); } return value; } But as I said above, this will make the Groovy numeric specification more lenient with regards overflow than the Java one. PS: Not sure why Integer.valueOf is used for Integers, but new Long for Longs (rather than Long.valueOf in the existing code (I have duplicated this style here as I assume there's a reason)

People

Assignee:

Guillaume Laforge

Reporter:

Karl Heinz Marbaise

Vote (0)

Watch (4)

Dates

Created:

10/Jul/12 3:34 PM

Updated:

26/Jul/12 4:49 PM

Resolved:

11/Jul/12 11:58 AM