Re: Weird characters in java/lang/Character.java
Etienne M. Gagnon wrote: Thanks. I have came to the same conclusion, using a small program looking for non-ASCII characters in all .java files. The real issue I had proved to be a Jikes 1.14 (on Debian?) problem, where many other files failed to compile for a different reason. It's jikes-1.14 : we've had problems with it too, on RedHat. Chris ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: Ant (was Re: about RMI)
At Thu, 06 Sep 2001 10:02:14 -0400, Etienne M. Gagnon [EMAIL PROTECTED] wrote: I have already packaged a version of Classpath using Ant. It is called Sablepath-classes, and it resides in the CVS repository of the SableVM project on SourceForge. You can give it a look. I couldn't compile Sablepath now but I think it's good idea:) I also prefer ant when I use Java. On the other hand, I would not use it for building the native libraries, and the GNU auto* tools (including libtool) are much more appropriate for it. sure. Ant is for Java:( It would be nice if you gave a look at the Sablepath-classe build process and commented about it. Would you add target about 'clear' ,'prepare' and so on..? You can refer a lot of good examples at http://jakarta.apache.org/;) regards. Takashi Okamoto ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: Duplicate JNI files.
Etienne M. Gagnon [EMAIL PROTECTED] writes: A look at the Makefile.am files seem to indicate that most current files are usually in native/jni, but a careful look into ChangeLog shows that sometime, both duplicates evolves into its own branch. I haven't deleted the old native/java.* things yet. Things were moved to make room for a cni directory at the same level as the jni directory. I asked about putting all of them in one directory and agreement was that would be fine. I have no problem with splitting them up either... it doesn't matter for automake/autoconf which way it is done. -- Brian Jones [EMAIL PROTECTED] ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: Ant (was Re: about RMI)
At Fri, 7 Sep 2001 06:11:51 -0700, Anthony Green wrote: gcj has a --encoding= option. I didn't know such a option, thanks. And what do you mean by no debug? I'm wrong. I didn't implement about debug. But someone put it into latter.. I would just change these to use -g and -O2 I'll post it to ant-devel-ml. regards. Takashi Okamoto ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: Duplicate JNI files.
On Fri, Sep 07, 2001 at 09:03:27AM -0400, Brian Jones wrote: I haven't deleted the old native/java.* things yet. Things were moved to make room for a cni directory at the same level as the jni directory. I asked about putting all of them in one directory and agreement was that would be fine. I have no problem with splitting them up either... it doesn't matter for automake/autoconf which way it is done. OK, this confirms my guess that the newer stuff is in native/jni. I. COPY VS MOVE -- Consequences solutions The problem with moving without deleting is one of consistency. You probably didn't notice the following ChangeLog entry that happened AFTER you moved native/java.lang/Double.c to native/jni/java_lang_Double.c : 2001-04-20 J. Russell Smyth [EMAIL PROTECTED] ... * native/java.lang/Double.c (toString): Corrected format specifiers for sprintf call to give better precision. Which means that, currently, there is a bugfix in native/java.lang/Double.c which has not been applied to native/jni/java_lang_Double.c. To make it worse, native/jni/java_lang_Double.c has also been modified since the move. The good news is that Double.c is the only file which has had this problem so far (old copy modified). Solution For this reason, I urge you to cvs -f remove all moved files. (Personally I prefer to say copied files when the original copy is left in place). As for the Double.c problem, you could use cvs diff to extract a patch of the modification made by Russell Smyth, then apply this patch to the newer copy. Then I would cvs -f remove the old copy along all other moved files. II. About the native/jni organization (and some inconsistencies) I agree that to the auto* tools, the organization of native/jni doesn't matter much. But for my poor human brain, and for simple brain-dead yet useful utility scripts, it can make a bigger difference. ;) So, what I propose is an intuitive organization of these directories. Mainly, what I see is one directory per libxxx.so library, where the directory name is xxx, matching the name found in Java source files, e.g. System.loadLibrary(xxx). Now (back to my brain-dead scripts), I have a little script that effectively goes through the Java sources, and it tells me that the following libraries are loaded from Java code (I exclude all the test stuff): bigint cpgdkpixbuf gtkpeer javaio javalang javalangmath javanet javautil runtime One initial comment: The 'System.loadLibrary (runtime);' in java/lang/Throwable.java makes no sense (and the whole static block should be removed). This is because runtime represents the VM, which is obviously running and available as a library at the time of this call! If you think a little about it, you'll notice that loadLibrary itself is a native method (or it necessarily calls one) of class System. Q: Wouldn't you expect System to have a static initializer calling loadLibrary so that the native loadLibrary method can be successfully linked? va.lang.System? (chicken/egg) So, let's get rid of runtime. We are now left with: native/jni/bigint native/jni/cpgdkpixbuf ... You'll see that there is no native/jni/javalangreflect. This is because I definitely think that the test stuff should be put apart, in its own directories, and be kept completely optional. Also, you'll notice that the current Classpath native/jni code does not build the libbigint.so library, even though it is required by the Java source code... [Thanks to brain-dead scripts, finding such things can be easy;-)] I definitely think that this whole JNI stuff should be buildable without ANY dependency on a VM. All you need is a plain JNI definitions file. [SableVM's definition file has been written with that in mind, and is released into the Public Domain. Do you want it?]. In fact, this was the primary objective of the JNI designers: no VM dependency whatsoever for compiling the stuff. A little later today, I will let you know when sablepath-libs is ready, so that you see how one can build the native libraries without any vm dependency. Obviously, there are some consequences to breaking the libraries into java / native code. One of them is that the generation of JNI header files is now semi-automatic. You first build / install the java classes, then you run a simple script that regenerates the JNI header files. You store the generated header files into CVS and distribution packages. As not every VM already has a javah like tool, you remove, by doing so, an artificial build dependency on specific VMs, or even proprietary tools [javah]. (In fact, one could write a Java based tool to emulate javah. As long as one is able to run an older version of his VM, he will be able to work in a completely Free environment). So, Brian, does this sounds as a good organization the native/jni sources? Have fun! Etienne -- Etienne M. Gagnon
Re: [Patch #25] String.CASE_INSENSITIVE_ORDER implements Serializable
Eric == Eric Blake [EMAIL PROTECTED] writes: Eric Aha - I just got the email today that my paperwork cleared FSF. Eric So, now it's just a matter of getting my CVS write access set Eric up, and I'll check this in. Is this in progress? If you want I can send email to the cvs guys to get you an account. Tom ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: jazzlib into java.util.zip
John == John Leuner [EMAIL PROTECTED] writes: John 2001-09-07 John Leuner [EMAIL PROTECTED] John* java/util/zip/*.java: imported the jazzlib code. Should Johnall be functional. John I compiled it, but haven't run it. It should all work however. Which repository is the master repository? FWIW I'd prefer Classpath. The header comments all mention Jazzlib and not Classpath. Tom ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: Duplicate JNI files.
Brian == Brian Jones [EMAIL PROTECTED] writes: Etienne Also, you'll notice that the current Classpath native/jni Etienne code does not build the libbigint.so library, even though Etienne it is required by the Java source code... [Thanks to Etienne brain-dead scripts, finding such things can be easy;-)] Brian I do not believe we've ever had one, and BigInteger doesn't Brian work obviously. :) libgcj has an all-Java BigInteger. It could be imported into Classpath with little trouble. Etienne [SableVM's definition file has been written with that in Etienne mind, and is released into the Public Domain. Do you want Etienne it?]. Do you mean jni.h? There is also one in libgcj, though it currently has some unportable bits and libgcj dependencies. Etienne As not every VM already has a javah like tool, you remove, Etienne by doing so, an artificial build dependency on specific VMs, Etienne or even proprietary tools [javah]. gcj includes a free javah program, called gcjh. Brian I'm almost done eith a full javap replacement that uses GNU Brian bytecode. Writing javah is trivial as well with this package Brian and I'll do it soon. Getting the decompilation to java Brian assembly to display as I want (just as Sun's javap does) has Brian proven tricky. FYI gcj includes jcf-dump, which is similar to javap. It isn't exactly the same, but it does have bytecode disassembly. Tom ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: Duplicate JNI files.
On Fri, Sep 07, 2001 at 08:11:50PM -0600, Tom Tromey wrote: Brian I'm almost done eith a full javap replacement that uses GNU Brian bytecode. Writing javah is trivial as well with this package Brian and I'll do it soon. Getting the decompilation to java Brian assembly to display as I want (just as Sun's javap does) has Brian proven tricky. FYI gcj includes jcf-dump, which is similar to javap. It isn't exactly the same, but it does have bytecode disassembly. Shameless plug... ;-) Have you looked, guys, at the Soot project (http://www.sable.mcgill.ca/soot)? It is a complete bytecode optimization framework. It has proven to improve java programs execution speed, even on HotSpot. [See the papers page for details]. Internally, it supports many representations, which can be pretty handy for programmers that want to look at classes. It even does type inference for local variables (that's my bit, proven to be NP-hard, but we have a practical cheat to get a fast polynomial solution: read the papers again;-) But, more importantly, Jerome Miecznikowski added a code restructurer (e.g. get rid of goto's) on top of all this. He calls the result dava, which is kind of a pretty neat decompiler. Last message I got about it, it was supposed to be in beta stage. You can have a look at http://www.sable.mcgill.ca/~jerome/public/ Just though the stuff might interest you... Etienne -- Etienne M. Gagnonhttp://www.info.uqam.ca/~egagnon/ SableVM: http://www.sablevm.org/ SableCC: http://www.sablecc.org/ ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: Duplicate JNI files.
Brian wrote: I'll remove the files shortly. Ooops, I had missed this bit;-) OK. Super! Etienne -- Etienne M. Gagnonhttp://www.info.uqam.ca/~egagnon/ SableVM: http://www.sablevm.org/ SableCC: http://www.sablecc.org/ ___ 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 a
