Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 163249 - Invoking javac through tools.jar fails on ia64
Summary: Invoking javac through tools.jar fails on ia64
Alias: None
Product: Fedora
Classification: Fedora
Component: java-1.4.2-gcj-compat
Version: rawhide
Hardware: ia64
OS: Linux
Target Milestone: ---
Assignee: Thomas Fitzsimmons
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2005-07-14 14:05 UTC by Gary Benson
Modified: 2007-11-30 22:11 UTC (History)
2 users (show)

Fixed In Version: gcc-4.0.1-3
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2007-04-02 14:36:40 UTC

Attachments (Terms of Use)

Description Gary Benson 2005-07-14 14:05:00 UTC
Description of problem:
Invoking javac through tools.jar fails on ia64, which breaks ant.  Invoking it
on the command-line works fine.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. java -classpath /usr/lib/jvm/java/lib/tools.jar
Actual results:
Missing resource : org/eclipse/jdt/internal/compiler/batch/
for locale en_US
Exception in thread "main" java.lang.ExceptionInInitializerError
   <<No stacktrace available>>
Caused by: java.util.MissingResourceException: Bundle
org.eclipse.jdt.internal.compiler.batch.messages not found
   <<No stacktrace available>>

Expected results:
Should print a usage message.

Comment 1 Gary Benson 2005-07-14 14:24:53 UTC
The missins stacktraces probably look something like this:

Missing resource : org/eclipse/jdt/internal/compiler/batch/
for locale en_GB
Exception in thread "main" java.lang.ExceptionInInitializerError
   at java.lang.Class.initializeClass() (/usr/lib/
   at java.lang.Class.forName(java.lang.String, boolean, java.lang.ClassLoader)
   at java.lang.Class.forName(java.lang.String) (/usr/lib/
   at (Unknown Source)
   at[]) (Unknown Source)
   at (/usr/lib/
   at (/usr/lib/
Caused by: java.util.MissingResourceException: Bundle
org.eclipse.jdt.internal.compiler.batch.messages not found
   at java.util.ResourceBundle.getBundle(java.lang.String, java.util.Locale,
java.lang.ClassLoader) (/usr/lib/
   at java.util.ResourceBundle.getBundle(java.lang.String, java.util.Locale)
   at org.eclipse.jdt.internal.compiler.batch.Main.relocalize() (Unknown Source)
   at org.eclipse.jdt.internal.compiler.batch.Main.<clinit>() (Unknown Source)
   at java.lang.Class.initializeClass() (/usr/lib/
   ...6 more

Comment 2 Gary Benson 2005-07-14 14:31:40 UTC
Hmmm, java.util.ResourceBundle.getBundle(String, Locale) (second down in the
stacktrace) looks like this:

  public static ResourceBundle getBundle(String baseName)
    ClassLoader cl = getCallingClassLoader();
    if (cl == null)
      cl = ClassLoader.getSystemClassLoader();
    return getBundle(baseName, Locale.getDefault(), cl);

I wonder, is getCallingClassLoader() failing for the same reason as that which
is causing the "<<No stacktrace available>>" messages?

Comment 4 Andrew Haley 2005-07-14 15:36:13 UTC
Try this test on IA-64.

#include <execinfo.h>
#include <stdio.h>
main (void)
  void *p[12];
  int NN = backtrace (p, 12);
  char **pp = backtrace_symbols (p, NN);
  printf ("trace: %d\n", NN);
  int i;
  for (i=0; i<NN; i++)
    printf (" %s \n", pp[i]);

Comment 5 Gary Benson 2005-07-14 15:46:30 UTC
natasha:[gbenson]$ ./backtrace.ia64
trace: 3
 ./backtrace.ia64 [0x4000000000000750]
 /lib/tls/ [0x200000000006a990]
 ./backtrace.ia64 [0x40000000000005a0]

Comment 6 Gary Benson 2005-07-15 12:52:07 UTC
Ok, so backtrace() was enabled on ia64 in libgcj-4.0.1-3, and ant successfully
built with it.  However, tools.jar still gives the "Missing resource" error if
eclipse-ecj.jar is native compiled.  I've renamed eclipse-ecj's database file on
the build machine to work around this.

Comment 7 Gary Benson 2005-08-25 11:18:29 UTC
There is a problem in tomcat5's build when native which could be this same
issue.  The class org.apache.jasper.JspC, loaded through ant's classloader,
throws an exception during <clinit> complaining that it can't find itself in the
system classloader.

Comment 8 Red Hat Bugzilla 2007-02-05 19:31:18 UTC
REOPENED status has been deprecated. ASSIGNED with keyword of Reopened is preferred.

Note You need to log in before you can comment on or make changes to this bug.