Re: java.util.zip.GZIPConstants
Sascha Brawer wrote: 1. The spec requires GZIPInputStream.GZIP_MAGIC; Classpath inherits the field from a package-private interface. This is binary compatible (if the constant is the same), but might be nice to move (or duplicate) the constant to the correct place for reflection compatibility. 2. According to the spec, there should not be a GZIPOutputStream.GZIP_MAGIC. This is not binary compatible. Classpath should not have public fields where the JDK does not, because it could lead to name conflicts in user code. 3. According to the spec, there should not be a FTEXT anywhere. In the interface, it is a problem, because it is public. But if you move FTEXT out of the interface, and make it package-private or private, then it is just fine. The only things we need to match with the JDK are protected and public APIs, and serialization. Besides, having internal constants is often a good idea, to avoid the magic number syndrome. Are any of these non-conformant? -- This signature intentionally left boring. Eric Blake [EMAIL PROTECTED] BYU student, free software programmer ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: java.util.zip.GZIPConstants
John Leuner [EMAIL PROTECTED] wrote on Thu, 21 Mar 2002 16:28:52 +: Sascha, would you like to fix these? If you would like to, please feel free to go ahead. -- Sascha ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: java.util.zip.GZIPConstants
1. The spec requires GZIPInputStream.GZIP_MAGIC; Classpath inherits the field from a package-private interface. This is binary compatible (if the constant is the same), but might be nice to move (or duplicate) the constant to the correct place for reflection compatibility. 2. According to the spec, there should not be a GZIPOutputStream.GZIP_MAGIC. This is not binary compatible. Classpath should not have public fields where the JDK does not, because it could lead to name conflicts in user code. 3. According to the spec, there should not be a FTEXT anywhere. In the interface, it is a problem, because it is public. But if you move FTEXT out of the interface, and make it package-private or private, then it is just fine. The only things we need to match with the JDK are protected and public APIs, and serialization. Besides, having internal constants is often a good idea, to avoid the magic number syndrome. Are any of these non-conformant? Sascha, would you like to fix these? John Leuner ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
FYI - Kaffe is alive again!
Hi, The last couple of days the Kaffe mailinglist saw a lot of new posts. There seems to be an new maintainer and they are interested in using Classpath as a (second) standard class library. Attached are two messages from Jim Pick the new maintainer were he outlines his plans and talks about having Kaffe+Classpath as an option. Nice, Mark ---BeginMessage--- Hi, I'd like to introduce myself. My name is Jim Pick. I have volunteered to take over the reigns of the kaffe project from it's original author, Tim Wilkinson. I've been following Kaffe's progress since about the time I first got involved in free software (around 1996). In the past, I've been an active Debian maintainer, and I also ran LinuxHQ.com, KernelNotes.org, and Kernel.org for a while, amongst other things. I know Tim quite well, as I moved to Berkeley, California (from Canada) to work with him and Peter Mehlitz at Transvirtual about two years ago. Tim is currently involved in the process of starting a new company, having left Transvirtual at the end of November last year. I still work at Transvirtual though, and I'm still good friends with Tim (we usually meet for coffee in the mornings). It was during one of those morning coffees that I asked Tim what was happening with Kaffe.org, and whether or not he was planning to do any more work on it. As I suspected, he stated that he really doesn't have time to do anymore work on it (especially since he no longer works at Transvirtual). He stated that he'd be happy if I took it over. I also checked with the new CEO of Transvirtual, Chris Herron, and Peter Mehlitz, if it was OK with them if I did some work to try to get the Kaffe.org project moving again, and they thought it was a good idea and were very supportive. I've announced my intentions to the core team, and they all seemed OK with the idea -- I asked if anybody else wanted the job, but there were no takers. So I guess I've got the go ahead to do this. :-) I've also taken over development of Transvirtual's internal, proprietary version of Kaffe (now called KaffePro), so I'm in the situation where I can spend a lot of time thinking about JVM implementations. :-) Anyways, here's what I'm planning to do: 1) Setup a new machine and website for kaffe.org, so everything can be centralized on one site. Transvirtual has donated a machine and rackspace for it, and I've already set it up. I've already moved the DNS and the ftp site onto it. The current website is looking pretty old and out-of-date, so I'm going to replace it with something simpler. I'm hoping I can get the CVS archive from Ean Schuessler at Brainfood so I can set it up on the new machine. Also, down the road, it would be nice to migrate the mailing list to the new machine so Daniel Veillard doesn't have to maintain it. I thought about using SourceForge, but I decided against it. 2) Make a new release as soon as possible. Version 1.0.6 came out in July, 2000, and there hasn't been a release since (although there has been CVS activity). I'd like to do a minimal amount of testing, and see if we can get it out, perhaps as early as next week. 3) Clarify the relationship between Transvirtual and Kaffe.org. As a long-time kaffe-watcher, I would like to see Kaffe.org be a very open project, which incorporates code from, and interoperates with all the other free virtual machine projects out there. I definitely see Kaffe.org as being an independent project that isn't controlled by Transvirtual. Transvirtual is willing to donate time and code to the project to make it successful. On the other hand, it would be best if everybody was comfortable with the fact that my employer is actively developing a proprietary version of kaffe, called KaffePro, which is designed to address the needs of the commercial market for clean room Java virtual machine implementations. As a commercial software company built on developing Intellectual Property, Transvirtual needs to be selective about what it does and does not contribute to the project. You can expect that Transvirtual won't hold back bug fixes from the free version, and will not prevent others from contributing to the project. Transvirtual, as a company, was founded with Kaffe as it's primary product, so you can expect to see Transvirtual continue to use, maintain and protect the Kaffe trademark for it's own purposes. It is important to Transvirtual that Kaffe.org is successful, but also that it is clear to the public that Kaffe.org's JVM implementation is separate from Transvirtual's KaffePro product, even though they share a common heritage. (whew, glad that's over, I'm afraid I was starting to sound like a lawyer) 4) Start active development on a new major release of kaffe. I've got a lot of ideas for what should be done with it. But I'll discuss those separately because I'd like to
Re: Locale initialization error
Patrik Reali wrote:
Hi!
I've run into a initialization problem when class java/util/Locale is
initialized.
The static initialization of Locale creates many instances of class Locale,
whose
constructor calls String.toUpperCase.
public Locale(String language, String country, String variant)
{
this.language = convertLanguage(language);
this.country = country.toUpperCase();
this.variant = variant.toUpperCase();
this.hashcode = (this.language.hashCode() ^ this.country.hashCode()
^ this.variant.hashCode());
}
For these constructors, I tried adding a trusted constructor which does
no capitalization. I'm still running into a problem here:
private static Locale defaultLocale =
new Locale(System.getProperty(user.language, ),
System.getProperty(user.region, ),
System.getProperty(user.variant, ));
According to the Javadoc of java.lang.System, there is no guarantee that
the properties user.language, user.region, or user.variant exist. Does
Sun document anywhere that these must exist, or who must supply them?
Or is it just a VM integration requirement of Classpath? If the latter,
then is it documented in the Classpath/VM integration guide?
If it is something only used by Classpath, then I think this approach
should solve the bootstrap issue:
public final class Locale implements java.io.Serializable, Cloneable
{
// NOTE: These static finals must be initialized with the trusted
// constructor to avoid bootstrap cycles with String.toUpperCase.
/**
* Locale which represents the English language.
*/
public static final Locale ENGLISH = new Locale(en, , true);
...
/**
* Creates a new locale with trusted versions of the strings. This is
* necessary to avoid bootstrap cycles with String.toUpperCase.
*
* @param language lowercase two-letter ISO-639 A2 language code
* @param country uppercase two-letter ISO-3166 A2 contry code
* @param ignored just for the type signature
*
*/
private Locale(String language, String country, boolean ignored)
{
this.language = language;
this.country = country;
variant = ;
hashcode = language.hashCode() ^ country.hashCode();
}
private static Locale defaultLocale =
new Locale(System.getProperty(user.language, ),
System.getProperty(user.region, ), true);
String.toUpperCase uses the default locale
public String toUpperCase()
{
return toUpperCase(Locale.getDefault());
}
We have little choice here, the Javadoc requires this behavior, as well
as a NullPointerException in toUpperCase(null). If it is still needed,
though, we could add a bootstrap flag in String that the VM must set
when bootstrapping is complete. The only use of the locale in
toUpperCase and toLowerCase is to special case two characters in the
Turkish locale.
I just committed my hack shown above - did it do the trick for you?
(How I wish that I could compile a working VM on cygwin, to answer that
question for myself).
--
This signature intentionally left boring.
Eric Blake [EMAIL PROTECTED]
BYU student, free software programmer
___
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath
