javax.crypto fixes

I fixed some stuff in javax.crypto:

1. decryption with padding was broken/wrong handled
2. CipherOutputStream was completly broken/unusuable
3. PKCS7 did an unnecessary test

1. decryption with padding needs to keep back the last block for final 
unpadding when doFinal() is called. This wasn't done. doFinal() lead to 
an exception.
Actually, padded decrypting only worked correct when all data was passed 
by doFinal(byte[]) or when there where update() calls that filled the 
data to a multiple of the blocklengh and doFinal was called with the 
rest of the data.
This fixes CiperInputStream as well, because it relies on the correct 
doFinal() handling of the cipher class.

2. CipherOutputstream had a lot of code that did nothing except leading 
to a NullPointerException when calling write(...) (outBuffer was never 
initialized). It looks to me like the code should have worked around the 
bugs in CipherAdapter. But that should have been done in CipherInputStream?!

3. PKCS7 unpadding tested a value that was just read with itself. Fixed 
it because I was already reading it... Nothing big...

Any comments? Hints?

I have no committing rights and the copyright assignment papers are not 
yet arrived with mail. This might be a problem...

Marco

Re: javax.crypto fixes

Marco Trudel wrote:
> I fixed some stuff in javax.crypto:
> 

Thanks for looking at this. Some of these parts of javax.crypto were
badly implemented, and I have to claim responsibility for that.

> 1. decryption with padding was broken/wrong handled
> 2. CipherOutputStream was completly broken/unusuable
> 3. PKCS7 did an unnecessary test
> 
> 1. decryption with padding needs to keep back the last block for final
> unpadding when doFinal() is called. This wasn't done. doFinal() lead to
> an exception.
> Actually, padded decrypting only worked correct when all data was passed
> by doFinal(byte[]) or when there where update() calls that filled the
> data to a multiple of the blocklengh and doFinal was called with the
> rest of the data.
> This fixes CiperInputStream as well, because it relies on the correct
> doFinal() handling of the cipher class.
> 

Understood. Sounds fine.

> 2. CipherOutputstream had a lot of code that did nothing except leading
> to a NullPointerException when calling write(...) (outBuffer was never
> initialized). It looks to me like the code should have worked around the
> bugs in CipherAdapter. But that should have been done in
> CipherInputStream?!
> 

Re: RFC: Custom composite support

Thanks Roman and Tom,

> - Try to limit the number of buffers needed and cache them.

This certainly sounds like a good idea; one question though: how can the buffer be reset between
operations?  I've tried using clearRect(), fill(), even setSample() and setPixel(), and can't get it to
work.  Either the old contents remain in the buffer (thus they get composited twice, and are too dark), or
the buffer background is no longer transparent and the background itself gets composited on the screen. 
It definitely should be possible, maybe I'm missing something...

> +    if (comp == null || comp instanceof AlphaComposite)
> +      super.draw(s);
> +
> +    // Custom composite
> +    else
> 
> Would it be cleaner to create a CustomVolatileImageGraphics that extends 
> VolatileImageGraphics?

I'm not sure - the composite is set after the VolatileImageGraphics is
created, so we don't know at creation-time whether to return the custom
subclass...

> +  pixbuf = gdk_pixbuf_new( GDK_COLORSPACE_RGB, TRUE, 8, width, height );
> +  gdk_pixbuf_get_from_drawable( pixbuf, pixmap, NULL, 0, 0, 0, 0, width, height );
> +  pixels = gdk_pixbuf_get_pixels(pixbuf);
> 
> Is pixmap guaranteed to be entirely on-screen for this call?  If not, some of 
> the resultant pixbuf will be black or undefined.

FYI: Addition of MBeanServer delegate bean

This adds the delegate management bean for the management
servers.

Changelog:

2006-10-02  Andrew John Hughes  <gnu_andrew <at> member.fsf.org>

	* gnu/classpath/ListenerData.java:
	New class for holding listener data.
	* gnu/java/lang/management/MemoryMXBeanImpl.java:
	ListenerData class moved to its own file.
	* javax/management/MBeanServerDelegate.java,
	* javax/management/MBeanServerDelegateMBean.java,
	* javax/management/MBeanServerNotification.java:
	Implemented.

--

-- 
Andrew 

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

Index: gnu/classpath/ListenerData.java
===================================================================
RCS file: gnu/classpath/ListenerData.java
diff -N gnu/classpath/ListenerData.java
--- /dev/null	1 Jan 1970 00:00:00 -0000
+++ gnu/classpath/ListenerData.java	2 Oct 2006 18:22:48 -0000

FYI: Image premultiplication fixes

Hi,

I found a number of mis-matches in our handling of alpha
premultiplication; Cairo data is always pre-multiplied, but we don't
always check for this (sometimes we pass Cairo non-premultiplied data,
and sometimes we assume the raw data is not premultiplied).

