Bug 32809 - Several printf format flags are unhandled by java.util.Formatter
Summary: Several printf format flags are unhandled by java.util.Formatter
Status: ASSIGNED
Alias: None
Product: classpath
Classification: Unclassified
Component: classpath (show other bugs)
Version: 0.95
: P3 normal
Target Milestone: ---
Assignee: Andrew John Hughes
URL:
Keywords:
: 36434 (view as bug list)
Depends on:
Blocks:
 
Reported: 2007-07-18 14:13 UTC by Ian Rogers
Modified: 2013-07-31 20:05 UTC (History)
3 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2007-12-25 01:43:23


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Ian Rogers 2007-07-18 14:13:59 UTC
Looking at:

http://developer.classpath.org/doc/java/util/Formatter-source.html#line.1393

the printf flags %e, %f, %g and %a aren't implemented. For example, the simple test:

class a {
  public static void main(String args[]) {
    System.out.printf("XXX%7.3fYYY",1234567.123);
  }
}

will print XXXYYY and not XXX1234567.123YYY.
Comment 1 Tom Tromey 2007-07-24 14:41:45 UTC
Yeah, nobody implemented the floating point support yet.
Comment 2 Andrew John Hughes 2007-12-25 01:43:23 UTC
I'll take a look at this.  May be possible to handle it using DecimalFormat.
Comment 3 Andrew John Hughes 2008-06-15 22:19:43 UTC
*** Bug 36434 has been marked as a duplicate of this bug. ***
Comment 4 Peter Breuer 2009-12-30 01:23:26 UTC
Also %x does an unwanted sign-extension to long from int.

class Test {

   public static void main(String argv[]) {

       System.out.printf("%x\n", new Integer(0x80000000));
   }
}

% gcj -Wall Test.java --main=Test -o Test
% ./Test
ffffffff80000000
%

% gcj -v
Using built-in specs.
Reading specs from /usr/lib/gcc/i486-linux-gnu/4.4.2/libgcj.spec
rename spec startfile to startfileorig
rename spec lib to liborig
Target: i486-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.4.2-7' --with-bugurl=file:///usr/share/doc/gcj-4.4/README.Bugs --enable-languages=c,c++,java --prefix=/usr --enable-shared --enable-multiarch --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.4 --program-suffix=-4.4 --enable-nls --enable-clocale=gnu --disable-libmudflap --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=//usr/lib/jvm/java-1.5.0-gcj-4.4/jre --enable-java-home --with-jvm-root-dir=//usr/lib/jvm/java-1.5.0-gcj-4.4 --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.4 --with-arch-directory=i386 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-targets=all --with-arch-32=i486 --with-tune=generic --enable-checking=release --build=i486-linux-gnu --host=i486-linux-gnu --target=i486-linux-gnu
Thread model: posix
gcc version 4.4.2 (Debian 4.4.2-7) 


The right output is produced from the class file by the java virtual machine
% gcj -Wall Test.java -C
% java Test
80000000


Comment 5 Erik Brangs 2013-07-31 20:05:08 UTC
FYI: Support for the %f flag is needed to successfully run the h2 benchmark from DaCapo 9.12. More specifically, it is necessary to complete the output verification because the missing %f support leads to percentages not being displayed correctly.

Quentin Sabah has provided a patch for the Jikes RVM which adds limited support for the %f flag. You can find it at http://jira.codehaus.org/browse/RVM-1047 .