This is the mail archive of the java-patches@gcc.gnu.org mailing list for the Java project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: New classes from Classpath


>>>>> "Mark" == Mark Wielaard <mark@klomp.org> writes:

Mark> The following patch adds the following four new classes from
Mark> Classpath: java.lang.CharSequence,
Mark> java.lang.InheritableThreadLocal, java.net.Authenticator and
Mark> java.net.PasswordAuthentication.

I saw the patch separately, thanks.

One question for all libgcj hackers: how far into JDK 1.4 do we want
to go?  We already have a little piece (IdentityHashMap, since it was
useful for JNI).  Do we want CharSequence?  Some Classpath hackers
seem to be working on 1.4 compatibility even though it hasn't been
released yet.

The non-1.4 parts are definitely ok.

Mark> It also adds implementations for CharSequence.subSequence() to String
Mark> and StringBuffer. The StringBuffer patch also merges some comments from
Mark> Classpath to make the diff as short as possible. And there is a small
Mark> patch to the Thread constructor so it calls the newChildThread() of
Mark> InheritableThreadLocal.

Assuming we all agree that CharSequence is ok, then most of these
changes are fine.

The only potential problem is in Thread.java:

Mark> Index: java/lang/Thread.java
Mark> ===================================================================
Mark> RCS file: /cvs/gcc/gcc/libjava/java/lang/Thread.java,v
Mark> retrieving revision 1.19
Mark> diff -u -r1.19 Thread.java
Mark> --- Thread.java	2001/08/26 11:30:09	1.19
Mark> +++ Thread.java	2001/10/01 20:50:45
Mark> @@ -258,6 +258,8 @@
Mark>      group.addThread(this);
Mark>      runnable = r;
 
Mark> +    InheritableThreadLocal.newChildThread(this);
Mark> +
Mark>      initialize_native ();
Mark>    }

I actually have a similar patch in a tree here.  In my patch I call
InheritableThreadLocal.newChildThread() from the `current != null' branch
of the `if' statement in the Thread constructor.  Otherwise I think
you run into problems because InheritableThreadLocal will look at the
currently executing thread -- which during startup might be null.
Also it doesn't seem important to try to inherit these objects for
the initial thread anyway.  What do you think of this?

Tom


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]