Re: Preparing for 0.06 release

[Mark Wielaard]

Hi,

There is (in a couple of minutes) a first test tar ball up at:
http://www.klomp.org/mark/classpath/classpath-0.06-test1.tar.gz (5.4M)
And I would appreciate it if someone could try it out.
But there are still some things todo before 0.06.

- More bugs...

3207API installation fails, argument list too long
Postponed?

3872Extra optional Exceptions thrown in e.g.
List.remove(Object) since 1.4
Postponed?

4118java.text.RuleBasedCollator is incompleted
Unanalyzed.

4120Locale collation rules incorrect (or missing)
Unalalyzed.

4357HTTP Request Headers should be handled Case Sensitive
Unanalyzed.

4477PrintWriter.checkError() gives wrong result sometimes
Seems to work for us, but libgcj is wrong. Strange, analyzis
seems to indicate
that this should also be a problem for us...

4741java.util.GregorianCalendar returns 0 for the first week
of the month
Unanalyzed.

4742java.io.StreamTokenizer behaves differently from Sun's
implementation
Unanalyzed.

- VMThread.
Postponed.

- VMSecurityManager
Postponed.

- VMMethod
Unanalyzed/Postpone?

- Import new external libraries
  - GNU-JAXP

- make dist.
Now creates a nice tar ball that can then be used to just
./configure && make && make install.

