Re: Japi results updated - full 1.0 and 1.1 *extremely* close
Tom Tromey writes: Stuart Firstly it looks like Tom's gcj issues are solved so we have an Stuart up-to-date classpath japi file[1]. I guess the build with gcj somehow got fixed. Sadly, it got fixed bacsue Mark Wielaard changed the Classpath source. Still, I've never seen the problem. Andrew. ___ Classpath mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/classpath
Re: DST related Calendar regression
Noa Resare wrote:
On 04-10-08 [EMAIL PROTECTED] checked in changes to java.util.Calendar
that effectively made an explicitly set DST_OFFSET value to a function
of the set TimeZone for the Calendar object if an other field (such as
YEAR) is set in the calendar after DST_OFFSET is set.
I think this is wrong, as someone who sets DST_OFFSET explicitly and not
via .setTimeZone() presumably knows what she is doing and expects the
provided DST_OFFSET to be used.
Hi Noa,
Thanks for looking into this. I agree that there is a bug here, as
demonstrated by your mauve test, but I'm not sure that this is the
correct fix. It should not be possible to set DST_OFFSET explicitly
because DST_OFFSET changes at different times of the year depending on
whether the Calendar is in DST or not according to the rules of it's
TimeZone. ie: for a given timezone and date value, there is only one
valid value for the DST_OFFSET field and it doesn't make sense to set a
different one explicitly.
Although the spec doesn't define what happens if you do this, I think
the simplest (implementation-wise) and most logical approach is to
ignore user attempts to set DST_OFFSET, which also appears to be what
Sun's implementation does (recent ones, at least). Consider the
following test case for an example:
import java.util.*;
public class TestDST
{
public static void main(String[] args)
{
Calendar c =
Calendar.getInstance(TimeZone.getTimeZone(America/Toronto));
c.set(2004, Calendar.NOVEMBER, 1); // Not in DST period
c.set(Calendar.DST_OFFSET, -1);
System.out.println (c.get(Calendar.DST_OFFSET));
c.set(2004, Calendar.OCTOBER, 1); // In DST period
c.set(Calendar.DST_OFFSET, 0);
System.out.println (c.get(Calendar.DST_OFFSET));
}
}
With Sun's JDK 1.5, this gives the following output:
$ java TestDST
0
360
So, I think the real bug here is in SimpleDateFormat - it should only
use setTimeZone() and not try to set DST_OFFSET or ZONE_OFFSET
explicitly. We should clarify our Javadoc to specify that attempts to
set these fields explicitly are ignored.
Regards
Bryce
___
Classpath mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/classpath
Re: Japitools status - Savannah and v5 support
Tom Tromey wrote: Eventually you could consider using code from gcjx (Eventually because the 1.5 bytecode-reading support hasn't been written yet). In this case you'd have to write in C++ and not Java. OTOH, the part of Japi to generate the .japi file could be rewritten as a gcjx back end without much difficulty. (In fact it could be arranged so that a Japi output file is created as a side effect of building the .class files; gcjx can already run multiple back ends for a single compilation.) Might be an interesting excuse to learn C++. I'll bear it in mind as a possibility if nothing else pops up in the meantime. Hmm, I suppose generating serialVersionUID will be hard. That's hard already and a suspected source of bugs - something's going on with AccessibleApplet that's not currently understood AFAIK. One thing we may want to consider is the goal of Japi. If it is binary compatibility, then most of the questions below aren't too relevant -- because generics work by type erasure, the parameterizations are not visible at runtime and thus don't affect binary compatibility. For instance, it is binary (but not source) compatible to change a generic class to be non-generic. Source compatibility is not defined by the spec, but we know what it is -- basically that the user-visible envelope of classes in the standard library should be the same in every meaningful way. Full source compatibility is almost impossible because you can't add any new names to a non-final class without potentially screwing stuff up royally. Besides, Sun broke that at a language level for anyone who had a variable called strictfp or a method called assert(). On the other hand, I agree that in this case following strictly binary compatibility with no regard for the source code implications is wrong. It just so happened that up to now the rules for binary compatibility were close enough to what we actually did want that it was reasonable to talk about. Actually japicompat already has a -s flag which sticks to binary compatibility as defined by the JLS, without the additions for things like exceptions and adding methods to abstract classes. I think it would be reasonable to put all the generic comparisons that don't affect binary compatibility in the set of tests that gets excluded by this flag. I didn't answer your list of questions one-by-one since we would need to answer the goal part first. But if the goal is source compatibility, which I think it should be, then basically we just want to keep ensuring that everything is the same: same (possibly generic) types for fields, same types for method arguments and returns, same parameterization for generic classes, etc. There's one definite exception to this - Sun's clearly felt free to take non-generic classes and add generic parameters constrained to the types that were already in use (see Collections, java.lang.Class etc). When japitools tests for backwards compatibility it should reflect the reality that doing this is considered okay. As a first cut I would say that those which are @Documented should be considered as necessary for compatibility. This sounds right. Enums and varargs methods. Good call. Stuart. -- Stuart Ballard, Senior Web Developer NetReach, Inc. (215) 283-2300, ext. 126 http://www.netreach.com/ ___ Classpath mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/classpath
Re: Japi results updated - full 1.0 and 1.1 *extremely* close
On Fri, 2004-10-29 at 11:52, Stuart Ballard wrote: I have a few more things I want to do before making a release of this, but I thought people might want to know about this so they can immediately set to fixing those 4 remaining errors to claim complete 1.1 and 1.0 coverage :) I committed a fix for the missing java.awt.Font fields. Tom ___ Classpath mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/classpath
Re: japi note
C. Brian Jones wrote: Stuart, I've taken the serialization tests I once gave you to add to japitools and added those to a module in Mauve called 'serialization'. A new Mauve module seems like a good home for the japitools project to me, but it's up to you... and Tom too. So would you suggest I take serialize and serialcompat out of japitools along with the references on the webpage? Thanks, Stuart. -- Stuart Ballard, Senior Web Developer NetReach, Inc. (215) 283-2300, ext. 126 http://www.netreach.com/ ___ Classpath mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/classpath
Re: japi note
On Tue, 2004-11-02 at 15:06, Stuart Ballard wrote: C. Brian Jones wrote: Stuart, I've taken the serialization tests I once gave you to add to japitools and added those to a module in Mauve called 'serialization'. A new Mauve module seems like a good home for the japitools project to me, but it's up to you... and Tom too. So would you suggest I take serialize and serialcompat out of japitools along with the references on the webpage? Yes, you can point people at the Mauve module if they are wondering where it went. Perhaps with the work on Mauve's framework it will be easy to run this as part of the regular Mauve test set in the near future. Brian -- Brian Jones [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part ___ Classpath mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/classpath
