Re: classpath 0.06?
Hi, On Wed, 2003-07-23 at 15:56, David P Grove wrote: There was some discussion a month or so ago about making a classpath 0.06 distribution. Is there a chance this could happen sometime relatively soon? We're thinking about making the next release of Jikes RVM in 2-3 weeks and it would be great to be able to get all the hard work done in classpath since 0.05 out to our users. Almost all of them use classpath 0.05 instead of classpath cvs head because the install process is easier. Having a release/snapshot now seems like good idea since 0.05 has been almost 6 months ago now. I would like to propose a quick release schedule of about three weeks. First one and a half week to get the last things in that people feel we must have for 0.06 (e.g. make sure the Aicas JNI C native layer is complete, update the gjdoc api generation, there is also one SecurityManager/VMSecurityManager thing that might be nice, maybe the Thread/VMThread thing, although it might be a bit big to change so close to the release). Feel free to make suggestions (but be prepared to provide code soon). And then have one and a half week to stabilize this thing and make sure it works with as much VMs (CVS versions probably) as possible. Then lets try to release it on August 15 2003 which would be precisely 6 months after 0.05. What do people think about this plan? Cheers, Mark ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: classpath 0.06?
Hi, On Wed, 2003-07-23 at 19:31, Brian Jones wrote: I can help to physically get it on the ftp server, etc. if Mark needs it. Paul has given me access to the ftp and alpha download areas. But I have not tried out these new powers yet. Help with packaging and putting things on the right servers will be highly appreciated when the time comes. Thanks, Mark ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: classpath 0.06?
Hi, On Fri, 2003-07-25 at 11:56, Arnaud Vandyck wrote: Sorry, maybe a idiot question, but is there a release plan for 0.06, 0.07, ..., 1.0? Good questions. There is no real release plan for 0.0x, 0.0x+1, etc. We just agreed to make a release roughly every couple of months. The plan for GNU Classpath 1.0 has always been to have core libraries comparable to what JDK 1.1 provided. We have reached that goal and gone far beyond it for some packages, but for java.awt this is still not reached. Two other important things. The first is that we want be merged as much as possible with libgcj, again most has been done see http://gcc.gnu.org/java/libgcj-classpath-compare.html but there remain a couple of tricky things not really on that page (e.g. char set encoding and url handlers). And merging more with libgcj relies on the other important thing to have for 1.0 and that is a clear maintainable VM integration layer (the SecurityManager/VMSecurityManager and Thread/VMThread split mentioned earlier are part of this). What this all means is that for declaring GNU Classpath 1.0 we want to have something that we feel is good enough that free VMs can use it out of the box and that we can confidentially say is maintainable and stable enough to use. Is it a problem if there are more releases? No, we can certainly do releases (or semi-stable snapshots) more often then every 6 months. But it does take a non-zero amount of time to prepare a real release so then we should make sure we have enough resources to pull that off. Isn't the website a bit out of date or will it be updated only when a new release will be done? If someone gives suggestions or even wants to update it a bit please do. Documentation is always the last priority even though it is very important to get right. All current pages can be found in CVS under doc/www.gnu.org. There is a little README in that directory that needs at least one change and that is that we would really like people to discuss anything about it on this mailinglist. Cheers, Mark ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Bug 2685
Hi, I'm trying to close a few bugs for the 0.06 release. I've replied to bug 2685, http://savannah.gnu.org/bugs/?func=detailbugbug_id=2685group_id=85, and need someone to help me understand how to correct my test case. The test case is attached to the bug report and this email. Sun's 1.4.1 JVM never seems to throw ThreadDeath in a catchable way or more likely I am trying to do something I can't. My reading of the documentation for this deprecated method Thread.stop() made me believe such a thing would work however. Any ideas? Thanks, Brian -- Brian Jones [EMAIL PROTECTED] stop.java Description: Binary data ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
RE: Bug 2685
Brian,
Try the attached code instead - which properly synchronizes between
the two threads to ensure that the thread to be stopped actually
starts executing. From what I observed the thread never got a chance
to run and so was stopped before it really got started. This can
happen because:
a) start sets the isAlive flag such that isAlive returns true (it need
not do this, but it can)
b) your while loop sees the thread is alive, even though it has never
yet been scheduled, and so the main thread doesn't sleep
c) you immediately stop() it, hence it will never be scheduled
Always use wait/notify to coordinate threads never use sleeps. Also
note:
a) the shared flag 'death' must be volatile as it is accessed without
synchronization
b) using someThread.sleep(x) is at best misleading because
Thread.sleep always applied to the current thread. Best to avoid
potential misunderstanding by just using Thread.sleep(x);
But also be aware that there is no guarantee, now that it is
deprecated, that Thread.stop() will do anything reasonable under the
JDK.
Cheers,
David Holmes
-
public class stop extends Thread
{
static volatile boolean death = false;
static void check(boolean cond, String msg) {
if (!cond) throw new Error(msg);
}
static Object lock = new Object();
static boolean running = false;
public void run()
{
System.out.println(Running ...);
try {
// main thread is waiting for us to start so let it proceed
// once we block
synchronized(lock) {
running = true;
lock.notify();
}
synchronized (lock) {
while (true) { lock.wait(); }
}
}
catch (Exception m)
{
check(false, Unexpected exception during test);
}
catch (ThreadDeath e)
{
death = true;
Thread thread = Thread.currentThread();
ThreadGroup group = thread.getThreadGroup();
check(group != null, Stop should not remove thread from
ThreadGroup);
throw e;
}
}
public static void main (String[] args)
{
try
{
Thread current = Thread.currentThread();
ThreadGroup group = current.getThreadGroup();
stop t = new stop();
t.start();
// wait until t says it's running
synchronized(lock) {
while (!running) lock.wait();
}
t.stop();
t.join(0);
check(death, ThreadDeath not properly thrown and caught);
}
catch (InterruptedException ie)
{
check(false, Unexpected interrupt);
}
}
}
___
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath
Re: Bug 2685
David Holmes [EMAIL PROTECTED] writes: Brian, Try the attached code instead - which properly synchronizes between the two threads to ensure that the thread to be stopped actually starts executing. Thanks David, I shouldn't have tried that hack I guess. Brian -- Brian Jones [EMAIL PROTECTED] ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Bug report: java.util.GregorianCalendar
Sun's API document says about java.util.Calendar.WEEK_OF_MONTH, The first week of the month, as defined by getFirstDayOfWeek() and getMinimalDaysInFirstWeek(), has value 1. But GNU Classpath's java.util.GregorianCalendar returns 0 for the first week of the month except for those special months whose first day is Sunday (e.g. Jun 2003). Here is my patch: --- java/util/GregorianCalendar.java.orig Sun Mar 24 01:10:15 2002 +++ java/util/GregorianCalendar.javaMon Jul 28 11:53:16 2003 @@ -599,7 +599,7 @@ // which day of the week are we (0..6), relative to getFirstDayOfWeek int relativeWeekday = (7 + fields[DAY_OF_WEEK] - getFirstDayOfWeek()) % 7; -fields[WEEK_OF_MONTH] = (fields[DAY_OF_MONTH] - relativeWeekday + 6) / 7; +fields[WEEK_OF_MONTH] = (fields[DAY_OF_MONTH] - relativeWeekday + 12) / 7; int weekOfYear = (fields[DAY_OF_YEAR] - relativeWeekday + 6) / 7; By the way, while GNU Classpath's Calendar returns 53 or 54 as the last week of the year, Sun's Java 1.4.2 returns 1. I think this may be a bug of Sun's. ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
