public inbox for java@gcc.gnu.org
 help / color / mirror / Atom feed
From: Eric Blake <ebb9@email.byu.edu>
To: Adam Megacz <gcj@lists.megacz.com>
Cc: java@gcc.gnu.org
Subject: Re: MissingResourceException with Date under mingw port
Date: Wed, 10 Apr 2002 12:25:00 -0000	[thread overview]
Message-ID: <3CB4908E.A902AF2E@email.byu.edu> (raw)
In-Reply-To: <86r8lnzcpo.fsf@megacz.com>

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

  parent reply	other threads:[~2002-04-10 19:21 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-04-10 10:31 Adam King
2002-04-10 10:42 ` Adam Megacz
2002-04-10 10:49   ` Tom Tromey
2002-04-10 12:25   ` Eric Blake [this message]
2002-04-10 12:55     ` Adam Megacz
2002-04-10 15:56       ` Eric Blake
2002-04-10 16:11         ` Tom Tromey
2002-04-10 16:35     ` Tom Tromey
2002-04-10 18:21       ` Per Bothner
2002-04-10 11:11 ` Mark Wielaard

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3CB4908E.A902AF2E@email.byu.edu \
    --to=ebb9@email.byu.edu \
    --cc=gcj@lists.megacz.com \
    --cc=java@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).