MissingResourceException with Date under mingw port

MissingResourceException with Date under mingw port

[Adam King]

Before the i686-pc-mingw32 taget for the cvs branch became
uncompilable this morning, I was getting the following
exception in my code.  I narrowed it down to the following
simple test:

import java.util.Date;

public class DateBug
{
  public static void main( String[] args )
  {
    System.out.println( (new Date()).toString() );
  }
}

With the mingw port, I get:

T:\>datebag
Exception in thread "main" java.util.MissingResourceException: Bundle gnu.java.locale.Calendar not found

It runs fine when compiled with the linux target.

Am I missing a library I should be linking in?  I compiled it with:
  i686-pc-mingw32-gcj --main=DateBug -o datebug.exe DateBug.java

	Adam

Re: MissingResourceException with Date under mingw port

[Adam Megacz]

Adam King <aking@dreammechanics.com> writes:
> Exception in thread "main" java.util.MissingResourceException:
> Bundle gnu.java.locale.Calendar not found

Yeah, the linkage between java.util.Date and gnu.java.locale.Calendar
is weak -- Date only references Calendar via reflection. GNU ld
doesn't understand this sort of linkage, so it doesn't include
gnu.java.locale.Calendar when creating a static binary.

Here's the standard prelude I throw into all my gcj programs to force
the linker to include all the required classes:

    // static references to these classes ensure that the linker will include them
    private static Class c1 = gnu.java.locale.Calendar.class;
    private static Class c2 = java.util.GregorianCalendar.class;
    private static Class c3 = gnu.gcj.convert.Input_ASCII.class;
    private static Class c4 = gnu.gcj.convert.Input_UTF8.class;
    private static Class c5 = gnu.gcj.convert.Input_8859_1.class;
    private static Class c6 = gnu.java.locale.LocaleInformation.class;
    private static Class c7 = gnu.gcj.convert.Output_ASCII.class;

To the other GCJ people: are there any disadvantages to putting
private static foo.class references in the java.* classes so that
static links work properly without this hack?


> It runs fine when compiled with the linux target.

Probably because you're dynamically linking against libgcj.so, which
includes the whole Java library. If you compile with --static you
should see the same problem on Linux.

  - a


-- 
The web is dead; long live the Internet.
http://www.xwt.org/

Re: MissingResourceException with Date under mingw port

[Tom Tromey]

>>>>> "Adam" == Adam Megacz <gcj@lists.megacz.com> writes:

Adam> Here's the standard prelude I throw into all my gcj programs to
Adam> force the linker to include all the required classes:
Adam> [ ... ]

Adam> To the other GCJ people: are there any disadvantages to putting
Adam> private static foo.class references in the java.* classes so that
Adam> static links work properly without this hack?

We already do this; look at FirstThread.java.  So far we've only done
it for classes needed for bootstrapping.  There's a tension here
because people might want to use static linking to make their programs
smaller; the more classes we list like this the less possible that is.

On the to-do list for a long time has been adding a command-line
option to gcj so you could specify classes which we would force to be
linked in.

I don't have an opinion right now on whether we should add your
classes to FirstThread.  I'd love to hear arguments either way.

Long term I think we need to make libgcj into a DLL on Windows.

Tom

Re: MissingResourceException with Date under mingw port

[Mark Wielaard]

Hi,

On Wed, 2002-04-10 at 19:12, Adam King wrote:
> With the mingw port, I get:
> 
> T:\>datebag
> Exception in thread "main" java.util.MissingResourceException: Bundle gnu.java.locale.Calendar not found
> 
> It runs fine when compiled with the linux target.
> 
> Am I missing a library I should be linking in?  I compiled it with:
>   i686-pc-mingw32-gcj --main=DateBug -o datebug.exe DateBug.java

You will get the same thing on GNU/Linux when compiling with -static.
But you can work around it by setting your CLASSPATH to the libgcj.jar
(e.g. export CLASSPATH=/usr/local/gcc-3.1/share/libgcj.jar or the
equivalent under Windows/Mingw.)
That does defeat the -static a bit, but at least makes your program run.

Cheers,

Mark

Re: MissingResourceException with Date under mingw port

[Eric Blake]

Adam Megacz wrote:
> 
> Yeah, the linkage between java.util.Date and gnu.java.locale.Calendar
> is weak -- Date only references Calendar via reflection. GNU ld
> doesn't understand this sort of linkage, so it doesn't include
> gnu.java.locale.Calendar when creating a static binary.
> 
> Here's the standard prelude I throw into all my gcj programs to force
> the linker to include all the required classes:
> 
>     // static references to these classes ensure that the linker will include them
>     private static Class c1 = gnu.java.locale.Calendar.class;
>     private static Class c2 = java.util.GregorianCalendar.class;
>     private static Class c3 = gnu.gcj.convert.Input_ASCII.class;
>     private static Class c4 = gnu.gcj.convert.Input_UTF8.class;
>     private static Class c5 = gnu.gcj.convert.Input_8859_1.class;
>     private static Class c6 = gnu.java.locale.LocaleInformation.class;
>     private static Class c7 = gnu.gcj.convert.Output_ASCII.class;

So why not add this line to Calendar?

  private static Class c1 = gnu.java.locale.Calendar.class;

That way, ld will pick up gnu.java.locale.Calendar, but only when
java.util.Date is referenced.  This is a better option than putting it
in FirstThread, which would always pick up the helper class in a static
compile, and it takes the burden away from the user of needing to list a
"standard prelude" of classes.  This should also be done for the other
classes in your list, wherever the current library uses them by
reflection only.

