Re: BitSet
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Please post to a public mailing list instead of private developers'
addresses (I no longer have time to actively contribute to classpath).
According to R.T.J.M. van der Heijden on 3/27/2006 7:42 AM:
Dear Tom and Eric,
I found your e-mail addresses in the source code of a Java class
'BitSet'. For a software project, I want an efficient implementation
that counts the number of bits that overlap (intersect) between sets. Of
course, I can create a new set as being the intersection between the two
sets and then determine the cardinality of that. After the count is
available, the newly created intersecting set becomes garbage. However,
it could be much more efficient to calculate and return the overlap
directly by accessing the bits variable in both sets (I give a possible
implementation below). Unfortunately, this is not possible because the
'bits' variable is private in BitSet.
Considering the above, I would suggest to set the accessibility of the
'bits' variable to 'protected', or to add some kind of overlap-counter.
Having 'bits' set to 'protected' allows more extensions, of course.
Sorry, but Classpath strives for compatibility with the Sun
specifications, which will not permit making fields publicly accessible
that are not documented as such.
However,
I think you might have other suggestions on how to solve this problem.
I would be glad to hear from you.
Best regards,
Rene van der Heijden
///
// The following is a suggested part of an extension of BitSet, or part
of BitSet itself //
///
int countOverlap(BitSet OtherSet)
// counts the number of bits in the intersection of This and the
OtherSet without intervenence of a new set
{
// determine the length to test
int n = Math.min(bits.length,OtherSet.bits.length);
// count the overlap; taken from the implementation of cardinality
int overlap = 0;
for (int i = n - 1; i = 0; i--)
{
long a = bits[i] OtherSet.bits[i];
// Take care of common cases.
if (a == 0)
continue;
if (a == -1)
{
overlap += 64;
continue;
}
// Successively collapse alternating bit groups into a sum.
a = ((a 1) 0xL) + (a 0xL);
a = ((a 2) 0xL) + (a 0xL);
int b = (int) ((a 32) + a);
b = ((b 4) 0x0f0f0f0f) + (b 0x0f0f0f0f);
b = ((b 8) 0x00ff00ff) + (b 0x00ff00ff);
overlap += ((b 16) 0x) + (b 0x);
}
return overlap;
}
A good garbage collector recognizes temporary objects that are created for
a single use, and then discarded. I doubt adding a method will buy you
much improvement.
- --
Life is short - so eat dessert first!
Eric Blake [EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2.1 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFEJ/uC84KuGfSFAYARApNOAKDMbxNTxx+KSqoG3iuJLbp83ERvnwCgiHmF
UH6/WwVtUYWRFGEux+SYDJ0=
=y6mw
-END PGP SIGNATURE-
Re: update gnu classpath to Unicode 4.0.0
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 [I don't read the address the private mail was sent to as often, but am still subscribed to classpath via a newer address. Hopefully this is okay to forward to the list.] According to Anthony Balkissoon on 1/31/2006 11:43 AM: Hi Eric, I noticed you were the one that wrote the GNU Classpath scripts to read the Unicode data and generate the java files needed. I want to update these to Unicode 4.0.0 but am unsure what this entails. Could you perhaps suggest what you think will need to be done to make the scripts useable for 4.0.0, which assigns code points for supplementary characters? I didn't write unicode_muncher.pl, just updated it from unicode 3.0 to 3.1. I think the bulk of the work will just be making sure that you enumerate for all characters, instead of stopping at 64k. I'm not sure if you will have to shuffle any bitfield sizes to fit the additional data, but I do recall that the script looped through several block sizes to choose the size that resulted in the smallest table. Also, was the encoding used (lower 5 bits for type of character, upper 9 bits for offset into attribute tables) something you designed yourself or is that something that came from the Unicode specs/docs? Inherited from the previous coder. In fact, I liked gcj's unicode-muncher.pl so much at the time that I rewrote Jikes' unicode parser (written in Java instead of Perl) to use the same packing concept. The differences are that Jikes needed less information (it was only making sure which characters were legal in identifires, instead of a full-blown implementation of java.lang.Character), and that by writing it in Java, then running against Sun's JDK, I picked up Sun's interpretation of Unicode 4.0, instead of parsing Blocks-4.0.0.txt myself; but ISTR that the results turned out the same. Before I stepped down as a Jikes maintainer, I managed to update the jikes' version of the script to build a packed table based on Unicode 4.0: http://cvs.sourceforge.net/viewcvs.py/jikes/jikes/src/gencode.java?rev=1.14view=markup Hopefully that can give you some ideas of where to proceed with the perl script. Thanks for any help you can offer! --Tony - -- Life is short - so eat dessert first! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFD50yj84KuGfSFAYARAnKXAJ9N26VY4vkh+FdlOpfHFaTM7Y7kAQCgtPHk no7WAhhnkuLRKVHDEdf+zPo= =fguU -END PGP SIGNATURE-
Re: fix to LinkedHashMap.java
Sorry I haven't cleaned my inbox in a while, you mailed an account I no longer actively track, since I no longer have time to actively develop on classpath. Please send bug reports to the project mailing list, and not an individual developer, if you want faster response. According to Jean-Marie White on 11/18/2004 5:44 PM: Hi Eric, just a quick note to let you know that I fixed a bug in LinkedHashMap.java. In method void addEntry(Object key, Object value, int idx, boolean callRemove), the remove call should read: remove(root.key) and not remove(root) (You always remove a map entry by key, not by the entry itself) This may or may not have been fixed, but thought would let you know anyway. Thanks for your implementing the class in the first place!!! jm ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: Patch: remove C++ keywords
Tom Tromey wrote: My only comment or criticism is that, in the absence of regular checking for this, we'll just see more code like it checked in. That's been the experience with non-C89 constructs, I don't see why this would be any different. It's just too hard to remember to write in some language subset without compiler-assisted checking. To avoid regressions, would we want to use a common header file to #define the C++ keywords into something that will generate a compile-time error when compiling under C? That is #define this do not use C++ keywords, JNI must compile in C and C++ -- Someday, I might put a cute statement here. Eric Blake [EMAIL PROTECTED] ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: An interessting change for shared char[] in String/StringBuffer
Tom Tromey wrote: == Chr Ullenboom [EMAIL PROTECTED] writes: From http://java.sun.com/j2se/1.5.0/jcp/beta1/index.html#java.lang: In this release, the sharing between String and StringBuffer has been eliminated. Does this mean to change to change the implementation in Classpath too? I like this optimization... I don't think we necessarily have to change this. IMO it would depend on whether the change is observable by user code. Our implementation doesn't always share, anyway. It only shares if the buffer is mostly in use. Part of Sun's rationale for their change is that in 1.5, they introduced java.lang.StringBuilder, a non-synchronized copy of StringBuffer with otherwise identical semantics. Similar to gnu.java.lang.StringBuffer used in gcj, if StringBuilder exists, it allows the compiler to emit more efficient string concatenation (and jikes already knows how to use it). My understanding of Sun's implementation of StringBuilder is that it is rather simplistic (based on a bug report to Sun's site complaining that the javadoc was misleading because of the non-public superclass) - they renamed the old StringBuffer into a new package-private class java.lang.AbstractStringBuffer (or some such name) for all the implementation, then created StringBuffer and StringBuilder as public extension classes with no further implementation (other than the fact that all the StringBuffer methods add synchronization). So perhaps they made the change on sharing the char[] because their class-shuffling broke something. I agree with Tom that we would have to benchmark it to see if sharing or not sharing is more efficient, before blindly choosing one way over the other just to match Sun. If I understand correctly, back in JDK 1.0, Sun did NOT use char[] sharing - it was added later as an optimization before JIT compilers were as good as they are now (and now Sun claims to be deleting it as an optimization). Also, we will have to be careful that we handle serialization of StringBuffer correctly, whichever way we choose. I also wonder if the following implementation would be more efficient. In the common case, StringBuffer/StringBuilder is used for appends, and then converted to a String just before being discarded. Currently, for every append, we adjust the underlying char[] and copy the appended String into that array. Would it be better to just build a String[] that caches all the appended Strings, and then create a single char[] at the time toString() is called, rather than updating the char[] for every append()? Of course, we would have to create the char[] for any non-append() method. And one of the disadvantages of this method is that we end up creating intermediate Strings when we append primitive types, whereas the current implementation can update the char[] without creating any intermediate objects. I haven't coded this up to experiment on the difference, but it would be an interesting experiment. -- Someday, I might put a cute statement here. Eric Blake [EMAIL PROTECTED] ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: Jikes 1.19 released
I'm glad you forwarded this announcement on to the Classpath list, Mark (yes, I'm one of the main jikes hackers). The jikes project would appreciate feedback on which new warnings are too pedantic to be on by default (for example, naming-conventions); we enabled them this release because it is easier to turn something off after feedback than to leave it off and people never learn that it exists. Comments are welcome to jikes AT www-124.ibm.com. I also recommend upgrading to jikes 1.19 when compiling classpath, because it has fixed bugs that are present in previous releases, which may affect the validity of Classpath code. Mark Wielaard wrote: Hi all, The Jikes compiler hackers made a new release. Some interesting new improvements: Command line options have been improved. Some pedantic warnings are controlled by name, so that you can select which warnings you get (for example, not everyone wants to know that 1L is preferred over 1l when writing a long literal). More switches have long names. Default state of switches now printed with --help. New switch -Xswitchcheck: Warn about fallthrough in switch statements (compatible with javac). New switch +Pnaming-convention: Warn about naming choices that violate Java's naming conventions. This switch is currently ON by default, +Pno-naming-convention will disable it for sites that use a different naming convention. New switch --noassert: Omits assertions from .class files (not recommended for normal development, but provided to allow you to do -source 1.4 -target 1.3). Now supports -target 1.4.2 (compatible with javac, no changes from -target 1.4 in emitted code). Error text has been improved for method calls, to list the parameter types the compiler is trying to match. Error text on duplicate declarations tries harder to list the original declaration. Static checks have been added for a variety of common Java mistakes, including empty catch and finally blocks, accidental overloading of the equals method, classes implementing equals but not hashCode (or the other way around), interfaces used as enums, missing private constructors to prevent instantiation of utility classes, overly-general throws clauses, public static final array fields, returning null instead of a zero-length array, and deviations from standard Java naming conventions. See/Get it here: http://www-124.ibm.com/developerworks/downloads/detail.php?group_id=10what=releid=686 If you have time, please try it out on GNU Classpath and see if these new warnings point out anything interesting. You want to add +Pno-naming-convention since the new jikes otherwise generates lots and lots of warnings. Cheers, Mark -- Someday, I might put a cute statement here. Eric Blake [EMAIL PROTECTED] ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: bug in java.util.Map
[Shoot, I hit send too early.]
For that matter, you should delete the static modifier. Inner classes
declared in an interface are implicitly 'public static'.
Matthias Pfisterer wrote:
Hi,
I found a minor bug in java.util.Map: the inner class Entry has to be
public. Diff is attached.
Matthias
Index: java/util/Map.java
===
RCS file: /cvsroot/classpath/classpath/java/util/Map.java,v
retrieving revision 1.11
diff -u -r1.11 Map.java
--- java/util/Map.java 15 Oct 2003 12:29:35 - 1.11
+++ java/util/Map.java 20 Jan 2004 20:34:32 -
@@ -264,7 +264,7 @@
* @since 1.2
* @status updated to 1.4
*/
- static interface Entry
+ public static interface Entry
{
/**
* Get the key corresponding to this entry.
--
Someday, I might put a cute statement here.
Eric Blake [EMAIL PROTECTED]
___
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath
Re: FYI: Patch: java.awt.image.PixelGrabber
How hard would it be to update the configure/Makefile.am to check that the compiler supports assert, and to enable any command-line option necessary to turn it on? Jikes supports assert when the `-source 1.4' flag is used. Speaking of which, I probably ought to see if I can push out a new version of jikes. And if I do that, I can bump the default source version of jikes to support 1.4 out of the box, with prior source versions requiring the command-line option. It has been more than a year since the last official release, and I have put in several bug fixes since then (although my coding time on jikes, and on classpath, has greatly diminished now that I have graduated from school). Tom Tromey wrote: Mark == Mark Wielaard [EMAIL PROTECTED] writes: Mark Lets keep asserts out of Classpath sources for now since by default not Mark all compilers support it. But I do like to see them in the future if we Mark can actually use them more then in one or two spots. Personally I'd like to see us push the envelope a little and allow `assert'. The lurking issue here is choosing a source language version. For API coverage it is ok to do what we've been doing, namely not pick a version and let things float toward the latest release. This doesn't work too well for the source version though. This is going to bite us big time when generics are introduced. Tom -- Someday, I might put a cute statement here. Eric Blake [EMAIL PROTECTED] ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: new jalopy available
I've noticed two general styles of 'sorting' in Classpath sources. Both styles separate the metadata types (all fields are listed, followed by member classes, constructors, methods). Within those groupings, one style sorts all methods alphabetically, and the other sorts methods according to the order which they are listed in Sun's documentation (which tends to be, but isn't always, by common functionality). There is also the question of whether implementation-only members (private or default access) should be mixed in with exposed members (protected or public), or whether they come later. I don't have a general opinion - alphabetical sorting makes it easier to find a method when just reading a file, but following Sun's sorting makes it easier to compare a method to Sun's documentation of how it should behave. Either choice is fine with me, especially since emacs has wrap-around searching. But if Jalopy can make the decision easier, by enforcing a sorting style, it might be worth considering. Mark Wielaard wrote: Hi, On Fri, 2003-11-21 at 23:06, Raif S. Naffah wrote: jalopy is able to handle grouping, and sorting, of class elements (e.g.static field and initialisers, instance fields, constructors, etc...) and separating them with a 1-line separator (2 with a blank line followup). how (strongly) do people feel about enabling this? I don't like that very much. I like it when methods are grouped logically (same kind of methods) together. Although simply adding all constructors, static fields and field members together is probably OK. Cheers, Mark -- Someday, I might put a cute statement here. Eric Blake [EMAIL PROTECTED] ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: new jalopy available
Michael Koch wrote: Serializable classes have to have their fields in the same order as in in SUNs classes because of serialization issues. I thought we already had the style rule that all serialized classes provide an explicit serialVersionUID - because we cannot depend on the compiler to generate the same serial version as Sun. Case in point: when a class literal appears in the class, Sun emits a one-argument class$ method, but jikes emits a two-argument version; this affects the serial version. Also, as long as the serial version is correct, deserialization is name-based (not offset-based). Therefore, field ordering does not matter, so long as we provide the explicit UID. -- Someday, I might put a cute statement here. Eric Blake [EMAIL PROTECTED] ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: [really patch] Re: HashMap putAll/putAllInternal bug
I just thought of another argument for changing the Map.putAll implementations
to use hasNext(), rather than size(). Sun's proposal for JDK 1.5 includes
adding a foreach construct, documented in JSR 201. According to their
proposal, the syntax:
for (Object o : mymap.keys()) { /* use o */ }
will be short for
for (Iterator i = mymap.keys().iterator(); i.hasNext();)
{
Object o = i.next();
/* use o */
}
Sun seems to be blessing the use of hasNext() here, by not documenting that
this should optimize to calling size().
I also agree that correctly calculating size() for a list composed of two
other lists is easy, but for a set composed of two other sets is difficult,
because of the set property that duplicate elements be counted only once.
David Holmes wrote:
Stuart Ballard wrote:
because the code that's causing a problem is in HashMap,
not AbstractMap, and it applies
when a Map of my type is passed to putAll() on a HashMap.
^^^
Stuart I apologize. I had misunderstood the exact nature and source of
the problem. I agree that both Abstractmap and HashMap putAll methods
should use hasNext() of the target collections iterator, not it's
size() method. In fact those methods should use nothing other than the
target collection's iterator as specified in AbstractMap.
David Holmes
___
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath
--
Someday, I might put a cute statement here.
Eric Blake [EMAIL PROTECTED]
___
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath
Re: [really patch] Re: HashMap putAll/putAllInternal bug
Here's an implementation idea that might work for an accurate size() for your
case - maintain a single combined hash map which contains modified elements,
with the submaps being views into the giant map, rather than maintaining the
two submaps and having the combined map be a view.
Instead of key-value, you would have key-valueWrapper, where valueWrapper is
something like:
class valueWrapper {
private static final Object UNUSED = new Object();
Object front; // UNUSED if not in front
Object back; // UNUSED if not in back
}
The big map is maintains all three maps with independent size counts for the
three views, and the small maps would just need to be custom implementations
of AbstractMap that wrap the big map to provide the appropriate view,
modifying their particular size count as appropriate.
Of course, having the small maps as wrappers of the big adds another layer of
indirection, which may affect your performance, but at least size() would be
O(1) for all three maps.
Stuart Ballard wrote:
David Holmes wrote:
Sure, I can calculate the size. The problem is that doing so requires a
full iteration over the elements of both sets: you can't just sum the
sizes, because you have to correctly account for elements that are in
both sets.
That makes this optimization of just looping size() times actually a
pessimization, because you have to iterate over the elements twice
instead of once. I didn't provide a correct implementation of size() for
exactly this reason: I was afraid that it would get called a lot on the
assumption that it's fast, when it's not.
As for why I need this implementation: it's being used for a language
interpreter and provides an implementation of nested scoping of
variables. Performance is important because it gets used a LOT. I wanted
to make sure that creating a new scope was cheap and didn't affect the
parent scope (it does caching to make sure that gets are cheap too). The
reasons why both the front and back scope need to be able to change
directly are complicated but (as far as I've found so far) unavoidable.
--
Someday, I might put a cute statement here.
Eric Blake [EMAIL PROTECTED]
___
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath
Re: Declaring RuntimeExceptions?
I agree with Tom that we should not declare unneeded exceptions, even when Sun does. Not all compilers emit RuntimeExceptions into the .class file to begin with. Reflection data is not guaranteed to be the same between two compilers, even if you DO declare the RuntimeExceptions, because compilers have the right to optimize for size and omit wasting the space on the useless declaration information. Therefore, code relying on the declared RuntimeExceptions returned by reflection is just asking for problems. David Holmes wrote: Standard practice - as epoused by various books and articles from various source related to Sun - is to not declare RuntimeExceptions on a throws clause. Such exceptions should be documented in the javadoc only. However, the reflection issue is not something I was aware of. If indeed reflection returns all declared throwables whether runtime exceptions or not, then there will be a behavioural difference - though not one that anybody should ever be relying upon. This situation is also clouded by the default rules for inheriting @throws documentation comments, which will only inherit comments for exceptions that are listed in the throws clause. The way around this is to not declare the exception but instead to the use @inheritDoc to force the inheritance of the doc comment eg: @throws someRuntimeException [EMAIL PROTECTED] but some people may start declaring the runtime exceptions just to inherit the doc comments. David Holmes ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath -- Someday, I might put a cute statement here. Eric Blake [EMAIL PROTECTED] ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: Jikes RVM mauve tests
Brian Jones wrote: David P Grove [EMAIL PROTECTED] writes: Hi, I've been experimenting a little bit with running Mauve tests on top of Jikes RVM and GNU Classpath. This generally does pretty well, except that there are massive failures on java.lang.Character.unicode (make check KEYS=!java. java.lang.Character yields 136460 of 3603803 tests failed). Before looking into this further, I just wanted to verify that the classpath libraries are expected to pass these tests. There may be Character problems... I tend not to run it because it (a) takes a while and (b) inflates positive results out of proportion with other class tests. I believe this is another area where gcj/classpath differ as well. I stand by the Classpath version of Character. I updated it to correctly obey the same Unicode version as JDK 1.4, and verified everything against the JDK. However, I never found the time to go and fix Mauve to do the same. So the Mauve tests for Character are currently broken. Back in Feb 02 or so, I posted a patch to gcj to merge as much of Character and String as possible between Classpath and libgcj, but it was never applied (back in the 3.1 days), so I would practically have to start the merge again to catch everything that has happened in both trees in the meantime. -- 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: Class.forName() bug
Jeroen Frijters wrote: Hi, When Class.forName() is called with an array classname (e.g. [LFoo;), it calls classloader.loadClass() with the same string, but this isn't correct. It should instead load Foo and then call a VM native method that constructs the array class. Be careful, though. Class.forName([LFoo;) is documented as NOT initializing Foo; does ClassLoader.loadClass() initialize Foo against our wishes? -- 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: classpath ./ChangeLog java/lang/reflect/Proxy.j...
Michael Koch wrote: CVSROOT: /cvsroot/classpath Module name: classpath Changes by: Michael Koch [EMAIL PROTECTED] 02/12/23 03:30:29 * java/lang/reflect/Proxy.java (h): This member was never final in any jdk release. I'm not sure this change needed to be made. The field h is not publically accessible - it is protected within Proxy, user code should not extend Proxy directly, and internally created proxy classes never change the value of h. I thought making it final (like we made Integer.value final) provided more security from bad reflection code. -- 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: possible bug in TreeMap.sucessor implementation
Dalibor Topic wrote: Since nil is supposed to have children that are also nil it appears that at some point nil.right was assiged a value. would it be possible to make nil an ImmutableNode, so that such assignments are caught and greeted with an Error? that should make your life easier next time you have to debug a similar case. For debugging, yes. For efficiency, no. Creating an ImmutableNode would require reworking the entire TreeMap class to use method calls, rather than field assignments, for manipulating nodes. Adding polymorphic calls is an additional layer of indirection, and will make the overall implementation slower. I still haven't had a good look into the bug, but I have finally got the time to spend on it now, and have reproduced it. So look for a fix by the end of the day (I hope). -- 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: possible bug in TreeMap.sucessor implementation
I'll try looking into this today, since I was the last one to do major changes in this file. Brian Jones wrote: Thanks for the test, it does get stuck in sucessor (). I put in a different toString() on Node in TreeMap and a few println statements in sucessor() to see this repeated output which indicates something went horribly wrong. while (node == parent.right) node = key (29), value(3), color(1), parent(nil), left(non-nil), right(nil) Since nil is supposed to have children that are also nil it appears that at some point nil.right was assiged a value. I'm somewhat concerned about the fact that the Node passed into the method is manipulated quite a bit... objects are pass by reference rather than pass by value so perhaps there are some unintended side affects happening here and in other places too. It will take me some time to review red-black tree stuff and fix this problem. Perhaps someone else who has worked on it before will take up the challenge. Brian -- 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: [Jikes] Bug with -target option
Brian Jones wrote: I didn't set the source option. It is just a HelloWorld program, really, so it doesn't use assertions ;) Should I try setting the source too, i.e. does source default to 1.4 ? My guess would be that it's easy to compile 1.1 source for a 1.4 target, but not the other way around, so that might explain the problem I'm seeing. I'll check and post a reply tonight. Setting the source option to 1.2 solved my problem. I think Classpath sets the -target in lib/Makefile.am for jikes compiles to 1.1 without setting the -source option. Should something be changed then? The point was mainly to make emitted class files useful to 1.1+ JVMs. I have just recently changed the behavior of -source and -target in the CVS version of jikes (post 1.18). Before, if you set -target, you could not parse assert. But now, -source and -target are sufficiently independent. With the addition of the new command-line option --noassert, you may compile code with assert statements while still emitting code workarounds necessary for running on 1.1 JVMs. For now, jikes 1.18 and CVS jikes default to -source 1.3 and -target 1.3 if neither is specified, to be drop-in compatible with the behavior of javac in JDK 1.4.1_01. -- 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: build failure
It's probably the same bug in Jode as is causing problems with jdk1.4 class files. I wonder what jikes is doing that Jode can't handle... Brian Jones wrote: And there is a reason why I didn't use jikes to begin with... japize barfs (jode actually) in java.applet with an ArrayIndexOutOfBoundsException. Processing package java.applet,:=Exception in thread main java.lang.ArrayIndexOutOfBoundsException: 38 at jode.bytecode.BytecodeInfo.read(BytecodeInfo.java:843) ... -- 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: Synchronization in java.util.Collections
Dalibor Topic wrote: Hi, I've looked over Classpath's implementation of synchronized* methods in java.util.Collections, and I don't understand why the synchronized wrapper classes sync on their own specific mutex field instead of syncing on themselves? i.e. why not have all the wrapper methods synchronized and drop the mutex field? That's how kaffe does it. They sync on the specified mutex so iterators (which are different instances) can sync on the same mutex. It is also essential for correctly implementing things like Map.subMap(), where the sub-map must synchronize on the original map. -- 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: package private static equals and hash methods in java.util
Dalibor Topic wrote: Hi, a couple of classes in java.util have the same implementation of a static final equals and hashCode method taking two arguments. What is the reason why not all the calls are delegated to a single implementation, say AbstractCollection.equals/hashCode instead of duplicating the code ? Because I was lazy - using inheritance, I could just type equals(a, b), instead of the full Collections.equals(a, b) if the helper methods lived in a single file. Feel free to change that if you want. -- 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: mauve results posted nightly
(where INTERPRETER == gij || Sun j2sdk 1.4 java) produced almost identical files but there were a few small differences. I also haven't looked into this yet. (diff attached) But this is probably one of the runtimes picking up a constant from its own runtime library and not from the GNU Classpath glibj.zip file. --- gij.out 2002-11-14 22:18:50.0 +0100 +++ j2sdk.out 2002-11-14 22:18:26.0 +0100 @@ -640,7 +640,7 @@ java.lang,Compiler!wait(J,I) Pcif V*java.lang.InterruptedException java.lang,Double! Pcif class#-9172774392245257468:java.lang.Number:java.lang.Object*java.lang.Comparable*java.io.Serializable java.lang,Double!#MAX_VALUE Pcsf D:1.7976931348623157E308 -java.lang,Double!#MIN_VALUE Pcsf D:5.0E-324 +java.lang,Double!#MIN_VALUE Pcsf D:4.9E-324 This diff is a result of bugs in Double.toString() within the VM. It is the underlying double value in both VMs, but a different string representation. The correct string is 4.9E-324. Perhaps japize should use Double.doubleToLongBits() to compare the bitwise value of double constants (likewise Float.floatToIntBits()). -java.lang,Float!#MIN_VALUE Pcsf F:1.4012985E-45 +java.lang,Float!#MIN_VALUE Pcsf F:1.4E-45 Likewise. The correct string should be 1.4E-45. -- 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: mauve results posted nightly
Stephen Crawley wrote: Perhaps japize should use Double.doubleToLongBits() to compare the bitwise value of double constants (likewise Float.floatToIntBits()). That would be a bit safer, considering that even JDK 1.4.x has minor bugs in its implementations of double - string translation! However, even comparing the bits returned Double.doubleToLongBits() is not strictly correct, because the Java VM spec says that VMs are allowed to use a range of bit patterns to represent NaN values. Double.doubleToLongBits is specified to flatten all doubles to the canonical version of NaN, 0x7ff8L. You're thinking of Double.doubleToRawLongBits where NaN can be from a range of values. Mauve tests whether an implementation actually obeys this rule. Of all the compilers and VMs I have seen for Java, the only one that currently gets double-String and float-String conversion 100% correct is jikes, version 1.16 or later. There are several tests in the Jacks test suite for corner cases of string conversion; but I ought to port them to Mauve as well, to have runtime as well as compile-time tests. (BTW, Sun JDK 1.4.x also has bugs in the string - double translation, and I know at least one string which sends Sun's Double.parseDouble, and thus javac, into an infinite loop). The safest way for for japize to compare Java doubles (and floats) is to do the following: double d1, d2; ... boolean sameValue = (Double.isNaN(d1) Double.isNaN(d2)) || (d1 == d2) Note: you have to test NaNs separately because the Java VM spec says that (NaN == NaN) always gives false!! Not just the JVM - IEEE 754 also specified this relation! But your test above does not work for 0.0 vs. -0.0. The best comparison is (Double.compare(d1, d2) == 0), added in JDK 1.4; or (new Double(d1).compareTo(new Double(d2)) == 0) in JDK 1.2. If you want japize to work with JDK 1.1, just copy the implementation of these methods from Classpath or libgcj. These methods are tested by mauve. -- 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: build failure
Stephen Crawley wrote: Today I updated and rebuilt classpath. I use `--with-jikes --with-jni' to compile. I'm using jikes 1.15. There were a bunch of errors. I've been seeing similar errors with Jikes 1.16 for the last few days. [I wish people would compile with Jikes or javac before checking in changes. Gcj's error checking is very lax.] Jikes 1.17 is much better than 1.15 or 1.16 in terms of producing correct bytecode in several situations. But that version also fails on the current tree; it looks like some import problems in the java.nio package, but I haven't tried to fix it yet. I'm not sure about compiling the tree with javac; and even if that works, I won't recommend it since it is not a free compiler. -- 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: mauve results posted nightly
What's wrong with TreeSet.subSet? Let's get that fixed! Stuart Ballard wrote: Well, that was my point - my understanding is that it currently fails due to the fact that neither Classpath nor Kaffe have a working implementation of TreeSet.subSet(). I proposed a hacky implementation of subMap (which subSet depends on) that would be sufficient to give Japize a fighting chance of running. I think that subSet is the only part of *my* code that free VMs can't currently handle; I'm not sure whether they can handle Jode or not though. Stuart. -- 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: LinkedHashMap.java: circular?
Ype, feel free to borrow the ideas of LinkedHashMap to write your own efficient version of a caching ordered hash table. Writing your own version may be the best in the long run, because you can be more efficient (such as actually overriding put(), instead of having to use the addEntry() hack to remain API compatible). However, your question led me into poking around in the code. Classpath's current version has a bug in that it changes access order via the entrySet().iterator(), when the docs say this should not happen. Also, I do not feel that the Classpath version can be optimized into a circular list, because of the API of removeEldestEntry() - it is guaranteed to be called after the insertion but before the deletion, and the user has the right to see the list in that state. Well, maybe a circular list is possible, but the list must have one more element than what size() normally reports to avoid object creation in the event of a likely entry removal. I'll play with the idea, and see if I can improve the code, but I doubt it. I'll see about fixing my bug in the near future, as well as committing a testcase to mauve. Ype Kingma wrote: Eric, I'm referring to the current cvs version from subversions.gnu.org:/cvsroot/classpath . The other day I needed a lru cache in jython (ie. python implemented in java) and I found that LinkedHashMap.java would do the job well, except that I'm currently forced to use java 1.1 and the collections replacement for 1.1 does not include a LinkedHashMap. That meant I needed to write a linked hash map with a doubly linked list and a maximum capacity in python. With the maximum capacity constraint I found that when implementing the doubly linked list as a circular list the insertion of a new element when the cache is full (ie. the normal case) can be implemented nicely by updating the oldest element and simply moving the list head and tail pointers one element. This also saves the creation of a new list element. My question: Since this is probably a frequent use of LinkedHashMap I wondered whether a circular list might be a good alternative for the current implementation of the LinkedHashMap, in which the head and tail elements have their prev and succ pointers set to null. Anyway, in case I run into memory problems with my current python implementation I'm probably going to use your LinkedHashMap class in java 1.1 as it is. For use as list elements, python objects in java are far too large, they have an associated dictionary for their fields. Thanks and regards, Ype -- 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: serialVersionUID (again)
Your summary seemed good to me. Mark Wielaard wrote: What I don't understand is why it is so hard to specify the actual accessor methods. Does anybody know why they were never clearly specified? Partly because it was a hack added in JDK 1.1. To maintain the most possible backward compatibility with 1.0, the whitepaper spec for adding inner classes gave recommendations for things like this$0 for the enclosing class, Outerclass$num for anonymous classes, class$(String) as the method to compute class literals, access$num() for accessors, and val$i for accessing a final local variable in a local class. But none of these were set in stone, in an attempt to avoid polluting the user's namespace. Only one naming scheme was required, rather than recommended - and that was that member classes (such as Outer.Inner) be given the name Outer$Inner, because it affects how a compiler finds inner classes when referenced from other .java files. Likewise, the specification requires that non-private constructors of non-static member classes have an additional first parameter for the enclosing class (but parameter names are not specified). All other compiler-generated names are local to a .java file, so the name chosen really doesn't matter. In the 2nd edition JLS, this scheme was maintained - chapter 13 of the JLS specifies ONLY the naming scheme of member classes, and leaves everything else to the compiler. It is up to the compiler to avoid name clashes with the user's code, and JLS2 does not prohibit a user from naming things in his class with names that would clash with the whitepaper suggested names. (In my opinion, the choice of keeping '$' as a legal user identifier character is deplorable - if Sun had truly wanted to keep compiler names and user names separate, they should have given the compiler a unique character or namespace for naming synthetic constructs). If both Tom Tromey and Eric Blake say that although theoretical possible, it is too difficult for us to ensure compatibility in the free compilers with the proprietary Sun javac naming scheme and other synthetic stuff I think that are current policy (always add serialVersionUID if the class is Serializable) is a good one. What do others think? Should we try to reverse engineer the naming scheme? Or do we keep the current policy? Or we could even ignore being serializable compatible with the Sun JDK till this is clearly specified. I don't think it ever will be clearly specified what accessor methods must be named - I think it is up to the compiler to choose its naming scheme. And, if I am correct about compiling the Foo.class literal, jikes will never compile serial versions compatibly with javac, because jikes relies on class$(String, boolean) to avoid initializing the class, whereas javac is still using class$(String) and incorrectly initializing classes when evaluating the .class literal. So I am okay with the proposal to always add a serialVersionUID to all Classpath files (with libgcj, I'm not as sure that it is necessary, except for the hassle of maintaining two sources). But I may be a bit biased, so I look forward to other's views on the matter. -- 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: serialVersionUID
If a class has a field (of any accessibility) named serialVersionUID of type long, that is what serialver uses. Otherwise it computes a value using some sort of hash function on the names of all method signatures in the .class file. I'm not sure whether the methods are sorted first, or what the hash function is. The fact that different compilers create different synthetic method signatures, such as access$0() if an inner class needs access to a private member of an enclosing class, make it impossible for two distinct compilers to reliably generate the same serial #, because their .class files differ. However, once you have a .class file, its serial # is unique, and the computation will give the same result no matter what platform you execute on. Giannis Georgalis wrote: Thank you Eric, I however had to run the serialver tool on a i386/solaris8 system (I didn't want to install sun's SDK on my computer, just for the serialver tool). Does the output match every system ? Is there a posibility that there are different serialVersionUIDs for different systems? -- 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: serialVersionUID
It is necessary for serialization, although it is usually a private field. ALL classes in classpath which implement java.io.Serializable should declare this field, and it should match the results of running Sun's serialver tool on that class; otherwise, Classpath will not be compatible for serialization. java.io.ObjectStream uses the value of this field to see if two class versions are compatible. This field is needed in Classpath even when Sun's jar does not have the field. (Interfaces which extend Serializable do not need this field). Giannis Georgalis wrote: Hello again from the primary spammer of the GNU classpath list :) I have one question. Please forgive my ignorance, as I'm new to the classpath project. What is serialVersionUID?, what is it used for? (instanceof operator?), where can I find it's value for a specific class? and should *all* the api classes have this constant? Thank you, Giannis -- 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: jdiff.sh (BETA)
Giannis Georgalis wrote:
Hello again,
After some useful comments and a bug report by Michael Koch, jdiff.sh
0.0.1 (BETA) now works in the following ways:
* Handles interfaces correctly ... Give me some help here; When you
have a public interface do all the methods-fields default to public?
I always explicitly declare them public, but that's not the case in
eg. java.net.SocketOptions (is that a valid declaration?)
(Thanks Michael)
Yes, ALL interface members (fields and abstract methods) are public,
whether the user marked them that way or not, and whether the interface
is public or not.
* Extracts the exceptions (from the source code of eg. GNU classpath)
from javadoc comments and _not_ from the methods (or constructors)
signature. Doing the same for the api documentation, makes it
report (correctly?) both checked and unchecked exceptions.
Unchecked exceptions do not need to be reported. There are several
places where Classpath purposefully omits mentioning unchecked
exceptions in the throws clause, because it is just a waste of .class
file size.
For example, these two declarations are equivalent, but the second
compiles to less space:
void m() throws RuntimeException {}
void m() {}
* It still doesn't handle declarations (in .java source) of the type
type ID[], and I did it on purpose because I think declaring it like
this is a bad style as ID is *not* an array of type type (like C/C++
arrays,for example), but a *reference* to an array object of type type.
But If you are *not* in any way willing to declare them as type[] ID,
I will fix it ...
Yes, it may be bad style, and even worse style is int m()[] instead of
int[] m(), but you should still check it, because it will help us
clean up our bad style.
* It ignores the native keyword from the source code.
Good point - whether a method is implemented in Java or natively does
not affect whether the method exists.
Likewise, your code should not worry about the synchronized keyword,
on classes or on methods, because different implementations can
successfully synchronize without marking everything in the same manner.
--
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: Moving com.sun.javadoc packages to cp-tools gjdoc cvs module
No objections here. Besides, having com.sun packages in a free project has always sounded weird to me, since this project is not sponsored by Sun. And, since Sun specifically states that the classes in com.sun are undocumented and subject to change, no external project should be linking to those classes in the first place, so it really isn't part of Classpath. Mark Wielaard wrote: Hi, Any objections to moving the classes from classpath sun/com/javadoc to the cp-tools gjdoc CVS module? Those classes are not really part of the standard java library packages. They are already licensed under the GPL without exception (just like gjdoc). And it would make gjdoc self contained. Cheers, Mark -- 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: recent javadoc change
Sascha Brawer wrote: I agree with Eric, so I'll eventually review my recent commits and undo them as appropriate. However, I think it would be fine to do the release with the Javadoc comments as they are in CVS. What do you think, Eric? I don't think the documentation should hold up the release, since the current documentation in CVS produces valid HTML, even if the formatting in the .java files is questionable. So, feel free to change it at your leisure without feeling pressured to do it before the release. -- 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
FYI: bug in cygwin affects build
I ran into a bug with cygwin 1.3.10 when compiling the latest Classpath with jikes 1.15b. Basically, cygwin is unable to tell the difference between java/net and java/nio in some cases, so it causes jikes to compile .class files to the wrong directory. The bug is detailed in http://cygwin.com/ml/cygwin/2002-04/msg01655.html. It is dependent on the absolute path of the build directory, so it will not appear for all users; and in many cases, if you are bit by the bug, the simplest workaround is renaming the build directory. Or you can wait for the next release of cygwin, when it will be patched, or check out the latest CVS version of jikes where I added a hack to avoid this particular bug. -- 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: Another bug in TreeMap
Yes, it is a bug. I posted the following patch (since I was responsible for this bug in the first place, several months ago): 2002-05-02 Eric Blake [EMAIL PROTECTED] * java/util/TreeMap.java (remove): Fix improper return value. * THANKYOU: Add Xuan Baldauf for spotting this. Index: java/util/TreeMap.java === RCS file: /cvsroot/classpath/classpath/java/util/TreeMap.java,v retrieving revision 1.19 diff -u -r1.19 TreeMap.java --- java/util/TreeMap.java 20 Feb 2002 23:56:46 - 1.19 +++ java/util/TreeMap.java 3 May 2002 04:17:37 - @@ -623,8 +623,10 @@ Node n = getNode(key); if (n == nil) return null; +// Note: removeNode can alter the contents of n, so save value now. +Object result = n.value; removeNode(n); -return n.value; +return result; } /** @@ -1768,7 +1770,7 @@ SubMap.this.clear(); } }; - return this.keys; + return this.values; } } // class SubMap } // class TreeMap By the way, Brian, you forgot to commit TreeMap, so I did it for you. Brian Jones wrote: Xuan Baldauf [EMAIL PROTECTED] writes: In case the node to be removed has two children, within removeNode(), new keys and values will be swapped into the node the which is about to be removed. After removeNode() finished, remove() returns the value variable of that node. Because it was changed previously within removeNode(), the wrong value (from the swapped in node rather than from the original node) is returned. This is a bug. I'm pretty sure that without dusting off my data structures book I couldn't patch this properly. I'm unsure what the point is of setting the key/value of node in the else statement with that node being deleted from the tree. The swap of the node contents saves effort over the additional pointer manipulation that is otherwise required, at the expense of modifying the node so that it is no longer valid in remove(). In short, the code deletes a leaf node, after moving its contents to the original node, so that the net result is deleting the contents of the original node. -- 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: classpath/javax/swing/plaf/basic BasicLookAndFe...
I got tired of the javax.swing tree not compiling, so I touched enough files to at least allow jikes to compile it. That does not mean that I implemented everything, by a long shot, but at least the build doesn't fail now. Eric Blake wrote: Are you remembering to make a ChangeLog entry for all your merges today? Also, are you enabling the build in the appropriate places, such as configure.in? And one more thing to remember - the .cvsignore files. Andrew Selkirk wrote: CVSROOT:/cvsroot/classpath Module name:class path Changes by: Andrew Selkirk [EMAIL PROTECTED] 02/04/25 01:47:23 Added files: javax/swing/plaf/basic: BasicLookAndFeel.java -- 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: Compilation error - More Info
Oops - I missed that file in my commit, this morning after already claiming to have changed it in the ChangeLog. Carlos Cavanna wrote: Hey guys, I checked out classpath today and tried to compile it with jikes 1.15b I found that it still had a small problem, it did not generate Makefile files for anything inside javax/swing. I changed configure.in and now it works OK. Following is the diff. -- 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
recent javadoc change
I have a complaint about this patch to the Javadoc. Sun's tools specifically ignores all leading whitespace up to the first '*' on a line, so that you can include embedded code while still making it match the style of the rest of the comment. * java/util/AbstractList.java (hashCode): Docfix to avoid angle brackets in Javadoc and for pre-formatted code without asterisks. /** * In other words, both style 1: * pre * for (int i = 0; i 10; i++) * System.out.println(i); * /pre * * and style 2: pre for (int i = 0; i 10; i++) System.out.println(i); pre * * should have the same result in the compiled documentation; but I think style 1 is more consistent. */ For more information on Sun's recommendations on doc comment formats, see http://java.sun.com/j2se/javadoc/writingdoccomments/index.html -- 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: Runtime reference implementation buglet
Which way do VM's do it? It might be easier to do if (nativeLoad(filename) != 0), so that the native code can just use the return code from system calls. Brian Jones wrote: Tom Tromey [EMAIL PROTECTED] writes: In the Runtime reference implementation I see this code: if (nativeLoad(filename) == 0) throw new UnsatisfiedLinkError(Could not load library + filename); Later there is this: * @return 0 on success, nonzero on failure */ native int nativeLoad(String filename); One or the other is wrong. I don't know which. Could whoever works on this class please fix this? Thanks. I changed the doc comment since changing the code would break VMs. Brian -- 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: Javadoc Comment Formatting
I am not opposed to doing better markup of comments in my code. As I write doc comments, I have been trying to make formatted lists correctly, use lt; instead of , and other things; but I do not always get it correct. Further, I have not tested my documentation work by running it through any tool, free or from Sun, so I'm sure I have contributed buggy comments. When I code, I prefer to consult well-formatted HTML, XML, or texinfo comments than trying to read comments inline. One reason is that a well-done markup version has hyperlinks that inline code does not, and as nice as etags is for emacs, it's not perfect. I agree with the sentiment that the final output is worth the reduced readability in the source code, but I am willing to go with the majority on this decision, whichever way it gets decided. Julian Scheid wrote: I find this issue not paramount but in order to offer high-quality documentation in various formats, I think we should propose some guidelines for contributors, including the advice to structure comments using (correct) HTML tags where necessary. Reduces inline readability but enhances output readability, integrity, portability and transformability. Wow!! ;) Other opinions are very welcome. -- 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: classpath/javax/swing/plaf/basic BasicLookAndFe...
Are you remembering to make a ChangeLog entry for all your merges today? Also, are you enabling the build in the appropriate places, such as configure.in? And one more thing to remember - the .cvsignore files. Andrew Selkirk wrote: CVSROOT:/cvsroot/classpath Module name:class path Changes by: Andrew Selkirk [EMAIL PROTECTED] 02/04/25 01:47:23 Added files: javax/swing/plaf/basic: BasicLookAndFeel.java -- 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: Bug in java.lang.Double(String)
I still haven't had time to look at the native code, but it is on my todo list. There is an updated upstream source, and I did the native code for the jikes compiler, so I'm familiar with what needs to happen - it is just time-consuming, and I am in the middle of final exams. Max Gilead wrote: Hello! There is a bug in java.lang.Double class. The problem is that string .3 is not recognized as a valid floating point value. According to Java language spec it should be. -- 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: bug in strtod?
strtod has an upstream source, which has been updated since the version included in Classpath. I have not yet had the time to look at updating this, but it is on my TODO list (although not very high priority). Having done floating point work on the Jikes compiler, I am aware of several (minor) bugs in the current Classpath implementation of string/fp and fp/string conversions. The upstream source does use the underlying architecture's floating point unit, where possible, in performing the conversions. And yes, the Java library must implement string conversions itself, to be platform independent to the last bit. In particular, not all platforms are IEEE 754 compliant (let alone compliant to the slight modifications to IEEE 754 required by Java), and not all operating systems/C libraries have bit accurate conversions. Even the x86 architecture has problems - by using 80-bit registers for internal computation instead of 64-bit, there are some off-by-one rounding errors in extreme corner cases. Thomas Hergenhahn wrote: Dear all, I hope this is the right place to post a patch fo libjava. I'm using libjava from GCC-3.0.4 on Linux i386. I tried to convert a string of the form 1.234E+000 to a double using Double.doubleValue(). The result was allways zero (no NumberFormatException). IMHO, this is a bug. I traced that down until finding the responsible lines of code in java/lang/strtod.c. The following patch works for me, but better take a deeper look on it. BTW, why must libjava implement all this itself? Is it to achieve platform independency down to the last bit? Does it take advantage of FPU, if one is present ? Yours sincerely Thomas Hergenhahn -- 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: [Kissme-general] SystemClassLoader fix
John Leuner wrote: I cleaned your patch up a bit, and once I get it to compile, I'm committing it. Thanks for the catch - I documented that the class specified by java.system.class.loader must now have a constructor which accepts a parent class loader. It wasn't really a patch, just a demonstration of the problem. Any reason why it wouldn't compile? Yes - the patch as it appeared in my reply to your email was hastily written and untested (ie. I wrote the patch and replied to your email before starting the time-consuming compilation and regression testing process). I think the only change I had to make before committing it, however, was adding an import statement. And it has been in CVS for nearly a week now. -- 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
FYI: configure update
I just upgraded my autotools to automake 1.6, autoconf 1.53, and libtool
1.4d, and in the process had to tweak configure.in to get Classpath to
build again. Can someone more familiar with these tools check that my
patch is correct?
I also took the liberty of making all the variable tests consistent,
turning things like
if test $foo = ; then
into
if test x${foo} = x; then
2002-03-28 Eric Blake [EMAIL PROTECTED]
* .cvsignore: Add autom4te.cache to ignored list.
* configure.in: Move CLASSPATH_WITH_JAVAH and
CLASSPATH_WITH_INCLUDEDIR out of conditionals, for use with latest
autotools. Make variable tests consistent.
* acinclude.m4: Make variable tests consistent.
--
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: [Kissme-general] More Classpath change problems
I cleaned your patch up a bit, and once I get it to compile, I'm
committing it. Thanks for the catch - I documented that the class
specified by java.system.class.loader must now have a constructor which
accepts a parent class loader.
John Leuner wrote:
I tracked this down to the ClassLoader class.
Otherwise getSystemClassLoader gets in an infinite loop where the Constructor for
SystemClassLoader calls the ClassLoader() constructor which tries to use the system
class loader as the parent classloader and round and round it goes ...
John Leuner
2002-03-28 John Leuner [EMAIL PROTECTED]
* java/lang/ClassLoader.java (getSystemClassLoader): Break
infinite loop by specifying parent classloader.
* gnu/java/lang/SystemClassLoader.java (SystemClassLoader): Add
proper constructor.
--
This signature intentionally left boring.
Eric Blake [EMAIL PROTECTED]
BYU student, free software programmer
Index: gnu/java/lang/SystemClassLoader.java
===
RCS file: /cvsroot/classpath/classpath/gnu/java/lang/SystemClassLoader.java,v
retrieving revision 1.1
diff -u -r1.1 SystemClassLoader.java
--- gnu/java/lang/SystemClassLoader.java22 Mar 2002 21:25:20 - 1.1
+++ gnu/java/lang/SystemClassLoader.java28 Mar 2002 21:36:04 -
@@ -64,6 +64,17 @@
/** Flag to avoid infinite loops. */
private static boolean is_trying;
+
+ /**
+ * Creates a class loader. Note that the parent may be null, when this is
+ * created as the system class loader by ClassLoader.getSystemClassLoader.
+ *
+ * @param parent the parent class loader
+ */
+ public SystemClassLoader(ClassLoader parent)
+ {
+super(parent);
+ }
/**
* Get the URL to a resource.
Index: java/lang/ClassLoader.java
===
RCS file: /cvsroot/classpath/classpath/java/lang/ClassLoader.java,v
retrieving revision 1.16
diff -u -r1.16 ClassLoader.java
--- java/lang/ClassLoader.java 22 Mar 2002 21:25:20 - 1.16
+++ java/lang/ClassLoader.java 28 Mar 2002 21:36:05 -
@@ -48,6 +48,7 @@
import java.util.Enumeration;
import java.util.HashMap;
import java.util.Map;
+import gnu.java.lang.SystemClassLoader;
import gnu.java.util.DoubleEnumeration;
import gnu.java.util.EmptyEnumeration;
@@ -685,7 +686,8 @@
* property codejava.class.path/code. This is set as the context
* class loader for a thread. The system property
* codejava.system.class.loader/code, if defined, is taken to be the
- * name of the class to use as the system class loader, otherwise this
+ * name of the class to use as the system class loader, which must have
+ * a public constructor which takes a ClassLoader as a parent; otherwise this
* uses gnu.java.lang.SystemClassLoader.
*
* pNote that this is different from the bootstrap classloader that
@@ -713,12 +715,28 @@
gnu.java.lang.SystemClassLoader);
try
{
-return (ClassLoader) Class.forName(loader).newInstance();
+// Give the new system class loader a null parent.
+Constructor c = Class.forName(loader).getConstructor
+ ( new Class[] { ClassLoader.class } );
+return (ClassLoader) c.newInstance(new Object[1]);
}
catch (Exception e)
{
-throw (Error) new InternalError
- (System class loader could not be found: + e).initCause(e);
+try
+ {
+System.err.println(Requested system classloader
+ + loader + failed, trying
+ + gnu.java.lang.SystemClassLoader);
+e.printStackTrace();
+// Fallback to gnu.java.lang.SystemClassLoader.
+return new SystemClassLoader(null);
+ }
+catch (Exception e1)
+ {
+throw (Error) new InternalError
+ (System class loader could not be found: + e)
+ .initCause(e);
+ }
}
}
// Check if we may return the system classloader
Re: minimal hack to classpath for ORP 1.0.9
Fred Gray wrote:
I did a cvs update to get your changes, and I copied the native method
insertSystemProperties() from VMSystem to Runtime. ORP still crashed.
*Dictionary, Hashtable, and Properties have no dependencies
This is the where the chain broke. Adding the properties to the Hashtable
calls Hashtable.hash(), which calls Math.abs(). That causes the static
initializer for Math to be run, and it calls System.loadLibrary().
Kaboom.
Man, those dependencies are annoying. Would using StrictMath.abs() in
place of Math.abs() work, since StrictMath doesn't use native methods?
Then again, inlining the check for absolute value saves a method call.
I'll go ahead and apply that patch you suggested.
The last problem is that the native method System.isWordsBigEndian()
is needed by the static initializer for System before the Classpath java.lang
JNI library is loaded. I enabled ORP's built-in version of this method
(which takes the super-portable return false approach to the problem).
At long last, Hello world! appeared.
I thought, in my analysis yesterday, that System.isWordsBigEndian
wouldn't be called until after System.loadLibrary(javalang), called in
Object.clinit, has completed. But thinking about it more, I guess you
are right - Object.clinit invokes the System class initializer, which
then executes to completion before returning to Object.clinit; and
System.clinit does use the native method. My patch yesterday just
deleted the line in System which called loadLibrary(javalang),
thinking it was redundant; I guess I was wrong, so I'll add it back in
and document it this time.
The last part of this message is a patch against the pristine ORP 1.0.9 release
@@ -344,7 +346,6 @@
//{ java_lang_System_currentTimeMillis, (void *)
Java_java_lang_System_currentTimeMillis, NI_IS_JNI },
{ java_lang_System_currentTimeMillis, (void *)
Java_java_lang_System_currentTimeMillis_no_extra_args, NI_IS_DIRECT },
-{ java_lang_System_isWordsBigEndian, (void *)
Java_java_lang_System_isWordsBigEndian, NI_IS_JNI },
{ java_lang_System_setErr, (void *) Java_java_lang_System_setErr,
NI_IS_JNI },
{ java_lang_System_setIn, (void *) Java_java_lang_System_setIn, NI_IS_JNI
},
{ java_lang_System_setOut, (void *) Java_java_lang_System_setOut,
NI_IS_JNI },
The last three methods in this section of the patch have been renamed
java_lang_System_setErr0, setIn0, and setOut0, because there must be a
security check in Java first. You should probably fix those as well, to
avoid another linkage error.
--
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: minimal hack to classpath for ORP 1.0.9
Fred Gray wrote: I think I've figured out the minimal hack to the current classpath CVS to work with ORP 1.0.9 (at least for programs of the complexity of Hello world). Hopefully, this will give the people who understand ORP some ideas on how to fix things up properly. Issue 1: Calling methods in java.lang.System from the constructor of java.lang.Runtime seems to cause a crash. What is the crash you are getting? I agree that your hack will prevent calling java.lang.System, but it limits the library search path to ., which is most likely wrong: what if any of the core classes need system properties during the bootstrap phase, such as for grabbing a locale resource file? We already have VMSystem.insertSystemProperties, which System uses to initialize the default properties. Would it be worth moving the default properties from System over to Runtime (the way the default security manager was moved), and having Runtime use this VM generated property list directly rather than relying on Runtime? Issue 2: Calling clone() on an array in String.getCharArray() causes a linking error when the method is compiled. As an aside, I'm at least a little interested in knowing why (char []).clone() is thought to be faster than System.arraycopy(). Both arraycopy and clone should be native methods, and both can be implemented pretty much as a memcpy(). However, arraycopy has to do bounds and type checking (to make sure you aren't doing something stupid like arraycopy(int[], -1, float[], 0, 1)), where clone doesn't. But I think that this hack is appropriate if it will help ORP, so I will commit it shortly. -- 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: minimal hack to classpath for ORP 1.0.9
Fred Gray wrote: It's a straightforward bootstrapping problem, and it's apparently already been solved once in the past. See the javadoc for Runtime.setSecurityManager(): This was moved to Runtime so that Runtime would no longer trigger System's class initializer. Runtime does native library loading, and the System class initializer requires native libraries to have been loaded. The world starts out by initializing java.lang.Object. Its static initializer does a System.loadLibrary(), which causes System to be initialized. The static initializer for System again calls System.loadLibrary(), which in turn calls Runtime.load(), causing Runtime to be initialized. The static initializer for Runtime calls System.getProperty(), but the properties table hasn't been constructed yet, so properties.getProperty(key) tries to follow a null pointer. Therefore the world ends in a giant kaboom. :-) I did some shuffling and analysis, and I think the latest version in Classpath has a safe bootstrap sequence. Can you please test it for me? I did not trace the initialization of ClassLoader; I'm hoping that it does not cause problems before the native libraries are loaded, but it appears to me that System.getProperty should now be working before the ClassLoader initialization begins. Quoting from the patch I made to Runtime.defaultProperties: ... * No matter what class you start initialization with, it defers to the * superclass, therefore Object.clinit will be the first Java code * executed. From there, the bootstrap sequence, up to the point that * native libraries are loaded (as of March 24, when I traced this * manually) is as follows: * * Object.clinit uses a String literal, possibly triggering initialization * String.clinit calls WeakHashMap.init, triggering initialization * AbstractMap, WeakHashMap, WeakHashMap$1 have no dependencies * String.clinit calls CaseInsensitiveComparator.init, triggering * initialization * CaseInsensitiveComparator has no dependencies * Object.clinit calls System.loadLibrary, triggering initialization * System.clinit calls System.loadLibrary * System.loadLibrary calls Runtime.getRuntime, triggering initialization * Runtime.clinit calls Properties.init, triggering initialization *Dictionary, Hashtable, and Properties have no dependencies * Runtime.clinit calls insertSystemProperties; the VM must make sure * that there are not any harmful dependencies * Runtime.clinit calls Runtime.init *Runtime.init calls StringTokenizer.init, triggering initialization * StringTokenizer has no dependencies * System.loadLibrary calls Runtime.loadLibrary * Runtime.loadLibrary should be able to load the library, although it * will probably set off another string of initializations from * ClassLoader first */ 2002-03-25 Eric Blake [EMAIL PROTECTED] * vm/reference/java/lang/Runtime.java (defaultProperties): New field, to work around bootstrap issue. (securityManager): Make package visible. (Runtime): Remove bootstrap dependencies from constructor. * vm/reference/java/lang/Thread.java: Use securityManager field directly. * vm/reference/java/lang/VMSystem.java (insertSystemProperties): Move to Runtime, for bootstrap issue. * java/lang/Object.java: Document bootstrap importance. * java/lang/String.java: Ditto. * java/lang/ThreadGroup.java: Use securityManager field directly. * java/lang/System.java (defaultProperties): Remove, to work around bootstrap issue. * java/util/Dictionary.java: Document bootstrap importance. * java/util/Hashtable.java: Ditto. * java/util/Propeties.java: Ditto. * java/util/StringTokenizer.java: Ditto. * java/util/WeakHashMap.java: Ditto. -- 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: Problems with Character
I think the latest version of both files in Classpath should work.
Could it possibly be a VM error in adding two chars, and casting the
result back to a char? The data is encoded as signed offsets from the
current character, but stored as unsigned chars in the String constants;
so if your VM does the math wrong, you may be getting a weird index.
Another possibility - is your VM correctly handling reading in the UTF
string from the constant pool and converting it to char[]?
Can you do some more detective work? What do you get for
Character.readChar('a') and Character.readChar('A')? If I'm reading
CharData correctly, readChar('a') should be 0x1b02, so that you then
index UPPER[54] == '\uffe0' (in other words, 'a' + -30 = 'A').
readChar('A') should be 0xd01, so that you index LOWER[26] == ' ' (or
'A' + 32 = 'a').
Patrik Reali wrote:
Hi!
I'm experiencing some problems with java.lang.Character.
The methods toUpperCase and toLowerCase return
wrong results (most of the calls leave the values unchanged,
a few return strange values). I went through the code,
but there's not much they're just taking the result from
some tables.
I'm currently using the latest version of Character and CharData.
Can anybody confirm (or dismiss) the problem?
Thanks,
Patrik
--
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
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: 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
FYI: javax.accessibility
I was working last weekend on updating java.applet, and in the process, decided that it would be worth my while to implement javax.accessibility first. As has already been commented, hacking anything related to AWT is sure interrelated! I checked in this package, my changes to applet will follow shortly. 2002-03-18 Eric Blake [EMAIL PROTECTED] * javax/Makefile.am (SUBDIRS): Visit accessibility subdir. * javax/accessibility/Makefile.am: New file. * javax/accessibility/.cvsignore: New file. * javax/accessibility/Accessible.java: Update to 1.4. * javax/accessibility/AccessibleAction.java: Update to 1.4. * javax/accessibility/AccessibleBundle.java: Implement. * javax/accessibility/AccessibleComponent.java: Update to 1.4. * javax/accessibility/AccessibleContext.java: Implement. * javax/accessibility/AccessibleEditableText.java: New file. * javax/accessibility/AccessibleExtendedComponent.java: New file. * javax/accessibility/AccessibleExtendedTable.java: New file. * javax/accessibility/AccessibleHyperlink.java: Implement. * javax/accessibility/AccessibleHypertext.java: Update to 1.4. * javax/accessibility/AccessibleIcon.java: New file. * javax/accessibility/AccessibleKeyBinding.java: New file. * javax/accessibility/AccessibleRelation.java: New file. * javax/accessibility/AccessibleRelationSet.java: New file. * javax/accessibility/AccessibleResourceBundle.java: Implement. * javax/accessibility/AccessibleRole.java: Implement. * javax/accessibility/AccessibleSelection.java: Update to 1.4. * javax/accessibility/AccessibleState.java: Implement. * javax/accessibility/AccessibleStateSet.java: Implement. * javax/accessibility/AccessibleTable.java: New file. * javax/accessibility/AccessibleTableModelChange.java: New file. * javax/accessibility/AccessibleText.java: Update to 1.4. * javax/accessibility/AccessibleValue.java: Update to 1.4. -- 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: FYI: javax.accessibility
Oops. Thanks for the catch. I just committed that too. Brian Jones wrote: Are you updating lib/standard.omit and configure.in to build this package? -- 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: Please keep Classpath in a working state (Was: cvs commits andjava.util.regex)
Mark Wielaard wrote: Please no. Classpath is now at a point that it can be compiled with only free tools. Please keep it that way. I think the String changes should not have been checked in. No String changes that depend on java.util.regex were checked in. My conversation started because I added the dependency in my local tree, and EXPECTED a failure, knowing that java.util.regex was non-existant, just to see what I would have to add. But I am not planning on committing anything which will break the build. For classes that are really standalone and that you want to have in the CVS repository you can add them to the lib/standard.omit file so they don't interfere with the build (although I would like to keep that file as small as possible, ideally it would be empty). If that is really not a option then you should either work on a branch or check in stub classes. If I check in anything, I will either leave the implementation in String.java as throw new InternalError(unimplemented); or else add stub classes in java.util.regex which do the same. Actually, now that I think about it, putting the error in a stub class is better, because then we won't have to go back and change String. Please, please, please, always keep the tree compiling and working with the VM-interface we currently have. Sometimes you have to break it to make progress, but in that case please warn everybody by posting your patch to the mailinglist first before you check in and explain what people should do to keep on working with their current setup. I agree with this (and if I've been guilty of breaking things in the past, I'm sorry). Maybe we could define a minimum setup that is easy for everybody to get working? I would propose using jikes (1.15+) 1.15b, actually, available from Jikes CVS - the jikes 1.15 release has problems. and orp (1.0.9+) as the minimum setup that always needs to work for compiling/running Hello World with Classpath. That way someone can always fall back to Is Classpath/Jikes/Orp available on all platforms that the Classpath hackers currently use? No, I'm on Cygwin, and have yet to compile a successful free VM (or for that matter gcj). However, I haven't really sat down and tried tweaking ORP, yet, so maybe I can get it to work if I put some effort into it. Orp might be a bit x86 specific, but no other free VM is currently so easy to use with Classpath out of the box. Does the Classpath build work on a MSWindows/CygWin (sp?) system? The build works out of the box, but only builds the .class files (no native support). At least, I haven't gotten native support to work. -- 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
StringBuffer question
How strictly do we want to match Sun on StringBuffer? In the 1.4 Javadoc, many of the methods specify only @throws IndexOutOfBoundsException, which can be done as a side-effect of array operations. Yet the JDK implementation seems to throw StringIndexOutOfBoundsException (a subclass), which requires explicit bounds checking. The current Classpath implementation is a mix of both approaches, depending on which method you look at. It would be nice if it were consistent. Should we let the VM generate the more general exception implicitly, skipping explicit checks where possible; or should I make sure that Classpath throws the more specific StringIndexOutOfBoundsException any time Sun does? -- 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: StringBuffer question
Bryce McKinlay wrote: However, in the JCL, setLength() and other StringBuffer methods are explicitly defined to throw the StringIndexOutOfBoundsException. Thanks for the clarification. I will document the methods in question as: * @throws IndexOutOfBoundsException description... *(while unspecified, this is a StringIndexOutOfBoundsException) Is there a way to access the JCL online? It's not listed on the Hacking page: http://www.gnu.org/software/classpath/doc/hacking.html Another question on the original topic. Do we try to match which exception is thrown when multiple problems occur? For example, new String(byte[], int, int, String) can throw a NullPointerException from a null encoding or byte[], IndexOutOfBoundsException from bad indices, or UnsupportedEncodingException from an unknown encoding. My experiments show that Sun checks for a null encoding, then for negative indices, then a null byte[], then indices too large, and finally for an unknown encoding. However, Classpath and libjava have different orders for checking, so the three implementations currently have different behavior for this snippet: new String(new byte[1], -1, 0, null); new String(null, -1, 0, foobar); Sun: NullPointer, StringIndexOutOfBounds Classpath: StringIndexOutOfBounds, StringIndexOutOfBounds libjava: ArrayIndexOutOfBounds, NullPointer My opinion is that it doesn't matter which exception is thrown, so long as one of them is (mainly because checking for a null encoding before checking bounds, but for an unknown encoding after, is less efficient then doing both encoding checks at once). That ArrayIndexOutOfBounds in libjava should probably be switched to StringIndexOutOfBounds, though. If it isn't obvious by now, I'm trying to merge String and StringBuffer between Classpath and libjava, insofar as possible. This includes adding better data sharing and substring support to Classpath. Of course, I'm tackling the all-Java version of Classpath before trying to modify gcj with its native support. -- 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
style question
I'm looking at fixing a bug in Long.decode(), and came across a style
question.
Which is prefered, performing array bound checks throughout a method, or
enclosing the algorithm in a try-catch block which converts an
IndexOutOfBoundsException into a NumberFormatException? Using a
try-catch block emits less bytecode, and if decode() is used on valid
strings as the common case, it reduces overhead to not check the
bounds. In the exceptional case, my proposal must create and discard an
IndexOutOfBoundsException, while bounds checking avoids that, but the
method fails in either case.
Here's a diff, (not quite to GNU coding standards, to preserve
indentation), that illustrates my question:
Index: java/lang/Long.java
===
RCS file: /cvsroot/classpath/classpath/java/lang/Long.java,v
retrieving revision 1.14
diff -u -r1.14 Long.java
--- java/lang/Long.java 25 Feb 2002 01:36:03 - 1.14
+++ java/lang/Long.java 25 Feb 2002 06:38:54 -
@@ -355,27 +355,25 @@
[...]
public static Long decode(String str)
{
+try
+ {
boolean isNeg = false;
int index = 0;
int radix = 10;
-final int len;
-
-if ((len = str.length()) == 0)
- throw new NumberFormatException();
+final int len = str.length();
// Negative numbers are always radix 10.
if (str.charAt(0) == '-')
@@ -405,10 +403,13 @@
radix = 8;
}
-if (index = len)
- throw new NumberFormatException();
-
+// Change parseLong to throw IndexOutOfBoundsException...
return new Long(parseLong(str, index, len, isNeg, radix));
+ }
+catch (IndexOutOfBoundsException e)
+ {
+throw new NumberFormatException();
+ }
}
/**
--
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: [Classpath] style question
C. Scott Ananian wrote:
For what it's worth: often adding explicit bounds checks will enable the
compiler to create faster code (by hoisting these checks, and others which
are implicit in the java semantics, out of the loop). I'm not sure
which/any of the existing Java compilers are smart enough to do this, but
they all will be, eventually.
Notice that in my case, though, there is no loop, and the bounds check
is still in software. I'm simply proposing to remove two independent
checks of the length in decode(), (before parsing, and after parsing
0x), because they duplicated the bounds check already explicit in
String.charAt().
I am not proposing to use VM hardware array bounds checking to reduce
the amount of bytecode. And I do agree that this:
try
{
int i = 0;
while (i++)
// process array[i]
}
catch (IndexOutOfBoundsException e)
{
// ignore - we used a try-catch as flow control
}
is much worse than this:
for (int i = 0; i array.length; i++)
// process array[i]
I can't imagine any
case where the try-catch would be faster for array-bounds (okay, there are
some w/in *imagination*, but...). In most cases, you'd be doing the same
array-bounds tests in hardware as in the explicit case, but then you'd
have to create the exception object and throw it, only to be caught,
rebuilt as another exception object, and rethrown.
That's what I was asking - if anyone else thinks that my proposed change
in decode() is one of those situations.
--
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: generation of gnu/java/locale/*.uni
Brian Jones wrote: I'll run what you've checked in through Mauve here and see what happens. Do you have time to evaluate the Character implementation Artur pointed to? I'm mostly concerned with correctness, I think the one he pointed to improved efficiency, if not speed. I'd do this myself but that would involve time learning how Character/Unicode work. I just committed an update based on Artur's code. And since the database is no longer a binary file, you should have no problems using it straight out of CVS for another run through Mauve. -- 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: generation of gnu/java/locale/*.uni
Artur Biesiadowski wrote: I just committed an update based on Artur's code. And since the database is no longer a binary file, you should have no problems using it straight out of CVS for another run through Mauve. Please note that this is not my code - it was written by Jochen Hoenicke. Sorry. I'll correct those references in CVS to give credit where it is due. I think that you might also find it useful: http://www.mail-archive.com/classpath@gnu.org/msg02024.html Hmm, more fun reading for me to do... I don't know how much the implementation differs now and unfortunately I cannot make a check right now, but I suppose that playing with block sizes should not be hard. The unicode-muncher.pl script checks all block sizes from 3-8 in selecting the best size. The best block size for Unicode 3.0.0 turns out to be 5; for Unicode 3.2.0 it is 4. -- 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: generation of gnu/java/locale/*.uni
Brian Jones wrote: As I recall Unicode now requires more bits than a Java 'char' allows. I don't know that helps at all? I don't really know what Sun's solution is. It looks like we did update to unicode data 3.0, but I know our implementation fails many Mauve tests related to Character. Unicode 3.1 introduced several code points in the surrogate space. And the upcoming 3.2 adds even more. These characters require two 16-bit fields to represent them (the first in \ud800 - \udb7f, the second in \udc00 - \udfff). And Java does ignore these - the 4-byte abbreviation sequences of UTF-8 are illegal in class files (you have to use a 6-byte sequence instead), and Java identifiers may not include surrogate characters. Sun would need to add more methods to the API to use them, because the point of surrogates is that two characters together have semantic meaning, while one alone is an error. For example, it is impossible to tell if \ud820 in isolation is part of a letter, number, or punctuation. So for now, Sun's solution is to stall. I did verify today that JDK 1.4 is still on Unicode 3.0.0. The implementation of Character that I just checked in to Classpath is identical in behavior to Sun's (fortunately, testing every method on all 64k chars is not terribly time-consuming). However, I could not run it through Mauve; as I still have been unable to compile a free VM on cygwin, and Sun's VM doesn't like me replacing core classes like Character. But if Character fails any tests in Mauve now, then I would suspect that Mauve has the bugs. -- 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: generation of gnu/java/locale/*.uni
Artur Biesiadowski wrote: I know that I tell it every time Character issue comes - but aren't we going to use alternative Character posted here some time ago (2 years?). It had a LOT better performance (no object creation during check and check itself quite faster) , encoded all data in Strings (so there was no need to play tricks with loaders and dependency on gnu/something class). Only problem I had was, I was unable to compile it with old jikes due to some funny unicode. Hmm, I did find it kind of fishy that the current implementation was creating so many throwaway objects. However, while the changes I made further separate the two implementations, I'll look at incorporating the benefits I see in the alternative: 1. loading from Strings instead of Java File IO is nicer, making the static initialization slightly faster, but more importantly less dependent on other classes (note that I would still be using file IO, as the data must be in a separate file to be easily upgradeable; but implicitly through the VM ClassLoader and not explicitly) 2. caching all attributes in arrays requires more runtime memory, but if the arrays are compressed enough, this is a hands-down win over frequent object creation 3. character class checks, such as isLetter(), are more efficient, using a shift and single comparison to a constant instead of a series of conditional comparisons Even if it might be out-of-date and non-compilable today, it might be nice to maybe work with it ? Or otherwise tell me that it WON'T be used ever, so I can stop touching this subject every time Character is on board :) Thanks for bringing up the issue. I hope to make some of those improvements in the near future. -- 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
generation of gnu/java/locale/*.uni
I'm looking at updating java.lang.Character to JDK 1.4 specs (and Unicode 3.0). Does anyone know what programs generated gnu/java/locale/*.uni? I ask because I need to add more information to each character to cover the new DIRECTIONALITY category designations. If the generation program is not currently in the distribution, I'll write up a quick Java program and add it to Classpath. -- 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: generation of gnu/java/locale/*.uni
Brian Jones wrote: doc/unicode/unicode-muncher.pl Thanks. Should I try to update Classpath to Unicode 3.2.0 (currently in beta, expected to be final next month), 3.1.1 (the current stable state), or 3.0 (the version mentioned in the 1.4 javadoc of java.lang.Character)? JLS 3.1 states The Java platform will track the Unicode specification as it evolves. The precise version of Unicode used by a given release is specified in the documentation of the class Character. I think the choice is between documenting that we are using the latest definition 3.2.0, or else sticking with 3.0.0 to match the behavior of Sun, but want to know what others think. -- 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.lang.StrictMath
Hmm, maybe you are right. On second reading, Sun specifies the following in StrictMath: To help ensure portability of Java programs, the definitions of many of the numeric functions in this package require that they produce the same results as certain published algorithms These algorithms, which are written in the C programming language, are then to be understood as executed with all floating-point operations following the rules of Java floating-point arithmetic. Then, in Math, they state: By default many of the Math methods simply call the equivalent method in StrictMath for their implementation. Code generators are encouraged to use platform-specific native libraries or microprocessor instructions, where available, to provide higher-performance implementations of Math methods. Such higher-performance implementations still must conform to the specification for Math. I had interpreted it to mean that Math may be native, but StrictMath should be pure. Besides, the less native code there is, the less maintainance problems and more portable Classpath becomes. But maybe it is worth it after all for StrictMath to have native implementations, provided such implementations match the ones I just submitted in the Java language. Is the overhead of calling a native method offset by the speed of doing this number crunching without going through bytecode? Per Bothner wrote: Eric Blake wrote: StrictMath is required to be implemented in pure Java, not in native code; Where is this peculiar requirement stated? No proper specification would make any such requirement (not to suggest that Java has a proper specification) - most standards have an as-if rule: The implementation must behave *as if* it used the specified algorithm or code, but as long as no valid program can tell the difference, the implementation is free to use some other algorithm. -- --Per Bothner [EMAIL PROTECTED] http://www.bothner.com/per/ -- 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: Compiling with jikes 1.13
Mark Wielaard wrote:
The rest of the verify output follows, but I have not analysed it yet.
Cheers,
Mark
Name: verify-jikes.libgcj
verify-jikes.libgcjType: Plain Text (text/plain)
Encoding: quoted-printable
It looks like all the errors listed in this file were incompatible type
on stack, in other words, side effects of your ClassLoader hack.
Name: verify-jikes.gcj
verify-jikes.gcjType: Plain Text (text/plain)
Encoding: quoted-printable
I have addressed all the errors listed in this file. With the attached
patch and the latest CVS version of jikes (as of 9:15 am UTC Feb 9),
this should be completely resolved. If you agree with me, then I will
tag the current version of jikes CVS as stable, and bump the version to
1.15b. Shall I go ahead and commit the patch?
--
This signature intentionally left boring.
Eric Blake [EMAIL PROTECTED]
BYU student, free software programmer
2002-02-09 Eric Blake [EMAIL PROTECTED]
* java/net/DatagramSocketImpl.java (setOption, getOption): Work
around gcj bug of wrong emitted qualifier for inherited method.
* java/net/SocketImpl.java (setOption, getOption): Ditto.
* java/util/WeakHashMap.java (WeakEntrySet): Work around jikes
1.15 bug of private constructors in inner classes.
* java/rmi/server/RMIClassLoader.java (MyClassLoader): Ditto.
* gnu/java/rmi/server/UnicastRemoteCall.java
(DummyObjectOutputStream, DummyObjectInputStream): Ditto.
Index: java/net/DatagramSocketImpl.java
===
RCS file: /cvsroot/classpath/classpath/java/net/DatagramSocketImpl.java,v
retrieving revision 1.11
diff -u -r1.11 DatagramSocketImpl.java
--- java/net/DatagramSocketImpl.java22 Jan 2002 22:27:00 - 1.11
+++ java/net/DatagramSocketImpl.java9 Feb 2002 09:17:31 -
@@ -1,5 +1,5 @@
/* DatagramSocketImpl.java -- Abstract class for UDP socket implementations
- Copyright (C) 1998, 1999 2000, 2001 Free Software Foundation, Inc.
+ Copyright (C) 1998, 1999 2000, 2001, 2002 Free Software Foundation, Inc.
This file is part of GNU Classpath.
@@ -203,4 +203,34 @@
{
return localPort;
}
+
+ /**
+ * Sets the specified option on a socket to the passed in object. For
+ * options that take an integer argument, the passed in object is an
+ * codeInteger/code. For options that are set to on or off, the
+ * value passed will be a codeBoolean/code. The codeoption_id/code
+ * parameter is one of the defined constants in the superinterface.
+ *
+ * @param option_id The identifier of the option
+ * @param val The value to set the option to
+ *
+ * @exception SocketException If an error occurs
+ */
+ public abstract void setOption(int option_id, Object val)
+throws SocketException;
+
+ /**
+ * Returns the current setting of the specified option. The
+ * codeObject/code returned will be an codeInteger/code for options
+ * that have integer values. For options that are set to on or off, a
+ * codeBoolean/code will be returned. The codeoption_id/code
+ * is one of the defined constants in the superinterface.
+ *
+ * @param option_id The option identifier
+ *
+ * @return The current value of the option
+ *
+ * @exception SocketException If an error occurs
+ */
+ public abstract Object getOption(int option_id) throws SocketException;
}
Index: java/net/SocketImpl.java
===
RCS file: /cvsroot/classpath/classpath/java/net/SocketImpl.java,v
retrieving revision 1.7
diff -u -r1.7 SocketImpl.java
--- java/net/SocketImpl.java22 Jan 2002 22:27:00 - 1.7
+++ java/net/SocketImpl.java9 Feb 2002 09:17:31 -
@@ -1,5 +1,5 @@
/* SocketImpl.java -- Abstract socket implementation class
- Copyright (C) 1998, 1999, 2000, 2001 Free Software Foundation, Inc.
+ Copyright (C) 1998, 1999, 2000, 2001, 2002 Free Software Foundation, Inc.
This file is part of GNU Classpath.
@@ -234,4 +234,34 @@
return [addr= + address.toString() + ,port= + Integer.toString(port) +
,localport= + Integer.toString(localport) + ];
}
+
+ /**
+ * Sets the specified option on a socket to the passed in object. For
+ * options that take an integer argument, the passed in object is an
+ * codeInteger/code. For options that are set to on or off, the
+ * value passed will be a codeBoolean/code. The codeoption_id/code
+ * parameter is one of the defined constants in the superinterface.
+ *
+ * @param option_id The identifier of the option
+ * @param val The value to set the option to
+ *
+ * @exception SocketException If an error occurs
+ */
+ public abstract void setOption(int option_id, Object val
Re: build question
Tom Tromey wrote:
Eric == Eric Blake [EMAIL PROTECTED] writes:
Eric automake: native/jni/java-lang/Makefile.am: `\' is not a standard
Eric libtool library name
This is curious. This error shouldn't happen. Apparently what is
happening here is that automake thinks that the `\' continuation
character in the definition of pkglib_LTLIBRARIES is supposed to be
the name of a library.
I can't reproduce this problem here. Since you are using Cygwin,
which most of us aren't, perhaps the problem is somehow related to
that. For instance, it could be a line termination problem.
Could you investigate this for me? I'd like to fix automake.
It has to be line terminator translation somewhere, because this hack to
automake makes everything work for me. I'm sure you could find a more
elegant way to fix the problem, and that the real fix should be upstream
in the sources rather than in the final executable; however, I'm not
familiar enough with the automake sources and/or perl to suggest a
better fix.
$ diff -u automake.bak automake
--- automake.bakSat Feb 9 10:35:42 2002
+++ automakeSat Feb 9 11:31:48 2002
@@ -6455,6 +6455,7 @@
while ($_ = $am_file-getline)
{
+s/\r\n/\n/g;
if (/$IGNORE_PATTERN/o)
{
# Merely delete comments beginning with two hashes.
@@ -6498,6 +6499,7 @@
# FIXME: shouldn't use $_ in this loop; it is too big.
while ($_)
{
+s/\r\n/\n/g;
$_ .= \n
unless substr ($_, -1, 1) eq \n;
--
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: Release [Was: Orp does zip files]
Brian Jones wrote: Anything else left to do before releasing? I'm going to tag the source tree when it is definite. You mentioned updating the INSTALL file for jikes. I'm good to go. Jikes 1-15b is now up and running on its CVS server, and Classpath's INSTALL and HACKING have been updated accordingly. -- 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: Compiling with jikes 1.13
Eric Blake wrote: Mark Wielaard wrote: And this time it actually had a valid VerifyError! This new jikes is a bit to clever about String concatenations. I'll fix that today, and repost here when it is up. I committed that patch to Jikes' CVS earlier today, fixing the VerifyErrors with string concatenation. I'm trying to get one more patch through the test suite and in CVS by tomorrow morning, then I'll take a look at the other verify errors you reported. My gut feeling is that we may have to make some private constructors in inner classes more accessible as a temporary workaround, until jikes 1.16 is released. -- 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: make dist fixes
Actually, the bug was in jikes 1.15, and is still in the jit. JLS 13
requires that compilers emit method references relative to the class
that qualifies the method invocation, even if that class only inherits
the method. It is then up to the VM to correctly track inheritance
issues when resolving method calls. Sun's javac 1.3 also had this bug,
JDK 1.4 compiles the way jikes 1.15a does (ie. Encoder8859_1.loadTable).
It makes a difference in this example:
in A.java:
class A
{
static void m() { System.out.print(a); }
}
in B.java:
class B extends A {}
in C.java:
class C
{
public static void main(String[] args)
{
B.m();
}
}
Now, recompile B.java:
class B extends A
{
static void m() { System.out.print(b); }
}
The result of executing the (unchanged) C.class should now be b, not
a.
This is also the reason that Sun's javap program will often list null as
the method or field name for classes compiled with javac 1.4, because
they have not yet fixed javap to take inheritance into account.
Mark Wielaard wrote:
The problem seems to come from the fact that jikes 1.15 (and gcj)
generate things like:
1804: invokestatic #34=Method
gnu.java.io.encode.EncoderEightBitLookup.loadTable ()void
But jikes 1.15a (from CVS) generates:
1804: invokestatic #33=Method
gnu.java.io.encode.Encoder8859_1.loadTable ()void
Since loadTable() is a static method in (the superclass)
EncoderEightBitLookup not in (the subclass) Encoder8859_1 it seems that
jikes 1.15a generates wrong code in this case.
Cheers,
Mark
--
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: make dist fixes
Keep in mind that a workaround for this is to explicitly qualify the
method with the desired class (ie. the one where the method is actually
defined).
In other words, instead of
Encoder8859_1.loadTable()
in the source code, use
EncoderEightBitLookup.loadTable()
The only problem I see with this approach is if EncoderEightBitLookup is
not accessible when Encoder8859_1 is. Then an alternative workaround
would be to modify Encoder8859_1 by adding this method:
public static void loadTable() { super.loadTable(); }
I'm not familiar with the ORP code, but these workarounds shouldn't be
too hard.
Do you want me to file a PR for the gcc bug? I've yet to get a working
compile of gcj on my cygwin box, so I'm not sure how well I would do on
bug reporting.
Mark Wielaard wrote:
That (and the example) seems to make sense. But it also means that we
don't have one bug in jikes, but two bugs, one in ORP and one in gcj
byte code generation. Sigh.
That basicly means we don't recommend jikes 1.15a for this Classpath
release and ORP 1.0.9, or we wait for a new ORP release with a fix.
H. I would opt for releasing now and adding a note about this
problem (with newer versions of jikes and ORP) to the README/INSTALL
file. Or we could try to produce a patch for ORP, but I am not sure that
is very easy.
Cheers,
Mark
--
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: Compiling with jikes 1.13
Mark Wielaard wrote: And this time it actually had a valid VerifyError! This new jikes is a bit to clever about String concatenations. I'll fix that today, and repost here when it is up. -- 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
build question
I'm trying to do a completely fresh build of classpath with the latest CVS version of Jikes, to see what needs to be fixed in Jikes (or what workarounds need to be patched into classpath) by Friday. But during the autoreconf stage, I was getting: $ automake native/jni/java-lang/Makefile automake: native/jni/java-lang/Makefile.am: `\' is not a standard libtool library name native/jni/java-lang/Makefile.am:15: invalid unused variable name: `libjavalang_la_LIBADD' native/jni/java-lang/Makefile.am:6: invalid unused variable name: `libjavalang_la_SOURCES' native/jni/java-lang/Makefile.am:18: invalid unused variable name: `libjavalangreflect_la_LDFLAGS' native/jni/java-lang/Makefile.am:17: invalid unused variable name: `libjavalang_la_LDFLAGS' native/jni/java-lang/Makefile.am:13: invalid unused variable name: `libjavalangreflect_la_SOURCES' $ Is it ok to commit this patch? Then I can actually do a build to report on the status of jikes/classpath. 2002-02-06 Eric Blake [EMAIL PROTECTED] * native/jni/java-lang/Makefile.am: Clean up automake problems caused by trailing '\'. Index: native/jni/java-lang/Makefile.am === RCS file: /cvsroot/classpath/classpath/native/jni/java-lang/Makefile.am,v retrieving revision 1.1 diff -u -r1.1 Makefile.am --- native/jni/java-lang/Makefile.am5 Nov 2001 03:03:27 - 1.1 +++ native/jni/java-lang/Makefile.am6 Feb 2002 20:24:38 - @@ -1,10 +1,7 @@ SUBDIRS = -pkglib_LTLIBRARIES = \ - libjavalang.la \ - libjavalangreflect.la +pkglib_LTLIBRARIES = libjavalang.la libjavalangreflect.la -libjavalang_la_SOURCES := \ - java_lang_System.c \ +libjavalang_la_SOURCES = java_lang_System.c \ java_lang_Object.c \ java_lang_Float.c \ java_lang_Double.c \ -- 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: build question
Mark Wielaard wrote: Hi, What version of automake are you using? You will need automake 1.5 to build Classpath from CVS (see HACKING). automake 1.5, as bundled in cygwin under their automake-devel branch. I'm not sure if the cygwin developers have done anything on top of the stock automake 1.5 distribution. I modelled my patch after java-io/Makefile.am; the only Makefile.am giving me problems was the one in java-lang. Cheers, Mark -- 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: Compiling with jikes 1.13
Mark Wielaard wrote: I also tried compiling jikes from CVS but I am unable to compile Classpath with it. Simple test programs work though. Needs some debugging. Eric, is jikes from CVS 'stable'? I just committed a patch, after spending all afternoon hacking, that ensures that the CVS version of jikes will compile Classpath without failure. I have not tried your verify script to see if all the class files are valid, but it is in better shape than yesterday when jikes was dumping core. Actually, I'd feel better if you ran your verify script on the output of the current CVS version of jikes, to check my work. If it succeeds with no compile or verify errors, then I will tag the current state of jikes CVS as stable, and update the Classpath documentation to point to that version. -- 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: Compiling with jikes 1.13
I'm one of the jikes developers. I know that Jikes 1.15 has some problems compiling inner classes with private constructors, (jikes compiles with exit status 0, but execution of the resulting .class file causes a VerifyError), and there are a few of those in Classpath. I'm not sure if the Debian release applied any patches to the stock 1.15 install. But the CVS version of jikes is looking better. Jikes 1.16 is being held up by a few more bugs; I have some partial patches in my source tree, but have not had the time to get them all in (school has hit me pretty heavily this semester). I plan to spend more time on jikes during the Olympics, when I have time off school. My plans for 1.16 involve flawless compilation of inner classes, and I'm getting closer. I haven't tried compiling Classpath with the latest CVS, so I'm not sure if it solves all the VerifyErrors of 1.15. If you would like, I can see about adding a tag to CVS on a stable version of jikes (possibly reverting one or two unstable patches), to coordinate with a release of Classpath, then provide instructions for obtaining this interim version of jikes. Mark Wielaard wrote: Hi, Chris Gray wrote: With Wonka we've had problems with every version after 1.12.1 (!). Problems includes: dumps core on valid input, outputs illegal bytecode Stuart Ballard wrote: FWIW, I had to put jikes in debian/unstable on hold at 1.14-0.4 because it started doing nasty things to my own application. But I haven't tried compiling classpath with it, so it may work for that purpose. Etienne M. Gagnon wrote: Hmmm... I experienced problems compiling Classpath with jikes 1.14. These problem went away when I installed jikes 1.15 on my Debian/sid system... John Leuner wrote: There were issues (don't remember exactly what), but I've been using the jikes 1.15 in debian/unstable and it seems to work fine. (I have compiled all of classpath with it) OK. So it seems that we can recommend jikes 1.15 for compiling Classpath but it may have some problems for other applications. I will put that in the HACKING and INSTALL notices. Have people with jikes problems actaully reported them to the jikes developers? We can try to recompile Wonka with 1.15 to see what happens. Stuart, what program were you using which forced you to downgrade to 1.14? Cheers, Mark -- 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: Problems with float Math.min(float,float) etc
Tom Tromey wrote: Eric == Eric Blake [EMAIL PROTECTED] writes: Eric * java/lang/Double.java (equals, compare): Fix 0.0 vs. -0.0 math. I don't think anything was wrong with the old logic in equals(). Yes, you are right that there were no logic errors in the old version of equals(). But the version I committed avoids 2 calls to a native method, and accesses the field value directly rather than calling doubleValue(). -- 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: Problems with float Math.min(float,float) etc
Peter Dickerson wrote:
Math.min(float,float) seems to have incorrect behaviour for negative zero.
You must have a stale file. I show CVS to have this already (which
avoids a method call, and does not have the bug you mentioned):
public static float min (float a, float b)
{
// this check for NaN, from JLS 15.21.1, saves a method call
if (a != a)
return a;
// no need to check if b is NaN; will work correctly
// recall that -0.0 == 0.0, but [+-]0.0 - [+-]0.0 behaves special
if (a == 0 b == 0)
return -(-a - b);
return (a b) ? a : b;
}
However, I did notice some similar problems in Double and Float, and am
checking in the following patch.
--
This signature intentionally left boring.
Eric Blake [EMAIL PROTECTED]
BYU student, free software programmer
2002-01-15 Eric Blake [EMAIL PROTECTED]
* java/lang/Double.java (equals, compare): Fix 0.0 vs. -0.0 math.
* java/lang/Float.java (equals, compare): Ditto.
Index: java/lang/Double.java
===
RCS file: /cvsroot/classpath/classpath/java/lang/Double.java,v
retrieving revision 1.26
diff -u -r1.26 Double.java
--- java/lang/Double.java 15 Nov 2001 02:23:35 - 1.26
+++ java/lang/Double.java 15 Jan 2002 16:34:04 -
@@ -1,5 +1,5 @@
/* Double.java -- object wrapper for double primitive
- Copyright (C) 1998, 1999, 2000, 2001 Free Software Foundation, Inc.
+ Copyright (C) 1998, 1999, 2000, 2001, 2002 Free Software Foundation, Inc.
This file is part of GNU Classpath.
@@ -44,7 +44,8 @@
*
* @author Paul Fisher
* @author Andrew Haley [EMAIL PROTECTED]
- * @since JDK 1.0
+ * @author Eric Blake [EMAIL PROTECTED]
+ * @since 1.0
*/
public final class Double extends Number implements Comparable
{
@@ -163,9 +164,12 @@
if (!(obj instanceof Double))
return false;
-Double d = (Double) obj;
+double d = ((Double) obj).value;
-return doubleToLongBits (value) == doubleToLongBits (d.doubleValue ());
+// common case first, then check NaN and 0
+if (value == d)
+ return (value != 0) || (1 / value == 1 / d);
+return isNaN(value) isNaN(d);
}
/**
@@ -336,10 +340,9 @@
return isNaN (y) ? 0 : 1;
if (isNaN (y))
return -1;
-if (x == 0.0d y == -0.0d)
- return 1;
-if (x == -0.0d y == 0.0d)
- return -1;
+// recall that 0.0 == -0.0, so we convert to infinites and try again
+if (x == 0 y == 0)
+ return (int) (1 / x - 1 / y);
if (x == y)
return 0;
Index: java/lang/Float.java
===
RCS file: /cvsroot/classpath/classpath/java/lang/Float.java,v
retrieving revision 1.21
diff -u -r1.21 Float.java
--- java/lang/Float.java11 Nov 2001 16:07:09 - 1.21
+++ java/lang/Float.java15 Jan 2002 16:34:04 -
@@ -1,5 +1,5 @@
/* java.lang.Float
- Copyright (C) 1998, 1999, 2000, 2001 Free Software Foundation, Inc.
+ Copyright (C) 1998, 1999, 2000, 2001, 2002 Free Software Foundation, Inc.
This file is part of GNU Classpath.
@@ -44,7 +44,8 @@
*
* @author Paul Fisher
* @author Andrew Haley [EMAIL PROTECTED]
- * @since JDK 1.0
+ * @author Eric Blake [EMAIL PROTECTED]
+ * @since 1.0
*/
public final class Float extends Number implements Comparable
{
@@ -232,9 +233,12 @@
if (!(obj instanceof Float))
return false;
-Float f = (Float) obj;
+float f = ((Float) obj).value;
-return floatToIntBits (value) == floatToIntBits (f.floatValue ());
+// common case first, then check NaN and 0
+if (value == f)
+ return (value != 0) || (1 / value == 1 / f);
+return isNaN(value) isNaN(f);
}
/**
@@ -484,10 +488,9 @@
return isNaN (y) ? 0 : 1;
if (isNaN (y))
return -1;
-if (x == 0.0 y == -0.0)
- return 1;
-if (x == -0.0 y == 0.0)
- return -1;
+// recall that 0.0 == -0.0, so we convert to infinities and try again
+if (x == 0 y == 0)
+ return (int) (1 / x - 1 / y);
if (x == y)
return 0;
Re: Serialver [was Re: [PATCH]]
Brian Jones wrote:
The Jikes developer discussion list recently had a small thread about
this and at least according to my understanding they think the
specification is incomplete such that it cannot be implemented
correctly by a compiler to exactly match Sun's compiler. Therefore
when Classpath is compiled with Jikes it is incompatible with any Sun
VM. I wish Eric Blake could comment further to explain to us a bit
more if I've misrepresented in some way.
Brian
--
Brian Jones [EMAIL PROTECTED]
I'll do my best, although I cannot guarantee a satisfactory answer. As
I understand it, the serial version number of a class is based on some
hashing algorithm that uses the either the contents of the constant
pool, or perhaps just the method names, in the order they appear in the
.class file. But since jikes sometimes emits methods with different
names, or in a different order, than Sun, the hash algorithm will
generate a different result for classes generated by the different
compilers.
As an example, if you compile:
class Foo { void bar() {} }
javac and jikes will emit bar() and init() (the implicit constructor)
in opposite order from one another. Another example is accessor
methods:
class Outer {
private int i;
class Inner { int j = i; }
}
javac emits an accessor named access$000(), while jikes uses
access$0(). And even if jikes and javac emitted the same methods,
simply listing the methods in a different order in the .java file would
cause them to be emitted in a different order, again changing the UID.
Therefore, the safest course of action is to explicitly have a
serialVersionUID for all Serializeable classes, rather than relying on
the implicit UID generated by the undocumented hash behavior. Note that
the serialVersionUID field should be a private variable (Sun's serialver
neglects this fact, making it seem like package-private is acceptable),
so that it is not inherited by other subclasses in the same package.
However, I doubt that java.io.Serializable needs a serialVersionUID, as
it is an interface. You only serialize Objects, not interfaces, so it
makes no difference whether Serializable has a UID. Besides, as pointed
out earlier, the jikes-compiled Classpath version has the same UID from
Sun's serialver, simply because there ARE no methods or fields, so the
hashing function has no incompatibilities with Sun's version.
--
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.ResourceBundle bug?
Mark Wielaard wrote:
I disagree since we should not let normal classes give direct access to
the VM interface classes.
I looked at the code and I do not understand why you want to call the
VMClassLoader.defineClass() method. It seems to me that you want to call
the defineClass() method of the supplied loader.
The problem here is that the supplied ClassLoader parameter may be null,
if you intend for the proxy class to be created by the bootstrap
loader. For example, in javac you can create a proxy Runnable with null
as its ClassLoader:
Proxy.newProxyInstance(null, new Class[]{Runnable.class}, myHandler);
In order to create this class without a NullPointerException, you must
defer to the secure VM entry point.
I do admit that this is
not possible with the same trick as we could use in java.util with the
SecurityManager. But since java.util.reflect.Proxy is system code it has
enough permissions to get at the defineClass() Method and invoke it on
the supplied loader. Wouldn't something like the following work:
Class clazz = (Class) AccessController.doPrivileged
(
new PrivilegedAction()
{
Class[] types = {ClassLoader.class, String.class,
byte[].class, int.class, int.class,
/* ProtectionDomain.class */ };
Method m = loader.getDeclaredMethod(defineClass, types);
Object[] args = {loader, qualName, bytecode, new Integer(0),
new Integer(bytecode.length),
/* Object.class.getProtectionDomain() */ };
return m.invoke(loader, args);
};
}
Again not actually tested or compiled. (Mostly just copy/paste from the
current Proxy.java code.)
Cheers,
Mark
--
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: Why upgrading sucks
Once again, I meant to send my reply to the list originally... Eric Blake wrote: Brian Jones wrote: I had to share my pain so I hope someone else finds this funny. Tonight I updated to Red Hat 7.2 and afterwards applied the necessary updates as noted by Red Hat. Then I created RPMs of the newest libtool, automake, and autoconf and installed those. After twiddling with the various files like updating ltmain.sh and adding depcomp turns out that the Jikes I now have seg faults building our source... so I'm going to sleep. I'll install gcc 3.0.2 soon (in a standalone fashion away from my current gcc) and presumably won't have to deal with the Jikes problem. Hopefully Eric Blake can shed some light on this and offer a suggestion for what Jikes to use. Which version of jikes does RedHat 7.2 ship with? 1.15 has some known segfaults when compiling nested classes in a static context, which escaped through the release process. The patch that caused the problems has since been reverted from CVS, if you are willing to try bleeding-edge versions. Or, if you prefer a specific time, the ChangeLog shows that the regression was fixed on Oct 15; and I can verify that the Jikes CVS tree was stable and successfully compiled classpath on Oct 18. Otherwise, all I can say is stick to 1.14; although I haven't tried that version on classpath myself, it does not have the blatant problem with nested classes. The sad part is that I was release manager for 1.15 back in September, but was not compiling Classpath at the time, or that regression might not have slipped through! :pserver:[EMAIL PROTECTED]:/usr/cvs/jikes (password anoncvs, module jikes) I feel your pain (sorry that I'm partly to blame). Brian -- 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
Yet more java.util
Tonight I committed my final installment of java.util Collections API documentation. I also fixed various bugs I found in the Set and Map classes. Once again, feel free to point out bugs or inconsistencies that I should repair. Now I can start focusing on porting all my recent changes to libgcj. 2001-10-25 Eric Blake [EMAIL PROTECTED] * java/util/AbstractCollection.java (removeAllInternal), (retainAllInternal): Add hooks for use by ArrayList. * java/util/AbstractList.java: Minor code updates. Fix some scoping. * java/util/AbstractMap.java: ditto * java/util/ArrayList.java (readObject, writeObject): ditto (removeAllInternal, retainAllInternal): Optimize. * java/util/Arrays.java: ditto * java/util/Collections.java: ditto. Change order of parameters to equals(Object, Object) to match specs. * java/util/Dictionary.java: Improve javadoc. (Dictionary): Add explicit constructor. * java/util/HashMap.java: Improve javadoc. Rearrange methods to follow order in JDK. Cleanups related to recent code migration to AbstractMap. Fix some scoping. (entrySet): Cache the result. (modCount): Ensure that this is updated correctly. * java/util/HashSet.java: Improve javadoc. Fix some scoping. (init): Add hooks for LinkedHashSet. (map): Use instead of Boolean.TRUE in backing map. Use package-private API where possible for less overhead. (readObject, writeObject): Fix serialization. * java/util/Hashtable.java: Improve javadoc. Fix some scoping. (entrySet, keySet, values): Cache the result. (modCount): Ensure that this is updated correctly. (contains, remove): Fix NullPointer checking to match specs. (class Enumeration): Make more like HashIterator. * java/util/IdentityHashMap.java: Minor code updates. (modCount): Ensure that this is updated correctly. (readObject, writeObject): Fix serialization. * java/util/LinkedHashMap.java: Minor code updates. Cleanups related to recent code migration to AbstractMap. * java/util/LinkedHashSet.java: New file. * java/util/LinkedList.java: (readObject, writeObject): Fix serialization. * java/util/Makefile.am: List recently added files. * java/util/Stack.java: Minor code updates. * java/util/TreeMap.java: Improve javadoc. Overhaul the class to be more efficient. Fix some scoping. Rearrange the methods. (nil): Ensure that this can be thread-safe, and make it a static final. Initialize it to be more useful as a sentinal node. (Node): Specify color in constructor. (deleteFixup, insertFixup): Improve comments and algorithm. (fabricateTree): Redesign with less overhead. (lowestGreaterThan): Add parameter first to make SubMap easier. (removeNode): Patch hole where nil was being modified. Choose predecessor instead of successor so in-place swap works. (class VerifyResult, verifyTree, verifySub, verifyError): Remove this dead code after verifying the class works. (class SubMap): Rewrite several algorithms to avoid problems with comparing nil. * java/util/TreeSet.java: Improve javadoc. Fix some scoping. (clone): Fix ClassCastException when cloning subSet(). (readObject, writeObject): Fix serialization. * java/util/WeakHashMap.java: Improve javadoc. Fix some scoping. (NULL_KEY): Make it compare as null, for ease elsewhere. (Class WeakEntry): Rename from Entry, to avoid shadowing Map.Entry. Add missing toString. (modCount): Ensure that this is updated correctly. (clear, containsValue, keySet, putAll, values, WeakHashMap(Map)): Add missing methods and constructor. -- 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: classpath ./ChangeLog java/util/AbstractList.ja...
Bryce McKinlay wrote:
I also looked at your implementations of removeAll/retainAll in Vector
-- nice. But don't you think its odd that there would be optimized
implementations in Vector but not ArrayList? I wonder if we should put
those in ArrayList as well. In the past I have avoided including any
public methods that wern't part of the Javadoc spec, but that was more
to help ensure that the implementation worked similarly to Sun's rather
than for any real correctness reasons, since of course adding extra
virtual methods should not effect binary compatibility in any way in
Java. What do you think?
I dunno - I'm hesitant to add unspecified public methods to public
classes, even though as you point out they will not destroy binary
compatibility.
I think Sun didn't notice the possibility for my optimization. I guess
Vector has removeAll when ArrayList doesn't simply because Vector needs
to be synchronized. Which is odd, because Sun didn't allow for iterator
or listIterator in Vector, so I was unable to create iterators which
were properly synchronized. Maybe we could use package-private hooks to
work around these spec shortcomings while still maintaining the public
API:
AbstractList.java:
public boolean removeAll(Collection c)
{
return internalRemoveAll(c);
}
boolean internalRemoveAll(Collection c)
{
// existing implementation
}
public Iterator iterator()
{
return internalIterator();
}
Iterator internalIterator()
{
// existing implementation
}
ArrayList.java:
boolean internalRemoveAll(Collection c)
{
// optimized implementation
}
Vector.java:
Iterator internalIterator()
{
// synchronized implementation
}
It was a little easier working with the nested classes in Collections.
For example, I added methods like Collections.EmptySet.toArray, which
Sun did not implement (of course, I tested this using only
java.lang.reflect, and not by decompiling or looking at JDK source).
But in those nested classes, I did not feel guilty adding public methods
because the entire class is private and undocumented except for its
serializable nature.
--
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: classpath ./ChangeLog java/util/AbstractList.ja...
Agreed, and I just committed a patch. Thanks for the feedback - it's nice to know my work has an audience. Bryce McKinlay wrote: Hi Eric, Thanks!! (rangeExclusive, rangeInclusive): Add common methods for bounds check. These should really be called checkBoundsInclusive and checkBoundsExclusive for consistency with AbstractList (plus, it makes it clearer what they actually do when reading the code...) -- 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
java.lang.reflect.Proxy
I finally got all the bugs worked out enough to check in my first version of java.lang.reflect.Proxy (I started this project several months ago). Feel free to provide suggestions on ways to improve it. In the process, I also did some cleanup in the java.lang.reflect package. -- 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
question about vm/reference files
What is the reason that some of the VM dependent core .java files are not located directly in the top tree, while others are? For example, java/lang/Object.java is in the main tree, but java/lang/Throwable.java is only in the vm/reference subtree. I understand why things like VMClassLoader.java are not in the main tree, since that is not a public API, even if it does compile to the java.lang package. But for compilation 3rd-party projects, jikes needs a .jar file with all the public APIs, even .class files for things like Object (where the VM probably never loads the .class file, because the it just uses native code). It is annoying to have to look in two places to build this .jar file. Would there be anything wrong with moving these .java files from vm/reference/java/lang to the main tree at java/lang? Class Runtime Thread Throwable reflect/Constructor reflect/Field reflect/Method -- 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: question about vm/reference files
The thought was that Classpath either would not provide the classes that are VM dependent (leaving those to the VM) or that there would be multiple directories (vm/gcj, vm/orp, vm/kaffe, etc.) The ugly complexity appears to be necessary. Brian That still doesn't explain why Object is in the top level when the other core classes are not. Even if these classes have no Java implementation, it is still useful to have a .java file in Classpath for making the .class file which jikes requires for compilation purposes. -- 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
java.util
I just committed a large change to some of the core classes of java.util (Abstract*.java, Arrays, BasicMapEntry, and Collections). A lot of it was just adding javadoc, formatting to GNU standards, and replacing some code with more efficient constructs, but I also fixed a few bugs. In particular, in Collections, I made all the nested classes compliant to JDK serialization. Let me know if I introduced any problems. I have more changes pending on the implementation classes (such as HashMap, ArrayList, Vector, ...), but want to make sure the abstract framework is correct first. I currently don't have write access to libgcj. Should I apply for that, so that I can do the work of keeping the two in synch, rather than leaving that responsibility on others like Tom? -- 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: build ideas
Brian Jones wrote: Who knows, improving the build framework might inspire someone to improve the dependency tracking that jikes does, to make that part of compilation even more efficient and compatible with automake. I tried working with jikes dependency tracking some time ago and I think I pretty much gave up on it. What is the current state of this? As far as I know, little work is currently being done on jikes' dependency tracking (there are only 3 or 4 active developers at the moment, and none of us have been tackling it). There is one outstanding patch that has yet to be applied to CVS which claims to allow command-line specification of the target directory for the generated .u files. Yet there are also several standing bug reports on flaws in the algorithm, such as questions over whether a .java file should be dependent on inner classes. Personally, I have never looked at that part of the jikes code, so I have no idea what it would take to make +M spit out the best possible dependence files. However, I feel that I could usefully spend some time on that project if it would help the Classpath project. I agree with the earlier sentiment that Ant has the drawback of requiring a working JVM installed on the machine, while make does not. While Ant may be the de-facto build framework for Java projects, it would be difficult to use when bootstrapping a free machine, which probably would not come with a free VM binary already installed. I also agree that make CAN be made to do anything that Ant can, it is just a tougher assignment to write the correct rules. But with automake and jikes dependency tracking (fixed, of course), I think this should be feasable. By the way, I don't have Ant installed on my machine; but make comes standard with cygwin. What about the idea of both a Makefile and build.xml approach to building the .class files? Then Ant users who just want classes.zip and already have a VM don't have to worry about make, but developers that care about the native code don't need to worry about Ant even for the .class files. The only drawback of this dual approach is that developers must remember to list new .java files in two separate build framework files, instead of one. -- 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: build ideas
I'm all for a way to compile the .class files without the shared libraries. I develop on a cygwin platform, which does not have the best support for free VMs or for shared libraries, so I tend to just compile the java files. By the way, I think developers should have the autotools installed on their machine, so I see no reason for CVS to keep track of generated files like configure and Makefile.in, only the originals like Makefile.am. The generated files should be part of the distribution, though, since end users should not be required to have all the developer tools just to use the final product. Fortunately, automake does this correctly. Who knows, improving the build framework might inspire someone to improve the dependency tracking that jikes does, to make that part of compilation even more efficient and compatible with automake. Brian Jones wrote: Like other GNU projects, I would like to continue to use the automake/autoconf system for driving the compilation of Classpath. For releases I'd like to continue to distribute compiled .class files and generated JNI headers. I want CVS builds to generate JNI headers and .class files relying only on free software. There exists a need within our community to generate .class files without compiling native libraries and I'd like that to be easier... it seems to me that to be successful this must be faster than 'jikes -d /tmp `find java gnu vm/reference -regex .*\.java$` or some working equivalent. -- 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: Partial Double/Float merge with libgcj
Shoot, I meant to hit reply-to-all.
Eric Blake wrote:
Chris Gray wrote:
An interesting twist on this: jikes seems to have its own idea of the correct
bit-pattern for NaN (0xffc0 instead of 0x7fc). This shouldn't matter
if all NaN's are canonicalized to the same value.
Which version of jikes? My guess is version 1.13 or sooner, as floating
point emulation mode was made default in later versions. When doing
floating point emulation jikes should always spit out 0x7fc0 for
Float.NaN, but with native math, it uses whatever the CPU thinks is NaN
(which for x86 architecture is 0xffc0). But you are right, as long
as Float.floatToLongBits canonicalizes NaN, there should be no problem
with the current algorithm.
However, I argue that this is a faster implementation (it avoids a
native call):
public static boolean isNaN(double v)
{
return v != v;
}
This works since NaN != NaN is the only reflexive inequality comparison
which returns true.
--
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
More on java.util.HashMap...
Thanks for all the recent comments on my contributions in java.util.Hashtable, HashMap, and such. Where people have cast doubt on the efficiency of my prior patches, I've reverted those. I also just added LinkedHashMap (new in JDK 1.4), and would like another pair of eyes to look over my work to check for any glaring bugs or items that could be improved. Now, I need to find time to write some Mauve tests for these fixes... -- 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: Question on nested types
No, javac and jikes are correct. Similarly, it is possible for a
private field to hide a visible field:
class A {
public int i;
}
class B extends A {
private int i;
}
class C extends B {
void foo() {
// illegal, i is hidden in B, and A's i is not available
// i++;
}
}
Also, see
http://www.ergnosis.com/java-spec-report/java-language/jls-8.5-b.html
for an unofficial take on the hole in the JLS.
You're thinking of methods, where it is NOT legal for a method with less
visibility to hide one with more.
Erwin Bolwidt wrote:
import java.util.*;
class Foo
{
public static void main(String[] args)
{
System.out.println(Hashtable.Entry.class == Map.Entry.class);
}
}
I think it is a bug in javac and jikes. Since Hashtable.Entry is private,
it is not visible to other classes, so it does not hide Map.Entry. So your
example should work, but the compilers are probably wrong.
It is not so strange though that Hashtable has its own Entry member class,
because Map.Entry is an interface that still needs to be implemented.
Yes, but the implementation need not be named Entry, so that it does not
hide the inherited Map.Entry.
- Erwin
--
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
Question on nested types
I just noticed the JDK 1.4 documentation for java.util.Hashtable claims
that Hashtable inherits the nested type Entry from Map:
http://java.sun.com/j2se/1.4/docs/api/java/util/Hashtable.html
This would mean that the following program should be legal, and output
true:
import java.util.*;
class Foo
{
public static void main(String[] args)
{
System.out.println(Hashtable.Entry.class == Map.Entry.class);
}
}
However, it does not compile against Classpath, since the implementation
of Hashtable defines a private nested class named Entry which hides
Map.Entry, and Hashtable.Entry is not accessible (instead of being an
alias for Map.Entry as the documentation claims). See JLS 8.5 for the
specification of nested class hiding.
But perhaps the bug is in Sun's javadoc. Notice that the JDK 1.4
classpath will not allow compilation of the example class either. In
other words, Sun's implementation (without decompiling it to verify)
also seems to have a private nested class Hashtable.Entry which hides
and prevents the inheritance of the public Map.Entry.
So, which do we follow, Sun's behavior or specification? Behavior-wise,
Classpath is correct because it behaves identically to the JDK;
specification-wise, both libraries are in error by not accepting the
above program as legal, and the fix for Classpath would be simply
renaming Hashtable.Entry to something like Hashtable.HashEntry.
I just submitted a bug report to Sun's website on the matter, but it may
be a while before I get a response.
--
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
java.util.HashSet
I was just looking at the code for HashSet tonight, and noticed that it
just uses HashMap as its backing store. This may be the way that Sun
does it, according to their javadoc, but I don't think the
implementation is a necessary detail; just the API and behavior. And it
seems to me that making a HashMap of (Object, java.lang.Boolean.TRUE)
pairs is a waste of memory and processor time, when the set could be
implemented directly.
Does anyone see why this patch should not be applied?
2001-09-07 Eric Blake [EMAIL PROTECTED]
* java/util/HashSet.java: implement the set directly, instead
of with a backing HashMap
--
This signature intentionally left boring.
Eric Blake [EMAIL PROTECTED]
BYU student, free software programmer
Index: java/util/HashSet.java
===
RCS file: /cvsroot/classpath/classpath/java/util/HashSet.java,v
retrieving revision 1.8
diff -u -r1.8 HashSet.java
--- java/util/HashSet.java 2001/02/18 15:39:58 1.8
+++ java/util/HashSet.java 2001/09/08 05:01:12
@@ -1,5 +1,5 @@
-/* HashSet.java -- a class providing a HashMap-backet Set
- Copyright (C) 1998, 1999 Free Software Foundation, Inc.
+/* HashSet.java -- a class providing a hash-based Set
+ Copyright (C) 1998, 1999, 2001 Free Software Foundation, Inc.
This file is part of GNU Classpath.
@@ -32,187 +32,480 @@
import java.io.ObjectInputStream;
import java.io.ObjectOutputStream;
+// NOTE: This implementation is very similar to that of Hashtable and
+// HashMap. If you fix a bug in here, chances are you should make a
+// similar change in those locations.
+
/**
- * This class provides a HashMap-backed implementation of the
- * Set interface.
+ * This class provides a hashing implementation of the Set interface.
+ * While the Sun implentation simply uses a backing HashMap, this
+ * version is more memory efficient; but binary serial compatibility
+ * remains intact.
+ * p
*
- * Each element in the Set is a key in the backing HashMap; each key
- * maps to a static token, denoting that the key does, in fact, exist.
+ * The set is not synchronized; if multiple threads must handle this
+ * set, wrap it with {@link Collections#synchronizedSet(Set)}. Meanwhile,
+ * the iterator is emfailfast/em, so that modifications performed
+ * while an iterator is in operation throw a
+ * {@link ConcurrentModificationException}.
+ * p
*
* Most operations are O(1), assuming no hash collisions. In the worst
- * case (where all hases collide), operations are O(n).
+ * case (where all hashes collide), operations are O(n). Setting the
+ * initial capacity too low will force many resizing operations, but
+ * setting the initial capacity too high (or loadfactor too low) leads
+ * to wasted memory and slower iteration.
+ * p
*
* HashSet is a part of the JDK1.2 Collections API.
*
- * @author Jon Zeppieri
+ * @author Jon Zeppieri
+ * @author Eric Blake [EMAIL PROTECTED]
+ * @since 1.2
*/
public class HashSet extends AbstractSet
implements Set, Cloneable, Serializable
{
- /** the HashMap which backs this Set */
- transient HashMap map;
- static final long serialVersionUID = -5024744406713321676L;
+ /**
+ * Default number of buckets.
+ */
+ private static final int DEFAULT_CAPACITY = 11;
+
+ /**
+ * Default load factor.
+ */
+ private static final float DEFAULT_LOAD_FACTOR = 0.75f;
+
+ /**
+ * compatible with JDK 1.2+
+ */
+ private static final long serialVersionUID = -5024744406713321676L;
+
+ /**
+ * The load factor of the set; if size() exceeds capacity * loadFactor,
+ * the set is rehashed
+ */
+ private transient float loadFactor = DEFAULT_LOAD_FACTOR;
+
+ /**
+ * The backing storage
+ */
+ private transient Entry[] buckets;
+
+ /**
+ * counts the number of modifications this HashSet has undergone, used
+ * by Iterators to know when to throw ConcurrentModificationExceptions.
+ */
+ private transient int modCount;
/**
- * construct a new, empty HashSet whose backing HashMap has the default
- * capacity and loadFacor
+ * the size of this HashSet: denotes the number of elements in the set
*/
+ private transient int size;
+
+ /**
+ * Class to represent an entry in the set.
+ */
+ private static final class Entry
+ {
+Entry next;
+
+Object element;
+
+Entry(Object element)
+{
+ this.element = element;
+}
+
+protected Object clone()
+{
+ Entry copy = new Entry(element);
+ if (next != null)
+copy.next = (Entry) next.clone();
+ return copy;
+}
+ }
+
+ /**
+ * construct a new, empty HashSet with default capacity (11) and
+ * loadFacor (0.75).
+ */
public HashSet()
{
-map = new HashMap();
+this(DEFAULT_CAPACITY, DEFAULT_LOAD_FACTOR);
}
/**
- * construct a new, empty HashSet whose backing HashMap has the supplied
- * capacity and the default load factor
+ * construct
Re: [Patch #25] String.CASE_INSENSITIVE_ORDER implements Serializable
Aha - I just got the email today that my paperwork cleared FSF. So, now it's just a matter of getting my CVS write access set up, and I'll check this in. In the meantime, feel free to make the change in libgcj - I didn't apply for developer access on that project (maybe I should, but not now). Tom Tromey wrote: Eric == nobody [EMAIL PROTECTED] writes: Eric Patch #25 has been updated. Eric Summary: String.CASE_INSENSITIVE_ORDER implements Serializable This patch looks good to me. Eric, what is your paperwork status? If you're going to have direct write access soon, then I'd rather you just check this in. Otherwise I will do it. I'm going to use your patch to make a patch for the libgcj String which does the same thing. (String is one of the few classes that will probably never be merged.) Tom -- 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: Weird characters in java/lang/Character.java
I'm the release manager for the upcoming jikes 1.15 release, currently targetted for Sept 26. Is there an actual bug with jikes' interpretation of encodings? If so, it might be a wise idea to move this discussion over to the jikes mailing lists, to see if we can repair it in time for the next release. Unfortunately, I'm not the expert on encodings. As pointed out earlier, the most portable solution would be using \u characters instead of 8-bit ascii characters in the source .java files of Classpath, as then jikes does not have to pull any encoding tricks. Etienne M. Gagnon wrote: On Mon, Sep 03, 2001 at 03:45:13PM -0400, Etienne M. Gagnon wrote: Brian Jones wrote: ... I'm using jikes 1.13 straight out of Red Hat 7.1. I'm on Debian sid running jikes 1.14 with glibc 2.2.4. I will try again with jikes 1.13, rebuilt from sources. ... In case anybody is interested, I got Jikes 1.13, compiled it, then used it to recompile Classpath/Sablepath, and it effectively works now. So, beware of Jikes 1.14 if you're on Debian :) Etienne -- -- 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
java.lang.StrictMath and copyright
I noticed that classpath does not yet implement java.lang.StrictMath. Sun's specification refers to fdlibm as being the canonical implementation, available at http://metalab.unc.edu/. I downloaded that to see how hard it would be to implement StrictMath in pure Java (although it would be a while before I could get to that project, if someone else wants to start first). All the files in that library carry this notice: * * Copyright (C) 1993 by Sun Microsystems, Inc. All rights reserved. * * Developed at SunPro, a Sun Microsystems, Inc. business. * Permission to use, copy, modify, and distribute this * software is freely granted, provided that this notice * is preserved. * Am I correct that this is compatible with the GPL+exception, provided that the copyright text above is included in the resulting implementation of StrictMath? Are there any other legal gotchas to be aware of before someone includes a modified version of fdlibm in Classpath? -- Eric Blake, Elixent, Castlemead, Lwr Castle St., Bristol BS1 3AG, UK [EMAIL PROTECTED] tel:+44(0)117 917 5611 ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: java.lang.Class inner class methods
Not so. '$' is a legal identifier character, so I can compile a non-inner
class as follows:
class X$Y {}
In order to detect inner classes in the VM (or in a compiler when reading
.class files), you MUST read the attributes, rather than relying on the
naming convention in the inner class specification.
It would be nice if Sun would give compilers a guaranteed namespace that
cannot conflict with user identifiers, but that has not happened yet...
Original message:
Thu, 2 Aug 2001 11:22:54 +0200 (MET DST)
The inner class Y of class X is compiled as X$Y.
So if a class name contains $, it must be an innerclass.
This is documentend in the Innerclass specification,
http://java.sun.com/products/jdk/1.1/docs/guide/innerclasses/spec/innerclass
es.doc.html
in section Class Name Transformation
http://java.sun.com/products/jdk/1.1/docs/guide/innerclasses/spec/innerclass
es.doc7.html
-Patrik
--
Eric Blake, Elixent, Castlemead, Lwr Castle St., Bristol BS1 3AG, UK
[EMAIL PROTECTED] tel:+44(0)117 917 5611
___
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath
