Roman Kennke | 1 Jul 01:20 2006

FYI: AbstractGraphics2D fix

This provides a default impl for getDestinationRaster() in
AbstractGraphics2D. I hope that this fixes the build for the X peers.

2006-07-01  Roman Kennke  <kennke <at> aicas.com>

        * gnu/java/awt/java2d/AbstractGraphics2D.java
        (transform): Make field protected.
        (getDestinationRaster): Provide default implementation for
        previously abstract method.

/Roman

--

-- 
“Improvement makes straight roads, but the crooked roads, without
Improvement, are roads of Genius.” - William Blake
Attachment (patch.diff): text/x-patch, 5639 bytes
Raif S. Naffah | 1 Jul 01:24 2006
Picon

Re: FYI: X peers

hello Roman,

On Friday 30 June 2006 01:27, Roman Kennke wrote:
> I checked in the Escher-based X peers and added some configury for
> enabling it. To build the X peers you need the most recent Escher
> library, to be found here:
>
> http://kennke.org/~roman/escher-0.3.0.jar
>
> Configure with: --with-escher=/path/to/escher-0.3.0.jar
> --enable-local-sockets

would it make sense to create a new folder, say "external-jars" and 
include the latest escher (and other java-only external dependencies) 
jar(s) there.  --with-escher can use that jar/location by default, 
otherwise the full path to a distro's/user's location of that jar can 
be fed to configure.

cheers;
rsn
Roman Kennke | 1 Jul 10:33 2006

Re: FYI: X peers

Hi Raif,

Am Samstag, den 01.07.2006, 09:24 +1000 schrieb Raif S. Naffah:
> hello Roman,
> 
> On Friday 30 June 2006 01:27, Roman Kennke wrote:
> > I checked in the Escher-based X peers and added some configury for
> > enabling it. To build the X peers you need the most recent Escher
> > library, to be found here:
> >
> > http://kennke.org/~roman/escher-0.3.0.jar
> >
> > Configure with: --with-escher=/path/to/escher-0.3.0.jar
> > --enable-local-sockets
> 
> would it make sense to create a new folder, say "external-jars" and 
> include the latest escher (and other java-only external dependencies) 
> jar(s) there.  --with-escher can use that jar/location by default, 
> otherwise the full path to a distro's/user's location of that jar can 
> be fed to configure.

This makes sense. I am all for it.

Mark proposed to put jars that are (optionally) needed for classpath on
http://builder.classpath.org/ somewhere. What do others think?

/Roman

--

-- 
“Improvement makes straight roads, but the crooked roads, without
(Continue reading)

Michael Koch | 1 Jul 12:05 2006
Picon
Picon

Re: FYI: X peers

On Sat, Jul 01, 2006 at 10:33:10AM +0200, Roman Kennke wrote:
> Hi Raif,
> 
> Am Samstag, den 01.07.2006, 09:24 +1000 schrieb Raif S. Naffah:
> > hello Roman,
> > 
> > On Friday 30 June 2006 01:27, Roman Kennke wrote:
> > > I checked in the Escher-based X peers and added some configury for
> > > enabling it. To build the X peers you need the most recent Escher
> > > library, to be found here:
> > >
> > > http://kennke.org/~roman/escher-0.3.0.jar
> > >
> > > Configure with: --with-escher=/path/to/escher-0.3.0.jar
> > > --enable-local-sockets
> > 
> > would it make sense to create a new folder, say "external-jars" and 
> > include the latest escher (and other java-only external dependencies) 
> > jar(s) there.  --with-escher can use that jar/location by default, 
> > otherwise the full path to a distro's/user's location of that jar can 
> > be fed to configure.
> 
> This makes sense. I am all for it.
> 
> Mark proposed to put jars that are (optionally) needed for classpath on
> http://builder.classpath.org/ somewhere. What do others think?

Don't put jars without sources into classpath releases. Otherwise
Distros will need to alter the upstream tarball and remove this. And
altering removes the feature that people can easily check if the
(Continue reading)

Raif S. Naffah | 1 Jul 12:03 2006
Picon

FYI: another partial fix for PPR Classpath/26067

hello all,

the attached patch --already committed-- is the 8th of a series of 
patches to address the above PR.

