Tom Tromey wrote:
> >>>>> "Jeroen" == Jeroen Frijters <[EMAIL PROTECTED]> writes:
> 
> Jeroen> Would anyone mind if I made the
> Jeroen> java.lang.String.CaseInsensitiveComparator inner class
> Jeroen> non-private (i.e.  make it package accessible)?
> 
> I'm sure it would be fine.
> But why do you need this?

It's a complicated scenario and I'm not sure I'm happy with it. I'll try
to explain:

IKVM.NET doesn't use java.lang.String, because it uses the String class
from the underlying platform (.NET). However, to build GNU Classpath
(using a regular Java compiler, I use Jikes) I have to have a String
class, so it makes sense to use java/lang/String.java from Classpath for
this. Now, obviously, the .NET String doesn't provide all the methods
that java.lang.String does, so I have a package private helper class
java.lang.StringHelper that contains static methods that implement all
the missing String methods. It also contains the static field
CASE_INSENSITIVE_ORDER, and this is intialized with an instance of
java.lang.String.CaseInsensitiveComparator, because it is private I
cannot directly instantiate it from within my Java StringHelper class, I
have to use a "native" method. It would be cleaner if I could just
instantiate it from within my StringHelper code.

An alternative would be to provide my own implementation of a
java.lang.String$CaseInsensitiveComparator class and pretend it is an
inner class of java.lang.String, but this has the downside that it
complicates my build process (I have to ignore the Classpath
String$CaseInsensitiveComparator.class) and I have to duplicate the
(admittedly small) source code.

Regards,
Jeroen


_______________________________________________
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath

Reply via email to