This patch should fix those issues, as well as fixing the behaviour of
Graphics.clearRect (it should write the background directly using the
AlphaComposite.SRC rule, instead of doing a regular fill, as shown by a
mauve test).

This also answers my earlier question about the custom composites (the
buffer wasn't clearing properly because the clearRect() method was
buggy).

Cheers,
Francis

2006-10-02  Francis Kung  <fkung <at> redhat.com>

	* gnu/java/awt/peer/gtk/BufferedImageGraphics.java
	(updateBufferedImage): Recognise that raw data is alpha-premultiplied.
	* gnu/java/awt/peer/gtk/CairoGraphics2D.java
	(clearRect): Paint background colour with AlphaComposite.SRC rule.
	(drawImage(Image, AffineTransform, Color, ImageObserver)): Alpha
	pre-multiply data before drawing.
	(fillRect): Draw using regular fill() method.
	(setComposite): Handle null case with AlphaComposite.SrcOver default.
	* gnu/java/awt/peer/gtk/CairoSurface.java

RFC: DecimalFormat and friends (part 3)...

The current update fixes a couple of issues and almost all the remaining
mauve tests.

There is still lack for the Iterator, and a failure for an exponential
pattern.

I'm working on the latter, but everything else now should work.

Please, let me know!!!!!!!

Mario
> 
> 2006-09-29  Mario Torre  <neugens <at> limasoftware.net>
> 
> 	PR28462
> 	* java/text/DecimalFormat.java: Almost new rewrite, and update to 1.5.
> 	* java/text/DecimalFormatSymbols.java (clone): fixed to also clones
> 	locale.
> 	* java/text/NumberFormat.java (format): all format methods, fixed
> 	FieldPosition argument should never be null.
> 	(format(Object, StringBuffer, FieldPosition)): fixed signature, method
> is
> 	not final.
> 
--

-- 
Lima Software, SO.PR.IND. s.r.l.
http://www.limasoftware.net/
pgp key: http://subkeys.pgp.net/

Proud GNU Classpath developer: http://www.classpath.org/

FYI: Custom Composites

Alright, the first part of custom composites is attached and committed.
They should now work with the VolatileImageGraphics peer, with patches
for the other peers coming soon.

Cheers,
Francis

2006-10-03  Francis Kung  <fkung <at> redhat.com>

	* gnu/java/awt/peer/gtk/CairoGraphics2D.java
	(compCtx): New field for composite context.
	(copy): Copy composite.
	(dispose): Dispose of composite context.
	(getNativeCM): New method.
	(setComposite): Discard old composite context and set up new context.
	(setRenderingHints): Update composite context.
	* gnu/java/awt/peer/gtk/CairoSurface.java
	(nativeColorModel): New field, renamed from nativeModel.
	(nativeModel): Renamed field to nativeColorModel.
	(CairoSurface(int, int)): Call new method to create sample model.
	(createNativeSampleModel): New method.
	(getBufferedImage): Updated variable name.
	* gnu/java/awt/peer/gtk/VolatileImageGraphics.java
	(buffer): New field.
	(createBuffer): New method.
	(draw): New method.
	(drawComposite): New method.
	(drawGlyphVector): New method.
	(drawImage(Image, AffineTransform, Color, ImageObserver)): New method.
	(drawImage(Image, int, int, ImageObserver)): Check composite.

Re: RFC: IdentityHashMap linear probing

>>>>> "Tom" == Tom Tromey <tromey <at> redhat.com> writes:

Tom> This changes IdentityHashMap to use linear probing, aka PR 28987.
Tom> This ought to be more cache friendly.  Also it lets us handle remove()
Tom> more efficiently, and removes the need for a tombstone object.

I checked this in.
Let me know if you run into any problems with it.

Tom

Re: RFC: a different Locale serialization fix

>>>>> "Tom" == Tom Tromey <tromey <at> redhat.com> writes:

Tom> I checked something like this into libgcj.  I'd like some comments on
Tom> it.
Tom> This is a different serialization fix for Locale.  See the earlier
Tom> thread for background:

I checked this in today.

Tom

RFC: DecimalFormat and friends (part 4)...

Il giorno mar, 03/10/2006 alle 13.35 +0200, Mario Torre ha scritto:

> The current update fixes a couple of issues and almost all the remaining
> mauve tests.

Ops, I've sent the wrong patch... This should be the right one...

Mario

--

-- 
Lima Software, SO.PR.IND. s.r.l.
http://www.limasoftware.net/
pgp key: http://subkeys.pgp.net/

Proud GNU Classpath developer: http://www.classpath.org/
Read About us at: http://planet.classpath.org

Please, support open standards:
http://opendocumentfellowship.org/petition/
http://www.nosoftwarepatents.com/