2006-07-01  Raif S. Naffah  <raif <at> swiftdsl.com.au>

	* gnu/javax/crypto/key/dh/DHKeyPairRawCodec.java: Source formatting.
	* gnu/javax/crypto/key/dh/DiffieHellmanKeyAgreement.java: Likewise.
	* gnu/javax/crypto/key/dh/DiffieHellmanReceiver.java: Likewise.
	* gnu/javax/crypto/key/dh/DiffieHellmanSender.java: Likewise.
	* gnu/javax/crypto/key/dh/ElGamalKeyAgreement.java: Likewise.
	* gnu/javax/crypto/key/dh/ElGamalReceiver.java: Likewise.
	* gnu/javax/crypto/key/dh/ElGamalSender.java: Likewise.
	* gnu/javax/crypto/key/dh/GnuDHKey.java: Likewise.
	* gnu/javax/crypto/key/dh/GnuDHKeyPairGenerator.java: Likewise.
	* gnu/javax/crypto/key/dh/GnuDHPrivateKey.java: Likewise.
	* gnu/javax/crypto/key/dh/GnuDHPublicKey.java: Likewise.
	* gnu/javax/crypto/key/dh/RFC2631.java: Likewise.
	* gnu/javax/crypto/key/srp6/SRP6Host.java: Likewise.
	* gnu/javax/crypto/key/srp6/SRP6KeyAgreement.java: Likewise.
	* gnu/javax/crypto/key/srp6/SRP6SaslClient.java: Likewise.
	* gnu/javax/crypto/key/srp6/SRP6SaslServer.java: Likewise.
	* gnu/javax/crypto/key/srp6/SRP6TLSClient.java: Likewise.
	* gnu/javax/crypto/key/srp6/SRP6TLSServer.java: Likewise.
	* gnu/javax/crypto/key/srp6/SRP6User.java: Likewise.
	* gnu/javax/crypto/key/srp6/SRPAlgorithm.java: Likewise.
	* gnu/javax/crypto/key/srp6/SRPKey.java: Likewise.
	* gnu/javax/crypto/key/srp6/SRPKeyPairGenerator.java: Likewise.
	* gnu/javax/crypto/key/srp6/SRPKeyPairRawCodec.java: Likewise.
(Continue reading)

Raif S. Naffah | 1 Jul 12:22 2006
Picon

Re: [cp-patches] FYI: X peers

hello Michael,

On Saturday 01 July 2006 20:05, Michael Koch wrote:
> On Sat, Jul 01, 2006 at 10:33:10AM +0200, Roman Kennke wrote:
> > Am Samstag, den 01.07.2006, 09:24 +1000 schrieb Raif S. Naffah:
> > > On Friday 30 June 2006 01:27, Roman Kennke wrote:
> > > > I checked in the Escher-based X peers and added some configury
> > > > for enabling it. To build the X peers you need the most recent
> > > > Escher library, to be found here:
> > > >
> > > > http://kennke.org/~roman/escher-0.3.0.jar
> > > >
> > > > Configure with: --with-escher=/path/to/escher-0.3.0.jar
> > > > --enable-local-sockets
> > >
> > > would it make sense to create a new folder, say "external-jars"
> > > and include the latest escher (and other java-only external
> > > dependencies) jar(s) there.  --with-escher can use that
> > > jar/location by default, otherwise the full path to a
> > > distro's/user's location of that jar can be fed to configure.
> >
> > This makes sense. I am all for it.
> >
> > Mark proposed to put jars that are (optionally) needed for
> > classpath on http://builder.classpath.org/ somewhere. What do
> > others think?
>
> Don't put jars without sources into classpath releases. Otherwise
> Distros will need to alter the upstream tarball and remove this. And
> altering removes the feature that people can easily check if the
(Continue reading)

Michael Koch | 1 Jul 12:44 2006
Picon
Picon

Re: FYI: X peers

On Sat, Jul 01, 2006 at 08:22:46PM +1000, Raif S. Naffah wrote:
> hello Michael,
> 
> On Saturday 01 July 2006 20:05, Michael Koch wrote:
> > On Sat, Jul 01, 2006 at 10:33:10AM +0200, Roman Kennke wrote:
> > > Am Samstag, den 01.07.2006, 09:24 +1000 schrieb Raif S. Naffah:
> > > > On Friday 30 June 2006 01:27, Roman Kennke wrote:
> > > > > I checked in the Escher-based X peers and added some configury
> > > > > for enabling it. To build the X peers you need the most recent
> > > > > Escher library, to be found here:
> > > > >
> > > > > http://kennke.org/~roman/escher-0.3.0.jar
> > > > >
> > > > > Configure with: --with-escher=/path/to/escher-0.3.0.jar
> > > > > --enable-local-sockets
> > > >
> > > > would it make sense to create a new folder, say "external-jars"
> > > > and include the latest escher (and other java-only external
> > > > dependencies) jar(s) there.  --with-escher can use that
> > > > jar/location by default, otherwise the full path to a
> > > > distro's/user's location of that jar can be fed to configure.
> > >
> > > This makes sense. I am all for it.
> > >
> > > Mark proposed to put jars that are (optionally) needed for
> > > classpath on http://builder.classpath.org/ somewhere. What do
> > > others think?
> >
> > Don't put jars without sources into classpath releases. Otherwise
> > Distros will need to alter the upstream tarball and remove this. And
(Continue reading)

