Re: classpath ./ChangeLog java/util/AbstractList.ja...

[Eric Blake]

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...

[Bryce McKinlay]

Eric Blake wrote:

>Agreed, and I just committed a patch.
>
>Thanks for the feedback - it's nice to know my work has an audience.
>

You're welcome!

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?

regards

Bryce.



___
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath

Re: classpath ./ChangeLog java/util/AbstractList.ja...

[Eric Blake]

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

more java.util

[Eric Blake]

I made another commit to java.util, this time to the List related
files.  Again, my biggest change was standardizing the javadoc and
formatting, but I also patched a few bugs.

2001-10-21  Eric Blake  <[EMAIL PROTECTED]>

* java/util/AbstractList.java:
(modCount): Make sure it is updated in all needed places.
* java/util/ArrayList.java: Improve javadoc. Implements
RandomAccess. Add serialVersionUID. Reorder methods.
(modCount): Make sure it is updated in all needed places.
(rangeExclusive, rangeInclusive): Add common methods for bounds
check.
(isEmpty): Add missing method.
* java/util/Collections.java: (class SynchronizedList): Make
package visible.
* java/util/ConcurrentModificationException.java: Improve
javadoc.
* java/util/EmptyStackException.java: Improve javadoc.
* java/util/LinkedList.java: Improve javadoc.
(modCount): Make sure it is updated in all needed places.
(rangeExclusive, rangeInclusive): Add common methods for bounds
check.
* java/util/NoSuchElementException.java: Improve javadoc.
* java/util/Stack.java: Improve javadoc. Fix synchronization
issues.
(modCount): Make sure it is updated in all needed places.
* java/util/Vector.java: Improve javadoc. Fix synchronization
issues. Implements RandomAccess. Reorder methods.
(modCount): Make sure it is updated in all needed places.
(setSize): Fix according to specifications: this does not dictate
the backing array size.
(removeAll, retainAll): Faster implementations.

Still outstanding in my local tree are modifications to the Set/Map
classes.  In the meantime, feel free to point out any bugs in my recent
commits.

I've noticed two main styles in java.util .java layouts, which probably
extend to other files.  One style lists public methods in alphabetical
order, the other lists them in the same order as the JDK web pages.  Is
there a preference as to which is better?  Also, is there a preference
as to whether field declarations should come before or after methods? 
I've sort of leaning to this approach (in part because it is similar to
the JDK web page layout):

class Foo
{
  static fields (constants first)
  instance fields
  constructors
  abstract methods
  other public methods, in alphabetical order
  helper (package-)private methods
  nested classes
}

Any preferences one way or another? Or flames in my general direction
for messing things up? If one layout style is preferred as the standard,
it would be a nice thing to document on the Classpath website and the
HACKING instructions.

-- 
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.reflect.Proxy

[Mark Wielaard]

Hi,

On Sat, Oct 20, 2001 at 07:05:47PM -0600, Eric Blake wrote:
> 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. 
Impressive. I will print out the source code and see if I understand it
and give some comments on it.

> In the process, I also did some cleanup in the java.lang.reflect
> package.
I saw that you also changed some exception things "in anticipation of 1.4
compatibility". I have been working on that, but it has been a while ago.
An old version can be found in the Classpath mail archives. I also have
some local libgcj hacks that almost work. But the Classpath/libgcj merge
work is currently eating up all my Classpath time so it might take a while
for that code to appear in Classpath in full working order. I will see if
I can make some more time to really finish it.

Cheers,

Mark
-- 
Stuff to read:

  What's Wrong with Copy Protection, by John Gilmore

___
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath

Re: question about vm/reference files

[Mark Wielaard]

Hi,

On Fri, Oct 19, 2001 at 08:58:58PM -0600, Eric Blake wrote:
> > 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.
> 
> 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.

The original idea was that some of these classes were to VM specific to
include a generic Classpath version. Some classes have a VMXXX counterpart
that contains the VM generic code but since they do not have to have direct
access to

Now that we have some VMs that actually use Classpath as their standard
class library we can reevaluate the way we split these classes. Which
classes are really so VM specific that they cannot be implemented with a
VMXXX bridge?