- make distcheck.
Would be nice to be distcheck clean, but currently we have lots of files
left after a make clean (mainly lib/*/ .class files).

- gjdoc
Played with it a bit and almost have it working, but gjdoc from CVS
doesn't build out of the box for me. I have to add the GNUJAXP sources,
play with resource paths a bit. Now still have to add a xml.transformer.
The Debian package from unstable is broken.

- .so files
Make install doesn't create .so files for me. For example I now have in
/usr/share/classpath/lib/classpath:
libjavanet -> libjavanet.0.0.0
libjavanet.0 -> libjavanet.0.0.0
libjavanet.0.0.0
libjavanet.la
No .so files.
Linking libjavanet.so -> libjavanet.0.0.0 by hand seems to work.

- tar balls
  - Create tests
  - Where to host? (alpha.gnu.org)

- NEWS file

- Announcement
  - Write
  - When to announce?
  - Where to announce?

- Bumb version number and tag tree just before final tar ball.

I am slowly going through this list. Hopefully resolving all items so we
have a real 0.06 tomorrow.

Cheers,

Mark



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

RE: Preparing for 0.06 release

[Mark Wielaard]

Hi,

On Mon, 2003-08-11 at 08:53, Jeroen Frijters wrote:
> Mark Wielaard wrote:
> >   - Is there any progress on the Thread/VMThread split?
> > Would be nice to get that in, but it will require work to make it
> > work with the different VMs so it better go in quickly
> > (today/tomorrow).
> 
> I think it would be good if another VM implemented it, to see if the
> proposed split works there as well (IKVM is already running with it).
> Besides that, VMThread needs to be documented and a NEWS entry needs to
> be written. I've attached the code I've got at the moment.

I won't have time to try it out with another VM at the moment and the
VMThread class really needs documentation (you might be able to lift
some documentation of my old proposal).

> A side question (that's important for deciding whether to include it in
> the 0.06 release), do any VMs use the unmodified reference Thread class?

I believe the kissme VM just uses the vm/reference version of Thread.

But lets decide to get the Thread/VMThread in after the 0.06 release on
Friday. Then We can do it together with a better design for the
SecurityManager/VMSecurityManger thing. It is only four days till the
release if everything goes well. And I want to have the next release a
bit sooner then 6 months (say 3 months if we have enough new stuff).

Cheers,

Mark



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

Re: Serialization

[Guilhem Lavaux]

Mark Wielaard wrote:

Hi,
 

Besides you suppress the check for 
the availability
of the field although it is quite sure it will not be there (I did not 
find it in the all source
code of classpath): this causes some huge NullPointerException problems.
The only solution is to change the name "getSerialPersistentFields" into 
"serialPersistentFields"
but I do not see the point to complicate things... :( (if someone can 
explain it to me)
   

The only user of the method is setFields() which does the check before
calling getSerialPersistentFields() (it checks by also doing a
getDeclaredField, but this time with the correct spelling).
I agree that the code is not that clean.
 

Once I have the agreement I will submit the necessary modifications to 
make the serialization a little
stronger (well at least it will make kaffe's regression test pass). 
There are still one or two issues like the
fact the serializer does not check invalid serialPersistentFields but it 
nearly behaves rightfully.

Cheers,
Guilhem.


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

Serialization

[Guilhem Lavaux]

Hi !

I am trying to import object serialization classes from Classpath to 
kaffe. I managed
to make them work together but I found some behaviour inconsistencies. 
For example,
I do not understand the method 
java.io.ObjectStreamClass.getSerialPersistentFields:
apparently the official documentation says we must use the field 
serialPersistentFields
to explicitly describe the fields to be exported, however you seem to use
"getSerialPersistentFields" instead. Besides you suppress the check for 
the availability
of the field although it is quite sure it will not be there (I did not 
find it in the all source
code of classpath): this causes some huge NullPointerException problems.
The only solution is to change the name "getSerialPersistentFields" into 
"serialPersistentFields"
but I do not see the point to complicate things... :( (if someone can 
explain it to me)

For the moment, there are still some problems with kaffe's regression 
tests and trying to
reduce them...

Cheers,
Guilhem.


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

Re: question about serialization

[Tom Tromey]

> "Ingo" == Ingo Prötel <[EMAIL PROTECTED]> writes:

Ingo> would like to propose a modification to Toms fix. It looks to me as if
Ingo> all fields of a deserialized object are accessible as well as the
Ingo> private readObject-Method. Or does the VM reset the Accessible flag?

No, nothing resets the flag.

I assume you are doing this because your Class implementation caches
the Field and Method objects.  I don't think that is valid.  If we
call setAccessible on a Method, then even if we reset it we are
opening up a window where other unprivileged code could access that
Method.  This can only happen in the serialization code if Class
returns the same Method or Field object to other callers.

Tom


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

Re: bug fix for java.io.InputReaderStream.close andjava.util.zip.InflaterInputStream.close

[Brian Jones]

David P Grove <[EMAIL PROTECTED]> writes:

> Appended is a patch to avoid a NullPointerException if close is called 
> multiple times.  This matches the logic that is already in 
> java.io.BufferedReader.   Could someone please apply it?

Someone applied the java/io/InputStreamReader patch but did not use
synchronize on the java/util/zip/InflaterInputStream patch.  Not sure
why.

Brian
-- 
Brian Jones <[EMAIL PROTECTED]>


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

Re: question about serialization

[Ingo Prötel]

Hi,

would like to propose a modification to Toms fix. It looks to me as if 
all fields of a deserialized object are accessible as well as the 
private readObject-Method. Or does the VM reset the Accessible flag?

I think we need to reset the accessible flag after we are done with the 
field or method:

 private void callReadMethod (Object obj, ObjectStreamClass osc) throws 
IOException
 {
 ...
   boolean saved = setAccessible(m,true);
   m.invoke (obj, args);
   setAccessible(m,saved);
 ...
 }

 /**
  * Sets the accessible flag of theAccessible in a privileged action.
  * @param theAccessible
  * @param isAccessible
  * @return the previous value of theAccessible.isAccessible()
  */
 private static boolean setAccessible(final AccessibleObject 
theAccessible, boolean isAccessible){
 boolean oldValue = theAccessible.isAccessible();
   AccessController.doPrivileged(new PrivilegedAction()
 {
 public Object run()
   {
   theAccessible.setAccessible(true);
   return null;
   }
 });
   return oldValue;
 }

--ingo



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

Re: /classpath java/awt/font/OpenType.java ChangeLog

[Sascha Brawer]

Tom Tromey <[EMAIL PROTECTED]> wrote on Mon, 11 Aug 2003 10:48:23 -0600:

>>  classpath/java/awt/font: OpenType.java 
>>  Declare OpenType tags as 'public static final'.
>
>Please revert this patch.  Fields in an interface are implicitly
>public, static, and final; see JLS 9.3. Our coding standard is not to
>add the unnecessary modifiers.

I know about the implicit modifiers for interface fields, but I am a bit
surprised that omitting them would be our coding standard. Is it a good
idea to omit declarations that, while technically redundant, make the
code easier to understand?

But then, we all have other things to do than arguing about matters of
taste, so I've reverted the change.

-- Sascha

Sascha Brawer, [EMAIL PROTECTED], http://www.dandelis.ch/people/brawer/ 




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

Re: gnu.java.awt.font

[Sascha Brawer]

Brian Jones <[EMAIL PROTECTED]> wrote on Tue, 12 Aug 2003 09:06:01 -0400:

Sascha> I've put a new snapshot of a prospective gnu.java.awt.font
Sascha> package at the following address:
Sascha> http://www.dandelis.ch/development/fonts/#Implementation

>Is this something we should get imported into Classpath since you're
>no longer working on improving it or are you thinking of writing it on
>top of OpenGL?

We really should discuss how to do graphics in general; see the workshop
announcement in a separate mail. Therefore, I think it would be too early
to import my code into Classpath. Before importing it, we should find
some general interface to font engines, so that those who can use
FreeType or some other native engine are able to use that instead of my
(pure Java) implementation.

Since you mention it: OpenGL has actually very little to do with fonts.
Its potential role in 2D graphics is fast operations on polygons and
images. To draw text with OpenGL (or also with the X rendering
extension), one needs to render some glyphs into a raster image, pass the
image to the rendering engine, and draw rectangular sections of that
image. This is orthogonal to choosing, measuring and obtaining glyph
outlines, which is what my (or any other) font library does.

Best,

-- Sascha

Sascha Brawer, [EMAIL PROTECTED], http://www.dandelis.ch/people/brawer/ 




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

Workshop/BoF: Graphics in GNU Classpath

[Sascha Brawer]

===
Workshop/BoF: Graphics in GNU Classpath
===

Linux-Kongress, Saarbrücken, Germany
October 14th, 2003, 14:30 - 17:30 h


--
Background
--

Many existing Java(TM) applications depend on the Java2D(TM) API, a very
well-designed, powerful set of high-performance graphics routines. Most
applications use this graphics library indirectly through the Swing(TM)
toolkit, which is the most widely used API to write interactive
applications in the Java(TM) programming language.

It would be very desirable for GNU Classpath to support the Java2D(TM)
API. However, the current state of graphics support in GNU Classpath is
extremely limited. Since there currently exist several projects that want
to support Java graphics, it would be good to coordinate them.

Therefore, a workshop/developer's gathering/birds-of-a-feather session
will take place during Linux-Kongress 2003. Some Classpath developers
said they plan going to this event, which is why this location was chosen.


--
Purpose of the meeting
--

- To get an understanding of the requirements for supporting Java2D(TM)
on top of various graphics engines.

- To find a structure of the code that can support several target
platforms. For example, the requirements are rather different for remote
X11, local X11, OpenGL, IKVM.NET, Jaos/Oberon, embedded devices with
framebuffers, or pure Java operating systems. Ideally, it will be
possible to find a clean, modular structure that allows for most code to
be shared, while still supporting back-ends for various graphics subsystems.

- To identify the tricky parts, and to discuss techniques for
implementing them.


---
Who might be interested
---

- People who know about X11, the X Rendering Extension, OpenGL(TM), or
some other graphics API

- People who are familiar with the Java2D(TM) APIs

- Implementors of virtual machines

- Contributors to GNU Classpath

Of course, anyone else is equally welcome to join!


-
Talks
-

- Agile2D, an implementation of Java2D on top of OpenGL
  (Jean-Daniel Fekete)

If you would like to give a presentation during the workshop, please
contact Sascha Brawer ([EMAIL PROTECTED]).  It would be especially
helpful if someone was present who knows about RedHat's implementation of
Java2D on top of Xr/Cairo. But you are invited to speak about any
relevant topic.



-
Related links
-

It would be good if the attendands could get familiar with some of the
relevant APIs. Of course, knowledge about Java2D(TM) would be especially
important.

- Programmer's Guide to the Java2D(TM) API
  ftp://ftp.java.sun.com/docs/j2se/1.4/j2d-book.pdf (PDF),
  http://java.sun.com/j2se/1.4.2/docs/guide/2d/spec/j2d-bookTOC.html (HTML)

- The X Rendering Extension
  Design: http://keithp.com/~keithp/talks/usenix2001/
  Protocol: http://keithp.com/~keithp/render/protocol.html

- Xr/Cairo (client-side API that uses X Rendering if present)
  Description: http://cairographics.org/xr_ols2003/
  Implementation: http://www.cairographics.org/
  API: http://www.keithp.com/cgi-bin/cvsweb/cairo/src/cairo.h

- OpenGL(TM)
  Overviews: http://www.opengl.org/developers/documentation/overviews.html
  Specification:
  http://www.opengl.org/developers/documentation/version1_4/glspec14.pdf
  Agile2D (implements Java2D on top of OpenGL):
  http://www.lri.fr/~fekete/agile2d/

- GNU Classpath
  http://www.gnu.org/software/classpath/




Please feel free to forward this message to anyone who might be interested.

-- Sascha

Sascha Brawer, [EMAIL PROTECTED], http://www.dandelis.ch/people/brawer/





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

Re: Small ZipFile patch

[Tom Tromey]

> "Brian" == Brian Jones <[EMAIL PROTECTED]> writes:

>> Sounds like we need this in ClassLoader and in any other class that
>> performs security checks in its constructor.

Brian> This is still a TODO item, yes?

I fixed this in ClassLoader.  I haven't looked to see whether any
other classes have a security check in their constructor.  (Well, I
know that Window does, but I think it doesn't need this treatment,
since it won't throw a SecurityException.)

Tom


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

Re: gnu.java.awt.font

[Brian Jones]

Sascha Brawer <[EMAIL PROTECTED]> writes:

> Hi all,
> 
> I've put a new snapshot of a prospective gnu.java.awt.font package at the
> following address:
> 
>   http://www.dandelis.ch/development/fonts/#Implementation

Sascha,

Is this something we should get imported into Classpath since you're
no longer working on improving it or are you thinking of writing it on
top of OpenGL?

Brian
-- 
Brian Jones <[EMAIL PROTECTED]>


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

Re: /classpath java/awt/font/OpenType.java ChangeLog

[Tom Tromey]

> "Sascha" == Sascha Brawer <[EMAIL PROTECTED]> writes:

Sascha> I know about the implicit modifiers for interface fields, but
Sascha> I am a bit surprised that omitting them would be our coding
Sascha> standard. Is it a good idea to omit declarations that, while
Sascha> technically redundant, make the code easier to understand?

First, I didn't make this particular rule.  As I recall in libgcj we
did have all the redundant modifiers.

However, I think the rationale here is that even Sun suggests not
using these.

Well, ok, I could only find this style discouragement for modifiers
on methods.  See JLS 9.4.

Tom


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

Re: Developing VM

[Mark Wielaard]

Hi,

On Sun, 2003-08-10 at 15:32, Peter Werno wrote:
> we are developing a new Virtual Machine for Amiga OS
> (http://sourceforge.net/projects/jamiga) which will be bundled with the
> GNU classpath.

Nice. Hope you find GNU Classpath useful for bringing a VM to that
platform.

> Our VM is following a differnet approach and JNI has not been implemented
> yet. Moreover, we tend to implement a lot of the core functions/classes
> natively straight into the VM, as the older 68K-processors of the
> Amiga-Systems are not really up to speed with modern Intel or IBM-chips!

In principle GNU Classpath can be used by VMs that don't support JNI.
But JNI makes things a lot easier since for almost everything we supply
native JNI C based implementations. But we also try to setup everything
so that classes don't need explicit native methods. In principle every
class that needs native or VM support (or a particular system/VM
optimization) delegates to a package private final VMSomething class
that is VM dependent and that does the correct thing on that VM (so if
the VM supports JNI then in most cases it can use the default
vm/reference classes that use the supplied native JNI implementations.

But this support is not complete yet so we need developers of VMs that
don't support JNI to help us point out where we need to abstract away
from direct native methods. Welcome! You have just volunteered :)

> For this reason, it would be very useful, if we could get information on
> changes, especially where native method calls are involved.
> 
> Would this kind of information usually be broadcasted on this mailing
> list, or are there different channels that I should subscribe to?

There are two mailinglist: http://savannah.gnu.org/mail/?group=classpath
[EMAIL PROTECTED] and [EMAIL PROTECTED] The first one (this
mailinglist) is were all the technical discussion takes place, also
discussion related to VM interface changes (which should always be
listed in the NEWS file).
If you want to follow development closely then you also need to
subscribe to the second mailinglist which gets email whenever code in
CVS changes or the bug or patch tracker record changes.

Cheers,

Mark



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

Small patch: java/io/PrintStream.java

[Andrew Haley]

Andrew Haley writes:
 > 
 > 2003-08-07  Andrew Haley  <[EMAIL PROTECTED]>
 > 
 >  * java/io/PrintStream.java (print(String)): Don't crash on a null
 >  string.

This code has been superseded, so I won't commit it.

Andrew.


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

Re: Class loader and serialization

[Mark Wielaard]

Hi,

On Thu, 2003-08-14 at 16:04, Guilhem Lavaux wrote:
> Thanks to Mark I have found a compatible way to do what I want with the 
> SecurityManager.
> I am going to see if it works in real world now.

For an example of what I suggested see the way java.util.ResourceBundle
creates a SecurityManager to access the calling ClassLoader.

Note that the above example actually uses getClassContext() which is
inefficient. If we look again at the SecurityManger/VMSecurityManager
split it might be a good idea to give VMs the possibility of providing
efficient implementations of currentClassLoader(), currentLoadedClass(),
etc.

Cheers,

Mark

P.S. I am sometimes reachable on IRC on the irc.oftc.net server as 'mjw'
and/or on the #gcj channel or on the irc.gnu.org server on the #kaffe
channel. (Should we create a #classpath channel?)



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

Re: String question

[Tom Tromey]

> "Jeroen" == Jeroen Frijters <[EMAIL PROTECTED]> writes:

Jeroen> Would anyone mind if I made the
Jeroen> java.lang.String.CaseInsensitiveComparator inner class
Jeroen> non-private (i.e.  make it package accessible)?

I'm sure it would be fine.
But why do you need this?

Tom


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

Preparing for 0.06 release

[Mark Wielaard]

Hi all,

A little reminder. We want to release a new GNU Classpath snapshot
release (0.06) next Friday (August 15).

Things to do/decide before the release:

- What should really go in before the release?
  - There are still some open bugs:
http://savannah.gnu.org/bugs/?group=classpath
Not all are analyzed yet, but although it would be nice to fix/close
some of these there don't seem to be any showstoppers.
  - There is still one open patch for SecurityManager/VMSecurityManager
http://savannah.gnu.org/patch/?func=detailpatch&patch_id=1031&group_id=85
Don't know how urgent this is. I would like to see a real design how
to handle this and related methods in a VM independent way, but that
is probably not 0.06 material. (JRVM hackers, how important is it
that this goes in? We can always add a hack for 0.06 if that really
helps you out.)
  - Is there any progress on the Thread/VMThread split?
Would be nice to get that in, but it will require work to make it
work with the different VMs so it better go in quickly
(today/tomorrow).
  - Is something else important missing? Please email me/the list with
suggestions.

- Creating release tar balls.
  I am playing with this now. It seems that this is not to difficult
  (Just type: make dist). Have to check to things:
  - How to get gjdoc installed and generate correct api documentation.
  - Why my make install does not create any plain .so files
(The .0, .0.0.0 and .la do get installed, but I have to symlink the
 .so to the .0.0.0 files by hand...)

- Update the NEWS file.
  - It contains all VM interface changes which is good.
  - It should contain all important additions/bug fixes made for this
release. This can be done by going through the bug/patch database
and the ChangeLog file. (Any volunteers?)

- Bumping the version number and tag the CVS treee (DON'T FORGET!)
  - Will do this just before the final release.

- Upload the release to alpha.gnu.org
  - Some yoyo thought it would be funny to crack the main GNU file
server. So they had to disable all accounts, reinstall the whole
machine and clean everything up :{ Hopefully this will be done
before Friday, otherwise we have to host the tar ball somewhere else
for the moment.

- Create release notes and post them to relevant forums.
  - Should be easy by taking the news items regarding older releases
 and combine them
with the NEWS items.

Cheers,

Mark



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

Re: Preparing for 0.06 release

[Stephen Crawley]

> I believe the kissme VM just uses the vm/reference version of Thread.

This is correct.  

If the classpath implementation of  vm/reference/java/lang/Thread.java
is redone as java/lang/Thread.java + vm/reference/java/lang/VMThread.java,
kissme should be changed to reflect this.  This will entail changes to
the native methods, depending on how the new VMThread.java declares them.

A short term alternative (hack) would be to simply copy the existing 
classpath vm/reference/java/lang/Thread.java into the kissme tree so 
that kissme continues to use the old Thread.java code.

I'd prefer to deal with this AFTER Classpath 0.06.

-- Steve


-- Steve



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

Re: Class loader and serialization

[Guilhem Lavaux]

Hi,

Thanks to Mark I have found a compatible way to do what I want with the 
SecurityManager.
I am going to see if it works in real world now.

Thanks Mark ! ;)

Cheers,
Guilhem.


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

Re: java.lang.Class.newInstance() construction caching

[Brian Jones]

"Jeroen Frijters" <[EMAIL PROTECTED]> writes:

> Oops. Forget to attach the file.

The patch to java/lang/Class is in CVS, couldn't tell from ChangeLog
when though.  I'm cleaning up my inbox, can you tell?

Brian
-- 
Brian Jones <[EMAIL PROTECTED]>


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

Re: Method.equals() question

[Tom Tromey]

> "Brian" == Brian Jones <[EMAIL PROTECTED]> writes:

Brian> These have not been applied yet, we should do so before Friday.
Brian> Does this look okay to everyone?

Yes, except for one little nit:

>> -  // Implementation note:
>> -  // The following is a correct but possibly slow implementation.
>> -  //
>> -  // This class has a private field 'slot' that could be used by
>> -  // the VM implementation to "link" a particular method to a Class.
>> -  // In that case equals could be simply implemented as:
>> -  //
>> -  // if (o instanceof Method)
>> -  // {
>> -  //Method m = (Method)o;
>> -  //return m.declaringClass == this.declaringClass
>> -  //   && m.slot == this.slot;
>> -  // }
>> -  // return false;

This part of the comment is still correct and could be left in place.
(This is actually what libgcj does.)

Whether you want to leave it in place, I don't know.  I see it is a
nice, but optional, hint to implementors.

Tom


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

Re: Patches need applying ...

[Brian Jones]

Stephen Crawley <[EMAIL PROTECTED]> writes:

> Could some kind soul please apply the BigDecimal.setScale patch I 
> just submitted on behalf of Saket and Jerry?

Mark did this back in mid-July.

Brian
-- 
Brian Jones <[EMAIL PROTECTED]>


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

Re: Jaos JVM

[Mark Wielaard]

Hi Patrik,

On Sun, 2003-08-03 at 16:21, Patrik Reali wrote:
> The Jaos VM is a JVM using GNU Classpath implemented on top of the
> Aos/Bluebottle kernel [1]. This kernel offers many useful features like
> garbage collected memory management, dynamic module loading, and
> object-oriented model. This makes the implementation of a JVM particularly
> attractive and simple.

Thanks for the update and the nice description. It is really good to
know people find such innovative uses for GNU Classpath. I have added a
link to Jaos from the projects list on our homepage.

Cheers,

Mark



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

Re: Preparing for 0.06 release

[Patrik Reali]

> > A side question (that's important for deciding whether to include it in
> > the 0.06 release), do any VMs use the unmodified reference Thread class?
>
> I believe the kissme VM just uses the vm/reference version of Thread.

Jaos uses vm/reference/java/lang/Thread as is.

But this shouldn't stop you from improving the design by moving the native
stuff into a VMThread class. If a native method is just rewritten to call a
VM* method, then Jaos implementation will still work, because the linker
patches the native method implementation directly into the method table and
thus ignores the call to the VM* class.

-Patrik



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

Re: /classpath java/awt/font/OpenType.java ChangeLog

[Tom Tromey]

> "Sascha" == Sascha Brawer <[EMAIL PROTECTED]> writes:

Sascha> classpath/java/awt/font: OpenType.java 
Sascha> Declare OpenType tags as 'public static final'.

Please revert this patch.  Fields in an interface are implicitly
public, static, and final; see JLS 9.3.  Our coding standard is not to
add the unnecessary modifiers.

Tom


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

Re: Hello

[Mark Wielaard]

Hi Ingo,

On Mon, 2003-08-11 at 16:36, Ingo Prötel wrote:
> I just want to introduce myself. I have started to work for aicas GmbH .
> Currently I work on bugfixes in our VM and Classpath.
> 
> So in future you will see some bugfixes from me. I test my fixes against
> kissme, so if you have trouble with any other VM please let me know.
> 
> I'm looking forward to work with you.

You are very welcome! And thanks for testing out you patches against
another VM. That is very appreciated! Good to see that your patches are
all over the place.

There are a couple of nitpicks though. This seems to be getting a
tradition with new people joining the project... Please don't take them
personally. Nobody can come into a new project and know everything there
is to know. And even experienced hackers make mistakes from time to
time. Next time I will pick on Brian or Tom just to show that I also
dare to correct senior hackers :)

+2003-08-11 Ingo Proetel <[EMAIL PROTECTED]>
+
+   * java/security/Security.java: moved initialization code of providers
+   from static initializer into a method to allow lazy evaluation of
+   this code. This permits faster startup and even automatic removal of
+   this code if it is not needed.

ChangeLog entries should just describe the facts and be pretty dry and
factual. Just mention the method/variable that got changed, created or
deleted. The why should be in the actual code. Look at the other
ChangeLog entries for examples. A good description is at:
http://www.gnu.org/software/guile/changelogs/guile-changelogs_toc.html

So this ChangeLog entry could be written as:

* java/security/Security.java (providers): Removed field,
replace by method.
(providers_lazy): New static field.
(static): Removed and replaced by new providers() method.
(providers): New static method, replaces static block and use of
static field of the same name.

The ChangeLog entry should be used as the commit message and the
ChangeLog file should be committed together with the files that changed.
(As you did in your last couple of commits. Thanks)

+   /* Removed this (more comprehensive) error string to avoid the need 
for a 
+* static variable or allocation of a buffer for this message in this 
(unlikely) 
+* error case. --Fridi. 
+*
+* sprintf(errstr,"JCL: Failed to throw exception %s with message %s: 
could not find exception class.", className, errMsg); 
+*/

Just remove old, unused, commented out code. It is available in the CVS
history. No need to clutter up the source with dead code.

There is also no need to add initials or other author markers to
comments. Comments should be valid whoever wrote them. And if you want
to find out who was responsible for a certain line of code or comment
there is alway cvs annotate.

+   // ???

That is not really a useful comment.

+// NYI: ignore check until Method.getExceptionTypes is implemented 
+// Class[] exceptions = meths[i].getExceptionTypes();
+// int index = 0;
+// for(;index < exceptions.length; index++){
+// if(exceptions[index].equals(RemoteException.class)){
+// break;
+// }
+// }
+// if (index < exceptions.length) {
+   rmeths.add(meths[i]);
+// } else {
+// logError("Method "+meths[i]+" does not throw a 
java.rmi.RemoteException");
+// }
[...]
-   out.print("throws ");
+// NYI hard-code java.rmi.RemoteException until Method.getExceptionTypes is 
implemented
+// out.print("throws ");
+   out.print("throws java.rmi.RemoteException");

This seems to be specific to VMs that don't implement
Method.getExceptionTypes(). Are you sure it is applicable in general?

Please revert this part.

Cheers,

Mark



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

Re: classpath java/util/TimeZone.java java/util/Loc...

[Brian Jones]

Tom Tromey <[EMAIL PROTECTED]> writes:

> > "Ingo" == Ingo Proetel <[EMAIL PROTECTED]> writes:
> 
> Hi.
> 
> Ingo> java/util  : TimeZone.java Locale.java 
> 
> Please follow the existing coding standards.  I looked at this briefly
> and there were a couple formatting bugs.  For instance, in Classpath
> an opening brace `{' goes on its own line.

Any word on jalopy understanding our conventions?

Brian
-- 
Brian Jones <[EMAIL PROTECTED]>


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

Class loader and serialization

[Guilhem Lavaux]

Hi,

it seems there is a misunderstanding problem between kaffe's class loader
mechanism and classpath's serialization. Here is the current state:
* ObjectInputStream builds class decriptors from input stream, or if it
is not described build them from classes directly. To do so it resolves
classes using Class.forName(name)
* It needs to build each inner fields: it it is a "natural" type (int, 
...) it is
constructed directly but if it is an object it uses
gnu.java.lang.reflect.TypeSignature.getClassForEncoding to build it.
This method calls Class.forName(name) to get the corresponding class.

The second step is the most problematic (the first may also cause problems
but they are marginal and if we can solve the second it will also be 
solved):
gnu.java.lang.reflect.TypeSignature has been loaded using the native 
class loader
(or more precisely the bootstrap class loader). But this class loader 
does not have
access to locally defined classes and this causes the regression test 
Alias.java
to halt (as pointed out by Dalibor ;) ). Kaffe's former implementation seems
to have solved this problem by resolving classes using the first non-null
class loader in the calling stack. Apparently, JDK use a similar mechanism
because its serialization code is capable of not taking ObjectInputStream's
class loader (which is null) but Alias's class loader (which sun's app 
class loader).

Would it be possible to add in classpath this sort of mechanism ? I mean 
dumping
the calling class stack so we can fetch the right class loader.

Cheers,
Guilhem.


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

Re: configure ignores --disable-gtktest ?

[Ingo Prötel]

In the meantime I have the complete gtk-packe set that is needed. So I 
don't use this option any longer.

I just tested it anyway and it seems to work properly.

Thanks
ingo
Brian Jones wrote:
Ingo Prötel <[EMAIL PROTECTED]> writes:


Hi,

I try to run configure without running the gtk test program by using
the --disable-gtktest option.
Configure seems to ignore this option and still runs the test. I have
attached parts of my config.log file.
What can I do to compile classpath so that I can use it with the kissme-vm?


Ingo, 

Did you figure out a solution?  We might need to fix configure?

Thanks,
Brian


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

Re: Preparing for 0.06 release

[Brian Jones]

Ito Kazumitsu <[EMAIL PROTECTED]> writes:

> Hi,
> 
> In message "Preparing for 0.06 release"
> on 03/08/10, Mark Wielaard <[EMAIL PROTECTED]> writes:
> 
> >   - There are still some open bugs:
> > http://savannah.gnu.org/bugs/?group=classpath
> 
> I submitted two new bug reports, which were originally
> submitted to this mailing list.

Thanks Ito, I hadn't forgot about these.

Brian
-- 
Brian Jones <[EMAIL PROTECTED]>


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

Re: Preparing for 0.06 release

[Ito Kazumitsu]

Hi,

In message "Preparing for 0.06 release"
on 03/08/10, Mark Wielaard <[EMAIL PROTECTED]> writes:

>   - There are still some open bugs:
> http://savannah.gnu.org/bugs/?group=classpath

I submitted two new bug reports, which were originally
submitted to this mailing list.


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

Re: classpath java/util/TimeZone.java java/util/Loc...

[Tom Tromey]

> "Brian" == Brian Jones <[EMAIL PROTECTED]> writes:

Brian> Any word on jalopy understanding our conventions?

Nope, I haven't heard back :-(

Tom


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

Re: Preparing for 0.06 release

[Brian Jones]

Mark Wielaard <[EMAIL PROTECTED]> writes:

> Hi,
> 
> There is (in a couple of minutes) a first test tar ball up at:
> http://www.klomp.org/mark/classpath/classpath-0.06-test1.tar.gz (5.4M)
> And I would appreciate it if someone could try it out.
> But there are still some things todo before 0.06.
> 
> - More bugs...
> 
> 3207  API installation fails, argument list too long
> Postponed?

Would 'find ... | cpio' fix the problem since the args are piped into
cpio instead of expanded on the command line...?

> - Import new external libraries
>   - GNU-JAXP

Will do tonight after dinner.

> 
> - make dist.
> Now creates a nice tar ball that can then be used to just
> ./configure && make && make install.
> 
> - make distcheck.
> Would be nice to be distcheck clean, but currently we have lots of files
> left after a make clean (mainly lib/*/ .class files).

It has never worked, worked almost completely with 0.05.  Does 'make
DESTDIR=/tmp/foo install' still work?

> - gjdoc
> Played with it a bit and almost have it working, but gjdoc from CVS
> doesn't build out of the box for me. I have to add the GNUJAXP sources,
> play with resource paths a bit. Now still have to add a xml.transformer.
> The Debian package from unstable is broken.
> 
> - .so files
> Make install doesn't create .so files for me. For example I now have in
>   /usr/share/classpath/lib/classpath:
>   libjavanet -> libjavanet.0.0.0
>   libjavanet.0 -> libjavanet.0.0.0
>   libjavanet.0.0.0
>   libjavanet.la
> No .so files.
> Linking libjavanet.so -> libjavanet.0.0.0 by hand seems to work.

Is this a libtool problem or auto*?  I'll give it a try later.  I
think it works for me though.

automake 1.6.3
autoconf 2.53
libtool 1.4.2

Brian
-- 
Brian Jones <[EMAIL PROTECTED]>


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

Re: Method.equals() question

[Brian Jones]

These have not been applied yet, we should do so before Friday.  Does
this look okay to everyone?

Brian

Archie Cobbs <[EMAIL PROTECTED]> writes:

> Archie Cobbs wrote:
> > The practical upshot of this is that the equals() methods that currently
> > exist in Classpath for Field and Constructor need to be fixed. But the
> > fixes could use "obj1.getDeclaringClass() == obj2.getDeclaringClass()"
> > as part of the test.
> > 
> > Method also needs to be fixed, but for a different reason (it doesn't
> > compare the return types as it should (referring to Classpath 0.05)).
> 
> Below are my patches (against 0.05) for fixing these equals() methods.
> 
> Cheers,
> -Archie
> 
> __
> Archie Cobbs * Precision I/O  * http://www.precisionio.com
> 
> diff -ur 
> /home/archie/classpath/classpath-0.05/vm/reference/java/lang/reflect/Constructor.java
>  ./Constructor.java
> --- 
> /home/archie/classpath/classpath-0.05/vm/reference/java/lang/reflect/Constructor.java
>  Fri Oct 25 16:02:26 2002
> +++ ./Constructor.javaMon Mar  3 12:51:12 2003
> @@ -38,6 +38,8 @@
>  
>  package java.lang.reflect;
>  
> +import java.util.Arrays;
> +
>  /**
>   * The Constructor class represents a constructor of a class. It also allows
>   * dynamic creation of an object, via reflection. Invocation on Constructor
> @@ -160,7 +141,14 @@
> */
>public boolean equals(Object o)
>{
> -return this == o;
> +if (!(o instanceof Constructor))
> +  return false;
> +Constructor that = (Constructor)o; 
> +if (this.getDeclaringClass() != that.getDeclaringClass())
> +  return false;
> +if (!Arrays.equals(this.getParameterTypes(), that.getParameterTypes()))
> +  return false;
> +return true;
>}
>  
>/**
> diff -ur 
> /home/archie/classpath/classpath-0.05/vm/reference/java/lang/reflect/Field.java 
> ./Field.java
> --- /home/archie/classpath/classpath-0.05/vm/reference/java/lang/reflect/Field.java  
>  Fri Oct 25 16:02:26 2002
> +++ ./Field.java  Mon Mar  3 12:47:44 2003
> @@ -135,7 +125,16 @@
> */
>public boolean equals(Object o)
>{
> -return this == o;
> +if (!(o instanceof Field))
> +  return false;
> +Field that = (Field)o; 
> +if (this.getDeclaringClass() != that.getDeclaringClass())
> +  return false;
> +if (!this.getName().equals(that.getName()))
> +  return false;
> +if (this.getType() != that.getType())
> +  return false;
> +return true;
>}
>  
>/**
> diff -ur 
> /home/archie/classpath/classpath-0.05/vm/reference/java/lang/reflect/Method.java 
> ./Method.java
> --- /home/archie/classpath/classpath-0.05/vm/reference/java/lang/reflect/Method.java 
>  Wed Dec 18 02:28:29 2002
> +++ ./Method.java Mon Mar  3 12:52:48 2003
> @@ -38,6 +38,8 @@
>  
>  package java.lang.reflect;
>  
> +import java.util.Arrays;
> +
>  /**
>   * The Method class represents a member method of a class. It also allows
>   * dynamic invocation, via reflection. This works for both static and
> @@ -144,57 +136,25 @@
>/**
> * Compare two objects to see if they are semantically equivalent.
> * Two Methods are semantically equivalent if they have the same declaring
> -   * class, name, and parameter list.  This ignores different exception
> -   * clauses or return types.
> +   * class, name, parameter list, and return type.
> *
> * @param o the object to compare to
> * @return true if they are equal; false if not
> */
>public boolean equals(Object o)
>{
> -  // Implementation note:
> -  // The following is a correct but possibly slow implementation.
> -  //
> -  // This class has a private field 'slot' that could be used by
> -  // the VM implementation to "link" a particular method to a Class.
> -  // In that case equals could be simply implemented as:
> -  //
> -  // if (o instanceof Method)
> -  // {
> -  //Method m = (Method)o;
> -  //return m.declaringClass == this.declaringClass
> -  //   && m.slot == this.slot;
> -  // }
> -  // return false;
> -  //
> -  // If a VM uses the Method class as their native/internal representation
> -  // then just using the following would be optimal:
> -  //
> -  // return this == o;
> -  //
> -  if (o == null)
> -return false;
> -
> -  if (!(o instanceof Method))
> -return false;
> -
> -  Method m = (Method)o;
> -  if(!name.equals(m.name))
> -   return false;
> -
> -  if(declaringClass != m.declaringClass)
> -   return false;
> -
> -  Class[] params1 = getParameterTypes();
> -  Class[] params2 = m.getParameterTypes();
> -  if(params1.length != params2.length)
> -   return false;
> -
> -  for(int i = 0; i < params1.length; i++)
> -   if(params1[i] != params2[i])
> -   return false;
> -
> -  return true;
> +if (!(o in

Re: More fixes

[Brian Jones]

"Jeroen Frijters" <[EMAIL PROTECTED]> writes:

> Hi,
> 
> More JBoss related fixes.

You applied these yourself now, thanks.  :)

Brian
-- 
Brian Jones <[EMAIL PROTECTED]>


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

Hello

[Ingo Prötel]

Hi all,

I just want to introduce myself. I have started to work for aicas GmbH .
Currently I work on bugfixes in our VM and Classpath.
So in future you will see some bugfixes from me. I test my fixes against
kissme, so if you have trouble with any other VM please let me know.
I'm looking forward to work with you.

--ingo



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

Re: X Rendering and GNU Classpath

[graydon hoare]

Sascha Brawer <[EMAIL PROTECTED]> writes:

> It seems there are several people with that goal, and that some
> coordination would be good so we can share at least some of the effort.
> Therefore, I guess I'll try to arrange a discussion session during
> LinuxKongress in Saarbrücken/Germany. Jean-Daniel, are you planning to go
> there, by chance?
> 
> Graydon, where are you located? Is there a chance that either you or
> someone else might be present who is familiar with what you are doing on
> top of Cairo/Xr?

I am located in Canada, and it will be somewhat of a trick for me to
get to Saarbrücken. I'll ask my manager, but I can't make any
promises.

I have had a look over the agile2d material, and while I was quite
enthusiastic looking at screenshots and playing with the demo
material, after reading the code I am hesitant to endorse this as a
solution for classpath or gcj. it seems quite specifically an
experiment in java2d *acceleration*, rather than from-scratch
implementation.

In particular, it relies on the existing sun java2d to perform much of
the "tricky" work, such as region and scanline conversion of fonts,
strokes and shapes; glyph selection, shaping and layout. moreover it
does not appear to support porter/duff compositing rules or splines,
nor subpixel positioning of glyphs (the latter is a common problem
when using texture mosaics for hardware-assisted glyphs).

in general terms -- and I don't mean to start a flamewar or anything
-- what it seems to do is (elegantly) copy pixels, matrices and
vectors back and forth between sun's java2d and the video card's
texture buffers, matrix stack and display lists, keeping the requisite
graphics states in sync and accelerating those operations it can with
hardware resources. the result is a good speedup, but it's not
particularly independent of sun's code. 

(a broader concern I have with "hardware accelerated" drawing is that
 there is sometimes an uncontrollable loss of precision and increase
 in ambiguous or unspecified behavior when using consumer graphics
 hardware. for example -- though you'll probably have a hard time
 reproducing this -- my cheapo OGL video card appears to make some
 creative decisions about texel coordinates, such that depending on
 the position of a window on the screen, glyphs in the agile2d demo
 are selected from one pixel further to the left or right than they
 should be, making small (< 24pt) text read like garbage. this is less
 significant with applications like games -- for which the hardware is
 designed -- or for large block-pixel movement commands, but can be a
 problem when attempting to do precise subpixel operations, for
 example rendering and placing glyphs.)

-graydon




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

ChangeLog entries

[Mark Wielaard]

Hi,

I would really like everybody to follow the ChangeLog entry guidelines
given in:
http://www.gnu.org/software/guile/changelogs/guile-changelogs_3.html

I will try to update out hacking document with some of the style guides
later. But maybe a couple of examples are more clear. So here is how I
would like to see some of the ChangeLog entries of today:

> * java/awt/font/OpenType.java: Remove 'public static final'
> from OpenType tags, reverting the change of 2003-08-11.  See
> Classpath discussion list of 2003-08-11.

This should just state:

* java/awt/font/OpenType.java: Remove 'public static final' from
all member fields.

The explanation why should either be in the code or (more appropriate in
this case be added to our hacking document.

> * java/io/ObjectOutputStream.java : allow putFields be called more than
> once

Don't make lines longer then 80 characters. And this explains the effect
of the change, which should be in a comment in the code if appropriate.
The ChangeLog should just explain what changed:

* java/io/ObjectOutputStream.java (putFields): Don't call
markFieldsWritten(). Only create new PutField when
currentPutField is null.
(writeFields): Call markFieldsWritten().

Also this patch included more then just the above. It also cleaned up
some exceptions. Which is nice, but should probably be a separate patch
and the change should be documented in the ChangeLog.

(Sidenote. Since Throwables can now be chained it is a good idea to use
Throwable.setCause() and not just add the String representation of a
exception to another exception.)

Hope these examples help. And I do appreciate the fact that writing
ChangeLog entries, using a coding style that is not "your own" and the
CVS, patch and diff tools do take some time to getting used to. So don't
feel like you have to do it perfect right away or that contributions
aren't welcome if they aren't 'perfect'. We all learn by doing and
interacting with each other. And over time I might actually learn to be
a bit less uptight maintainer :)

One more thing. I really want to have a pretty open check-in policy. But
this means that you should be extra careful if you check something in.
If at all in doubt or if you think that something might need extra
explaining since it is not completely obvious please make a little
announcement about the change on the main classpath mailinglist. And if
you do commit something without discussing it first and another GNU
Classpath hackers asks for extra explanation or suggests to revert a
certain commit then please reply to the request by explaining why
something should be so or if you agree to revert it. (Just reverting
immediately is OK without discussion, but then please don't mix it with
other changes.)

All the above is really meant to make sure that GNU Classpath will be
maintainable in the long run and to give all the projects that are now
using GNU Classpath an accurate view of the changes we make to the code
and to see what changed when.

If you think that the above "project rules" are impractical or will
hinder contributions please contact me. I am happy to do code cleanups
and/or write ChangeLog entries for submissions (although that can mean
that your contribution takes a bit longer to get into the main tree).
And we can always setup a classpath-patches mailinglist to really
discuss and/or approve of each change before it gets committed, but I
think that will add to much bureaucracy at the moment.

Cheers,

Mark



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

Re: classpath java/util/TimeZone.java java/util/Loc...

[Tom Tromey]

> "Ingo" == Ingo Proetel <[EMAIL PROTECTED]> writes:

Hi.

Ingo>   java/util  : TimeZone.java Locale.java 

Please follow the existing coding standards.  I looked at this briefly
and there were a couple formatting bugs.  For instance, in Classpath
an opening brace `{' goes on its own line.

Tom


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

Re: Preparing for 0.06 release

[Brian Jones]

Brian Jones <[EMAIL PROTECTED]> writes:

> > - Import new external libraries
> >   - GNU-JAXP

Done, but someone concerned that I'm not seeing 'configure' in the
jaxp directory.  No difference otherwise between initial import and
this import.

Brian
-- 
Brian Jones <[EMAIL PROTECTED]>


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

Re: Developing VM

[Mark Wielaard]

Hi,

On Sun, 2003-08-10 at 20:29, Peter Werno wrote:
>
> From the top of my head ... there is this "TimeZone" - class in the
> java.util - package which defines a "getDefaultTimeZoneId" - method. Would
> it make sense to redirect this to - say - the java.lang.VMSystem - class?
> (The currentTimeMillis is defined in "System" too, so it's not too far off
> :-) )

That is indeed one of the places that needs to be abstracted away. Maybe
we could even just let the VM set some System property
(gnu.classpath.vm.default-timezone) to indicate this. But since the 0.06
release is coming soon it might be better to move such a decision to
next week after the release.

Cheers,

Mark



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

Re: Developing VM

[Peter Werno]

Hello Mark,

> Hi,
>
> On Sun, 2003-08-10 at 15:32, Peter Werno wrote:
>> we are developing a new Virtual Machine for Amiga OS
>> (http://sourceforge.net/projects/jamiga) which will be bundled with
>> the GNU classpath.
>
> Nice. Hope you find GNU Classpath useful for bringing a VM to that
> platform.
>

Yes, indeed. We tried with Sun's rt.jar first, but their documentation
...uhm... well ...
plus they were never answering any of our requests (e.g. wether or not we
could include the rt.jar with our vm). Once we moved to GNU classpath, it
took us only 2-3 days to "replace" everything and it now runs much
smoother :-)

>> Our VM is following a differnet approach and JNI has not been
>> implemented yet. Moreover, we tend to implement a lot of the core
>> functions/classes natively straight into the VM, as the older
>> 68K-processors of the Amiga-Systems are not really up to speed with
>> modern Intel or IBM-chips!
>
> In principle GNU Classpath can be used by VMs that don't support JNI.
> But JNI makes things a lot easier since for almost everything we supply
> native JNI C based implementations. But we also try to setup everything
> so that classes don't need explicit native methods. In principle every
> class that needs native or VM support (or a particular system/VM
> optimization) delegates to a package private final VMSomething class
> that is VM dependent and that does the correct thing on that VM (so if
> the VM supports JNI then in most cases it can use the default
> vm/reference classes that use the supplied native JNI implementations.
>
> But this support is not complete yet so we need developers of VMs that
> don't support JNI to help us point out where we need to abstract away
> from direct native methods. Welcome! You have just volunteered :)
>

I will help wherever I can :-)
>From the top of my head ... there is this "TimeZone" - class in the
java.util - package which defines a "getDefaultTimeZoneId" - method. Would
it make sense to redirect this to - say - the java.lang.VMSystem - class?
(The currentTimeMillis is defined in "System" too, so it's not too far off
:-) )

>> For this reason, it would be very useful, if we could get information
>> on changes, especially where native method calls are involved.
>>
>> Would this kind of information usually be broadcasted on this mailing
>> list, or are there different channels that I should subscribe to?
>
> There are two mailinglist: http://savannah.gnu.org/mail/?group=classpath
> [EMAIL PROTECTED] and [EMAIL PROTECTED] The first one (this
> mailinglist) is were all the technical discussion takes place, also
> discussion related to VM interface changes (which should always be
> listed in the NEWS file).
> If you want to follow development closely then you also need to
> subscribe to the second mailinglist which gets email whenever code in
> CVS changes or the bug or patch tracker record changes.
>
> Cheers,
>
> Mark

I will check that out! Thank you very much,

Peter Werno




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

Re: Method.equals() question

[Brian Jones]

Tom Tromey <[EMAIL PROTECTED]> writes:

> > "Brian" == Brian Jones <[EMAIL PROTECTED]> writes:
> 
> Brian> These have not been applied yet, we should do so before Friday.
> Brian> Does this look okay to everyone?
> 
> Yes, except for one little nit:
> 
> >> -  // Implementation note:
> >> -  // The following is a correct but possibly slow implementation.
> >> -  //
> >> -  // This class has a private field 'slot' that could be used by
> >> -  // the VM implementation to "link" a particular method to a Class.
> >> -  // In that case equals could be simply implemented as:
> >> -  //
> >> -  // if (o instanceof Method)
> >> -  // {
> >> -  //Method m = (Method)o;
> >> -  //return m.declaringClass == this.declaringClass
> >> -  //   && m.slot == this.slot;
> >> -  // }
> >> -  // return false;
> 
> This part of the comment is still correct and could be left in place.
> (This is actually what libgcj does.)
> 
> Whether you want to leave it in place, I don't know.  I see it is a
> nice, but optional, hint to implementors.

Left it in place.  Checking in now.

Brian
-- 
Brian Jones <[EMAIL PROTECTED]>


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

Re: Developing VM

[Brian Jones]

Peter Werno <[EMAIL PROTECTED]> writes:

> Hello everybody,
> 
> we are developing a new Virtual Machine for Amiga OS
> (http://sourceforge.net/projects/jamiga) which will be bundled with the
> GNU classpath.
> 
> Our VM is following a differnet approach and JNI has not been implemented
> yet. Moreover, we tend to implement a lot of the core functions/classes
> natively straight into the VM, as the older 68K-processors of the
> Amiga-Systems are not really up to speed with modern Intel or IBM-chips!
> 
> For this reason, it would be very useful, if we could get information on
> changes, especially where native method calls are involved.
> 
> Would this kind of information usually be broadcasted on this mailing
> list, or are there different channels that I should subscribe to?

Generally we put in NEWS information concerning a change to the VM
interface.  However the information you want is more detailed,
relating to all native method changes.  You may wish to subscribe to
the commit mailing list and simply monitor commits for anything that
seems pertinent.

Brian
-- 
Brian Jones <[EMAIL PROTECTED]>


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

Developing VM

[Peter Werno]

Hello everybody,

we are developing a new Virtual Machine for Amiga OS
(http://sourceforge.net/projects/jamiga) which will be bundled with the
GNU classpath.

Our VM is following a differnet approach and JNI has not been implemented
yet. Moreover, we tend to implement a lot of the core functions/classes
natively straight into the VM, as the older 68K-processors of the
Amiga-Systems are not really up to speed with modern Intel or IBM-chips!

For this reason, it would be very useful, if we could get information on
changes, especially where native method calls are involved.

Would this kind of information usually be broadcasted on this mailing
list, or are there different channels that I should subscribe to?

Many thanks,

Peter Werno







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

RE: String question

[Jeroen Frijters]

Tom Tromey wrote:
> > "Jeroen" == Jeroen Frijters <[EMAIL PROTECTED]> writes:
> 
> Jeroen> Would anyone mind if I made the
> Jeroen> java.lang.String.CaseInsensitiveComparator inner class
> Jeroen> non-private (i.e.  make it package accessible)?
> 
> I'm sure it would be fine.
> But why do you need this?

It's a complicated scenario and I'm not sure I'm happy with it. I'll try
to explain:

IKVM.NET doesn't use java.lang.String, because it uses the String class
from the underlying platform (.NET). However, to build GNU Classpath
(using a regular Java compiler, I use Jikes) I have to have a String
class, so it makes sense to use java/lang/String.java from Classpath for
this. Now, obviously, the .NET String doesn't provide all the methods
that java.lang.String does, so I have a package private helper class
java.lang.StringHelper that contains static methods that implement all
the missing String methods. It also contains the static field
CASE_INSENSITIVE_ORDER, and this is intialized with an instance of
java.lang.String.CaseInsensitiveComparator, because it is private I
cannot directly instantiate it from within my Java StringHelper class, I
have to use a "native" method. It would be cleaner if I could just
instantiate it from within my StringHelper code.

An alternative would be to provide my own implementation of a
java.lang.String$CaseInsensitiveComparator class and pretend it is an
inner class of java.lang.String, but this has the downside that it
complicates my build process (I have to ignore the Classpath
String$CaseInsensitiveComparator.class) and I have to duplicate the
(admittedly small) source code.

Regards,
Jeroen


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

Serialization

[Guilhem Lavaux]

Hi,

I nearly managed to get Classpath's serialization up to kaffe's level 
and at the
same time keeping the advantage of it. However, it is "nearly". As I said to
Mark Wielaard, kaffe's regression tests TestSerialVersions.Test0007, 
Test0009,
Test0010, Test0011, Test0013 fails; but also TestSerialFields.Test0010 and
Test0015. These tests are problematic because it seems the field 
serialPersistentFields
has an effect on the deserialization. The specification is not really 
clear for that
point although all documentation I came across says 
serialPersistentFields is normally only used
for serialization. I checked JDK: except for one test, its output is the 
same
as the expected one (which means kaffe's previous implementation was right
except for one test).

What is your opinion on that ? The spec of serialization says:
"By using |serialPersistentFields| to define the Serializable fields for 
a class,
there no longer is a limitation that a serializable field must be a 
field within
the current definition of the |Serializable| class. The |writeObject| 
and |readObject|
methods of the |Serializable| class can map the current implementation 
of the
class to the serializable fields of the class using the interface that 
is described
in Section 1.7 "Accessing Serializable Fields of a Class
.”
Therefore, the fields for a |Serializable| class can change in a later 
release, as
long as it maintains the mapping back to its Serializable fields that 
must remain
compatible across release boundaries."

However I cam across an RMI's documentation which says 
serialPersistentFields should
only be used for writing objects and not reading them.

So ?

Cheers,
Guilhem.


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

Re: Serialization

[Brian Jones]

Guilhem Lavaux <[EMAIL PROTECTED]> writes:

> Hi,
> 
> I nearly managed to get Classpath's serialization up to kaffe's
> level and at the same time keeping the advantage of it. However, it
> is "nearly".
> 
> However I cam across an RMI's documentation which says
> serialPersistentFields should only be used for writing objects and
> not reading them.

It's kind of weird, as I recall initially people were supposed to
support older versions of a serialized object by checking the
serialVersionUID and if/else if/etc. the read/write object code.  This
seems to say another method is to always use the older serialized form
and translate to/from it using serialPersistentFields, the advantage
being a newer version could be used by an older version.

I intend to work on verifying serial compatibility with JDK 1.1
through 1.4 (maybe 1.5 beta) in the next couple of months, but I maybe
should hold off until the framework is working as intended.  I have
code that instantiates serializable classes and serializes to XML or
normal serialized representation.  Comparing via diff isn't that hard
on the XML afterward.  Testing that Classpath's libraries can in fact
read the serialized forms is also not too difficult.  I might should
spend time making it easy to run as a suite of tests.

Brian
-- 
Brian Jones <[EMAIL PROTECTED]>


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

Re: [kaffe] Serialization

[Guilhem Lavaux]

Hi,

Finally, I have followed kaffe's regression tests. Classpath's 
serialization passes all kaffe's tests, although one is wrong
according to JDK 1.4.2 (TestSerialVersions.Test0007 should give "null, 
105"). serialPersistentFields is now also used
by the reading process to create some more fields to ensure 
compatibility. For the moment I do know how to deal with
the last failing test (I do not even know if it is not a bug in the JDK, 
the behaviour is really weird).

Cheers,
Guilhem.
P.S.: I will send to Mark the last patch against Classpath and will soon 
commit the code in kaffe's CVS.



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

Re: [kaffe] Serialization

[Brian Jones]

Guilhem Lavaux <[EMAIL PROTECTED]> writes:

> Hi,
> 
> Finally, I have followed kaffe's regression tests. Classpath's
> serialization passes all kaffe's tests, although one is wrong
> according to JDK 1.4.2 (TestSerialVersions.Test0007 should give "null,
> 105"). serialPersistentFields is now also used
> by the reading process to create some more fields to ensure
> compatibility. For the moment I do know how to deal with
> the last failing test (I do not even know if it is not a bug in the
> JDK, the behaviour is really weird).
> 
> Cheers,
> Guilhem.
> 
> P.S.: I will send to Mark the last patch against Classpath and will
> soon commit the code in kaffe's CVS.

Sweet, when could this go into Classpath?

Thanks,
Brian
-- 
Brian Jones <[EMAIL PROTECTED]>


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

Re: [kaffe] Serialization

[Mark Wielaard]

Hi,

On Tue, 2003-08-12 at 01:13, Brian Jones wrote:
>
> Sweet, when could this go into Classpath?

Guilhem already send me a patch and as soon as the paperwork is done it
will almost certainly go immediately (I will review it, but it looks
pretty good). And Guilhem already checked in this new code (the GNU
Classpath ObjectStream classes with his fixes into Kaffe so people can
already play with it if they want.

Cheers,

Mark



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