Andrew John Hughes | 1 Jul 13:33 2006
Picon

FYI: Add implementation of thread MX bean

This adds the missing implementation of a Thread MX bean at last.
This also removes the earlier VMThreadInfo interface, which turned
out to be unworkable for two reasons:

* The bean implementation and ThreadInfo exist in different packages,
and thus one can't construct the other from Java.  There are ways to
avoid this, but they are generally ugly.
* The real showstopper is that the information needs to be serialized to
a javax.management.openmbean.CompositeData object and back (see the
currently missing from(CompositeData) method of ThreadInfo).  This implies
that the information is not discovered on a as-needed basis, as I first thought,
but when the ThreadInfo is created.

Thus, the same information is still required from the VM, but instead of supplying
it via a series of native methods, it is supplied to the new private constructor
of ThreadInfo in one shot.  This also leaves the interpretation of maxDepth with
the VM.

A new interface, VMThreadMXBeanImpl, is supplied which includes the call to the
VM to get the ThreadInfo along with the other required methods.  This includes some
default implementations of some of the methods, which can be overridden with better
solutions by the VMs.

Changelog:

2006-07-01  Andrew John Hughes  <gnu_andrew <at> member.fsf.org>

	* gnu/java/lang/management/BeanImpl.java:
	New superclass for all bean implementations.
	* gnu/java/lang/management/ClassLoadingMXBeanImpl.java:
(Continue reading)

Andrew John Hughes | 1 Jul 13:57 2006
Picon

FYI: Fix thread ID start value

The attached patch fixes the initialization of the thread IDs
in java.lang.Thread so that it starts at 1.  0 is not a valid
thread ID, and was rightly being thrown out by the managment stuff.

Changelog:

2006-07-01  Andrew John Hughes  <gnu_andrew <at> member.fsf.org>

	* java/lang/Thread.java:
	Make thread IDs start from 1.

--

-- 
Andrew :-)

Please avoid sending me Microsoft Office (e.g. Word, PowerPoint) attachments.
See http://www.fsf.org/philosophy/no-word-attachments.html

If you use Microsoft Office, support movement towards the end of vendor lock-in:
http://opendocumentfellowship.org/petition/

"Value your freedom, or you will lose it, teaches history. 
`Don't bother us with politics' respond those who don't want to learn." 
-- Richard Stallman

Escape the Java Trap with GNU Classpath!
http://www.gnu.org/philosophy/java-trap.html
public class gcj extends Freedom implements Java { ... }
Index: java/lang/Thread.java
(Continue reading)

Jeroen Frijters | 1 Jul 15:01 2006
Picon

FYI: New VM helper method ThreadGroup.getThreadFromId

Hi,

I added a helper method to ThreadGroup that the VM can use to
(relativelyly) efficiently resolve a thread id into a Thread object.

Regards,
Jeroen

2006-07-01  Jeroen Frijters  <jeroen <at> frijters.net>

        * java/lang/ThreadGroup.java
        (getThreadFromId, getThreadFromIdImpl): New methods.
Index: java/lang/ThreadGroup.java
===================================================================
RCS file: /cvsroot/classpath/classpath/java/lang/ThreadGroup.java,v
retrieving revision 1.21
diff -u -r1.21 ThreadGroup.java
--- java/lang/ThreadGroup.java	10 May 2006 13:54:51 -0000	1.21
+++ java/lang/ThreadGroup.java	1 Jul 2006 12:39:11 -0000
 <at>  <at>  -749,4 +749,43  <at>  <at> 
           parent.removeGroup(this);
       }
   }
+
+  /*
+   * Helper method for the VM. Find a Thread by its Id.
+   *
+   *  <at> param id The Thread Id.
(Continue reading)


Gmane