Actually, to reduce the number of wasted class variables allocated in
Date, it would be nicer to use this paradigm, using the stack instead of
static data (although I'm not sure if it would be optimized away on the
knowledge that c is unused, and hence defeat the intended purpose):
  static
  {
    Class c = gnu.java.locale.Calendar.class;
  }

Or, to reduce the bytecode when compiling with -C (as the .class literal
expression expands to quite a bit of bytecode), you could do this:
  static
  {
    gnu.java.locale.Calendar c = null;
  }

-- 
This signature intentionally left boring.

Eric Blake             ebb9@email.byu.edu
  BYU student, free software programmer

Re: MissingResourceException with Date under mingw port

[Adam Megacz]

Eric Blake <ebb9@email.byu.edu> writes:
> So why not add this line to Calendar?
>   private static Class c1 = gnu.java.locale.Calendar.class;

Sounds good to me.

  - a

-- 
The web is dead; long live the Internet.
http://www.xwt.org/

Re: MissingResourceException with Date under mingw port

[Eric Blake]

Adam Megacz wrote:
> 
> Eric Blake <ebb9@email.byu.edu> writes:
> > So why not add this line to Calendar?
> >   private static Class c1 = gnu.java.locale.Calendar.class;
> 
> Sounds good to me.

I propose this patch (should it go on the branch, or just mainline?):

2002-04-10  Eric Blake  <ebb9@email.byu.edu>

	* java/util/Calendar.java (bundleName): Make reference to bundle
	explicit to aid the linker.

Index: java/util/Calendar.java
===================================================================
RCS file: /cvs/gcc/gcc/libjava/java/util/Calendar.java,v
retrieving revision 1.12
diff -u -r1.12 Calendar.java
--- java/util/Calendar.java     22 Jan 2002 22:40:38 -0000      1.12
+++ java/util/Calendar.java     10 Apr 2002 19:49:06 -0000
@@ -1,5 +1,5 @@
 /* java.util.Calendar
-   Copyright (C) 1998, 1999, 2000, 2001 Free Software Foundation, Inc.
+   Copyright (C) 1998, 1999, 2000, 2001, 2002 Free Software Foundation, Inc.

 This file is part of GNU Classpath.

@@ -362,9 +362,12 @@
   static final long serialVersionUID = -1807547505821590642L;

   /**
-   * The name of the resource bundle.
+   * The name of the resource bundle. Since the bundle class is only used by
+   * reflection, we use this expression instead of a string literal so that
+   * the linker will be aware of the dependence.
    */
-  private static final String bundleName = "gnu.java.locale.Calendar";
+  private static final String bundleName
+    = gnu.java.locale.Calendar.class.getName();

   /**
    * Constructs a new Calendar with the default time zone and the default


-- 
This signature intentionally left boring.

Eric Blake             ebb9@email.byu.edu
  BYU student, free software programmer

Re: MissingResourceException with Date under mingw port

[Tom Tromey]

>>>>> "Eric" == Eric Blake <ebb9@email.byu.edu> writes:

Eric> I propose this patch (should it go on the branch, or just mainline?):

Both, thanks.

Eric> 2002-04-10  Eric Blake  <ebb9@email.byu.edu>
Eric> 	* java/util/Calendar.java (bundleName): Make reference to bundle
Eric> 	explicit to aid the linker.

This seems good to me.  We may need similar changes elsewhere too, for
instance in java.text (though based on the number of bug reports we've
received over time I would say that few people use java.text).

Eric> -  private static final String bundleName = "gnu.java.locale.Calendar";
Eric> +  private static final String bundleName
Eric> +    = gnu.java.locale.Calendar.class.getName();

I like the idea of putting this into Calendar.  I wish I had thought
of it.  Do you think this is acceptable for Classpath though?

Tom

Re: MissingResourceException with Date under mingw port

[Tom Tromey]

>>>>> "Eric" == Eric Blake <ebb9@email.byu.edu> writes:

Eric> Or, to reduce the bytecode when compiling with -C (as the .class literal
Eric> expression expands to quite a bit of bytecode), you could do this:
Eric>   static
Eric>   {
Eric>     gnu.java.locale.Calendar c = null;
Eric>   }

I imagine the native compiler will simply eliminate this.
I haven't tried it though.

Tom

Re: MissingResourceException with Date under mingw port

[Per Bothner]

> Eric>   static
> Eric>   {
> Eric>     gnu.java.locale.Calendar c = null;
> Eric>   }

I don't particularly care for this approach.
The correct general solution is to support some option
to specify classes that should be loaded.  The gcj
wrapper can easily mangle this into a '-u' linker option.

I don't understand how forcing gnu.java.locale.Calendar
to get loaded really helps since you're don't know which
locale you will need.  However, I suggest the following:

Add a static method to gnu.java.locale.Calendar:

   public static ResourceBundle getBundle(Locale locale)
   {
     // This can possibly be optimized.
     return getBundle("gnu.java.locale.Calendar", locale);
   }

and in Date.java replace getBundle calls:
   ResourceBundle rb = ResourceBundle.getBundle(bundleName, locale);
by:
   ResourceBundle rb = gnu.java.locale.Calendar.getBundle(locale);
-- 
	--Per Bothner
per@bothner.com   http://www.bothner.com/per/