What we could do is build two zip files, one with the standard classes and
one with the generic implementation classes (glibj-runtime.zip?) that each
VM should implement in their own VM specific way. (So this second zip would
be very small and contain the 'default' - noop - implementation of the VM
specific classes.)
Then those two zip combined could be used as input for compilers like jikes.
And each VM would have the generic zip file plus an vmspecific zip file in
its bootclasspath.

Cheers,

Mark
-- 
Stuff to read:

  What's Wrong with Copy Protection, by John Gilmore

___
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath

Re: java.util

[Mark Wielaard]

Hi,

On Thu, Oct 18, 2001 at 06:28:02PM -0600, Eric Blake wrote:
> 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.

Great! I really appreciate all the javadoc comments, this will allow us to
generate a reference manual from our sources. I also saw that you updated
a couple of classes to the 1.4 (beta) spec and included a @since 1.4 tag.
This will make it easy to track any changes in that spec.

The Java Collections Clearinghouse  contain
some Test Suites that you might want to run.

Cheers,

Mark
-- 
Stuff to read:

  What's Wrong with Copy Protection, by John Gilmore

___
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath

Re: build ideas

[Mark Wielaard]

Hi,

On Wed, Oct 17, 2001 at 01:51:54PM +0100, Nic Ferrier wrote:
> 
> Personally, I don't like Ant. It's not *free* software either.
It Free Software. It is distributed under the Apache License.
Which is a Free Software license. This does make it GPL incompatible
since it includes the trademark license clauses which is a added restriction
according to the GPL. But since ANT is a standalonce tool which you will
probably never embed into a GPLed program I don't think this is such a
problem. For more info see:


> There's not much you can do with Ant that can't be done with Make
> (given a little thought).
> 
> Ant is also very Java centric, Classpath has a lot of C (and C++ if we
> include the GCJ stuff). Make is perfect for those languages.
But this is a valid argument.
And even if we needed to only compile the java source code and generate
a zip/jar file Ant would be a bit overkill. In that case a classes @file,
a java compiler and a zip/jar tool are enough. Just put that into a simple
Makefile or shell script and you are done.

Cheers,

Mark

-- 
Stuff to read:

  What's Wrong with Copy Protection, by John Gilmore

___
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath

Re: build ideas

[Mark Wielaard]

Hi Brian,

On Tue, Oct 16, 2001 at 11:26:27PM -0400, Brian Jones wrote:
> Like other GNU projects, I would like to continue to use the
> automake/autoconf system for driving the compilation of Classpath.
This seems like a good idea. Especially for the native C/C++ code.

> For releases I'd like to continue to distribute compiled .class files
> and generated JNI headers.
And the configure, Makefile, etc files that are generated from the CVS
source I presume. Is there a way to ship with the generic jni.h file
that Etienne Gagnon made? He released it in the public domain. It is a
real pain to have to have the jni.h file from a particular VM around to
compile the native libraries.

> I want CVS builds to generate JNI headers and .class files relying only
> on free software.
I would suggest to use the GNU Compiler Collection (GCC) tools by default.
It includes a C compiler (gcc), a java to bytecode generator (gcj -C)
and a JNI header generator (gcjh -jni). Although it would be nice to be
able to override these defaults in the configure script (jikes, kaffeh, etc).

> 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.
It would be nice to include a 'classes' file in the release that lists
all the java source files. Such a file can easily be used with any java
compiler that supports the "@file" construct (I think almost all do).
We do have such a file at the moment but it does not seem to be widely
known. Maybe this is just a documentation issue. But maybe it is not
very convenient that this files lives in the lib directory and contains
../java entries. Move it to the toplevel directory?

It would also be nice to have different classes @files for subprojects
such as jazzlib which contains only the java.util.zip classes or a
version that excludes all (LGPLed) AWT code, or standalone versions of
the RMI sources, SQL, etc.
But if such a subproject also includes some native files we also need
a easy way to define which native files belong to which subproject.
It seems libgcj tries to do something like this.
 
> Additions?  Contrary notions?  Devil's advocate?
In the (far, far) future it would be nice to split the libgcj library in
a real runtime libary and a classes library, then we could create the
(native) gcj classes library straight from the Classpath sources.

Cheers,

Mark

P.S. I just bought a paper version of "The Goat Book"
 
 So please let me know if you need any help.
 (then I will have a real reason to actually read it :)
-- 
Stuff to read:

  What's Wrong with Copy Protection, by John Gilmore

___
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath