date:20060204

Re: [cp-patches] DSSKeyPairGenerator JCE Adapter

2006-02-04 Thread Mark Wielaard

On Fri, 2006-02-03 at 16:34 -0800, Casey Marshall wrote:
 Looks wrong to me; you usually break lines after `,' or `+' in long  
 expressions like this, not after the `(' (Emacs will break the  
 formatting here, and will indent the Parameters.. line to line up  
 with the opening parenthesis). In this case I think doing something  
 like this is more appropriate:
 
throw new InvalidAlgorithmParameterException
  (Parameters argument is not a non-null instance, or  +
   sub-instance, of java.security.spec.DSAParameterSpec);

To be really pedantic. It is after a ',' or before a operator (like +),
so it would actually be:

   throw new InvalidAlgorithmParameterException
 (Parameters argument is not a non-null instance, or 
  + sub-instance, of java.security.spec.DSAParameterSpec);

 Although I don't want to claim to be a GNU source formatting expert.  

I am neither, but emacs is mostly right :)
Normally we try to follow the generic GNU C formatting:
http://www.gnu.org/prep/standards/html_node/Formatting.html
The specific GNU Classpath java source code extensions are documented:
http://www.gnu.org/software/classpath/docs/hacking.html#SEC7

Cheers,

Mark


signature.asc
Description: This is a digitally signed message part

Re: [cp-patches] Re: RFC: Remove default 'Expect 100-continue' usage in HTTP Requests

2006-02-04 Thread Wolfgang Baer

Hi,

David Daney wrote:
 Wolfgang Baer wrote:
 
 +String expect = getHeader(Expect);
 +if (expect != null  expect.equals(100-continue))
 
  ^
 
 This *may* have to be a case insensitive compare.  I think RFC2616
 allows either upper or lower case.

I am not sure about this, Section 4.2 Message Headers of the RFC only
explicitly talks about case insensitiveness for the field name (which
is respected througth the getHeader() method) and nothing about the
field value.

I am fine with comparing through equalsIgnoreCase if you think so. I am
not familiar with reading RFC's - maybe its noted somewhere else and I
didn't found it.

Thanks,
Wolfgang

Re: [cp-patches] Patch: DefaultStyledDocument.ElementBuffer final fix

2006-02-04 Thread Roman Kennke

Hi Lillian,

Am Freitag, den 03.02.2006, 11:25 -0500 schrieb Lillian Angel:
 All the structures in the mauve tests are now correct. There are some
 regressions with ElementBuffer still. 
 
 Mark, can you please change these to Failures instead. They test that
 the leaves of the document are created in a certain order, right now we
 are creating leaves differently from Sun.. but this is not really an
 important issue. They should not be considered regressions.
 
 The structure created by the ElementBuffer is now correct. In a certain
 case, I get an exception but this is a GapContent Bug:
 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26091
 
 As of now, DefaultStyledDocument.ElementBuffer creates a structure
 identical to Sun, so the corresponding bug has been closed. (Finally!)


Great work indeed! The BeanShell Swing console now starts up again and I
am actually able to type into it. It looks a bit ugly and is slow like
hell, but that seems to be a view problem. Now we should go on with
fixing the styled text views and push HTML when that works. Maybe we can
get something running for 0.21?

Cheers, Roman



signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil

[cp-patches] FYI: JLayeredPane fixes / new Container methods

2006-02-04 Thread Roman Kennke

This fixes a mauve test for JLayeredPane. In order to fix this, I
implemented the set/getComponentZOrder() methods in Container and made
JLayeredPane use these methods. This is not only much more efficient
than adding/removing components when changing the order, it also fixes a
nasty problem when there is a layout manager installed on the
JLayeredPane (which is discouraged but not forbidden).

2006-02-04  Roman Kennke  [EMAIL PROTECTED]

* java/awt/Container.java
(getComponentZOrder): New method.
(setComponentZOrder): New method.
* javax/swing/JLayeredPane.java
(setPosition): Reimplemented to use setComponentZOrder().
(getIndexOf): Reimplemented to use getComponentZOrder().
(addImpl): Pass layerContraint to super call. Important for
possibly
installed layout managers.
(swapComponents): Remove unneeded method.

/Roman
Index: java/awt/Container.java
===
RCS file: /cvsroot/classpath/classpath/java/awt/Container.java,v
retrieving revision 1.77
diff -u -r1.77 Container.java
--- java/awt/Container.java	27 Jan 2006 15:51:21 -	1.77
+++ java/awt/Container.java	4 Feb 2006 11:04:18 -
@@ -1565,6 +1565,93 @@
 changeSupport.addPropertyChangeListener (name, listener);
   }
 
+
+  /**
+   * Sets the Z ordering for the component codecomp/code to
+   * codeindex/code. Components with lower Z order paint above components
+   * with higher Z order.
+   *
+   * @param comp the component for which to change the Z ordering
+   * @param index the index to set
+   *
+   * @throws NullPointerException if codecomp == null/code
+   * @throws IllegalArgumentException if comp is an ancestor of this container
+   * @throws IllegalArgumentException if codeindex/code is not in
+   * code[0, getComponentCount()]/code for moving between
+   * containers or code[0, getComponentCount() - 1]/code for moving
+   * inside this container
+   * @throws IllegalArgumentException if codecomp == this/code
+   * @throws IllegalArgumentException if codecomp/code is a
+   * codeWindow/code
+   *
+   * @see #getComponentZOrder(Component)
+   *
+   * @since 1.5
+   */
+  public final void setComponentZOrder(Component comp, int index)
+  {
+if (comp == null)
+  throw new NullPointerException(comp must not be null);
+if (comp instanceof Container  ((Container) comp).isAncestorOf(this))
+  throw new IllegalArgumentException(comp must not be an ancestor of 
+ + this);
+if (comp instanceof Window)
+  throw new IllegalArgumentException(comp must not be a Window);
+
+if (comp == this)
+  throw new IllegalArgumentException(cannot add component to itself);
+
+// FIXME: Implement reparenting.
+if ( comp.getParent() != this)
+  throw new AssertionError(Reparenting is not implemented yet);
+else
+  {
+// Find current component index.
+int currentIndex = getComponentZOrder(comp);
+if (currentIndex  index)
+  {
+System.arraycopy(component, currentIndex + 1, component,
+ currentIndex, index - currentIndex);
+  }
+else
+  {
+System.arraycopy(component, index, component, index + 1,
+ currentIndex - index);
+  }
+component[index] = comp;
+  }
+  }
+
+  /**
+   * Returns the Z ordering index of codecomp/code. If codecomp/code
+   * is not a child component of this Container, this returns code-1/code.
+   *
+   * @param comp the component for which to query the Z ordering
+   *
+   * @return the Z ordering index of codecomp/code or code-1/code if
+   * codecomp/code is not a child of this Container
+   *
+   * @see #setComponentZOrder(Component, int)
+   *
+   * @since 1.5
+   */
+  public final int getComponentZOrder(Component comp)
+  {
+int index = -1;
+if (component != null)
+  {
+for (int i = 0; i  component.length; i++)
+  {
+if (component[i] == comp)
+  {
+index = i;
+break;
+  }
+  }
+  }
+return index;
+  }
+
   // Hidden helper methods.
 
   /**
Index: javax/swing/JLayeredPane.java
===
RCS file: /cvsroot/classpath/classpath/javax/swing/JLayeredPane.java,v
retrieving revision 1.42
diff -u -r1.42 JLayeredPane.java
--- javax/swing/JLayeredPane.java	1 Feb 2006 12:17:13 -	1.42
+++ javax/swing/JLayeredPane.java	4 Feb 2006 11:04:18 -
@@ -353,16 +353,9 @@
*/
   public void setPosition(Component c, int position)
   {
-int currentPos = getPosition(c);
-if (currentPos == position)
-  return;
-
 int layer = getLayer(c);
-int i1 = position;
-int i2 = getPosition(c);
-int incr = (i1 - i2) / Math.abs(i1 - i2);
-for (int p = i2; p != i1;

Re: [cp-patches] DSSKeyPairGenerator JCE Adapter

2006-02-04 Thread Raif S. Naffah

hello all,

On Saturday 04 February 2006 20:52, Mark Wielaard wrote:
 On Fri, 2006-02-03 at 16:34 -0800, Casey Marshall wrote:
  Looks wrong to me; you usually break lines after `,' or `+' in long
  expressions like this, not after the `(' (Emacs will break the
  formatting here, and will indent the Parameters.. line to line up
  with the opening parenthesis). In this case I think doing something
  like this is more appropriate:
 
 throw new InvalidAlgorithmParameterException
   (Parameters argument is not a non-null instance, or  +
sub-instance, of java.security.spec.DSAParameterSpec);

 To be really pedantic. It is after a ',' or before a operator (like
 +), so it would actually be:

throw new InvalidAlgorithmParameterException
  (Parameters argument is not a non-null instance, or 
   + sub-instance, of java.security.spec.DSAParameterSpec);

  Although I don't want to claim to be a GNU source formatting
  expert.

 I am neither, but emacs is mostly right :)
 Normally we try to follow the generic GNU C formatting:
 http://www.gnu.org/prep/standards/html_node/Formatting.html
 The specific GNU Classpath java source code extensions are
 documented:
 http://www.gnu.org/software/classpath/docs/hacking.html#SEC7

since we're at it ;-)  here is the output of the GNU
(srcipts/eclipse-gnu.xml) and GNU Classpath (attached
eclipse-gnu-classpath.xml) which one looks more acceptable?

- - - begin GNU formatter

package gnu.java.security.key.dss;

import gnu.java.security.OID;
import gnu.java.security.Registry;
import gnu.java.security.der.BitString;
import gnu.java.security.der.DER;
import gnu.java.security.der.DERReader;
import gnu.java.security.der.DERValue;
import gnu.java.security.der.DERWriter;
import gnu.java.security.key.IKeyPairCodec;

import java.io.ByteArrayOutputStream;
import java.io.IOException;
import java.math.BigInteger;
import java.security.InvalidParameterException;
import java.security.PrivateKey;
import java.security.PublicKey;
import java.util.ArrayList;

/**
 * An implementation of an [EMAIL PROTECTED] 
gnu.java.security.key.IKeyPairCodec} that
 * knows how to encode/decode X.509 ASN.1 external representation of DSS keys.
 */
public class DSSKeyPairX509Codec implements IKeyPairCodec
{
  // Constants and variables
  // --

  private static final OID DSA_ALG_OID = new OID(Registry.DSA_OID_STRING);

  // Constructor(s)
  // --

  // implicit 0-arguments constructor

  // Class methods
  // --

  // Instance methods
  // --

  // gnu.java.security.key.IKeyPairCodec interface implementation -

  public int getFormatID()
  {
return X509_FORMAT;
  }

  /**
   * Returns the X.509 ASN.1 iSubjectPublicKeyInfo/i representation of a
   * DSA public key. The ASN.1 specification is as follows:
   * 
   * pre
   *SubjectPublicKeyInfo ::= SEQUENCE {
   *  algorithm AlgorithmIdentifier,
   *  subjectPublicKey BIT STRING }
   * /pre
   * 
   * @param key
   *  the [EMAIL PROTECTED] PublicKey} instance to encode.
   * @return the ASN.1 representation of the iSubjectPublicKeyInfo/i in an
   * X.509 certificate.
   * @throw InvalidParameterException if codekey/code is not an instance
   *of [EMAIL PROTECTED] DSSPublicKey} or if an exception occurs during 
the
   *marshalling process.
   */
  public byte[] encodePublicKey(PublicKey key)
  {
if (!(key instanceof DSSPublicKey))
  throw new InvalidParameterException(key);

DSSPublicKey dssKey = (DSSPublicKey) key;
BigInteger p = dssKey.getParams().getP();
BigInteger q = dssKey.getParams().getQ();
BigInteger g = dssKey.getParams().getG();
BigInteger y = dssKey.getY();

byte[] result = null;
// - begin from gnu.java.security.provider.GnuDSAPublicKey
ByteArrayOutputStream baos = new ByteArrayOutputStream();
ArrayList spki = new ArrayList(2);
ArrayList alg = new ArrayList(2);
alg.add(new DERValue(DER.OBJECT_IDENTIFIER, DSA_ALG_OID));
ArrayList params = new ArrayList(3);
params.add(new DERValue(DER.INTEGER, p));
params.add(new DERValue(DER.INTEGER, q));
params.add(new DERValue(DER.INTEGER, g));
alg.add(new DERValue(DER.CONSTRUCTED | DER.SEQUENCE, params));
spki.add(new DERValue(DER.CONSTRUCTED | DER.SEQUENCE, alg));
spki.add(new DERValue(DER.BIT_STRING, new BitString(y.toByteArray(;
try
  {
DERWriter.write(baos,
new DERValue(DER.CONSTRUCTED | DER.SEQUENCE, spki));
result = baos.toByteArray();
  }
catch (IOException x)
  {
InvalidParameterException e = new InvalidParameterException();
e.initCause(x);
throw e;
  }
// - end from

[cp-patches] Re: FYI: Fixup ChangeLog

2006-02-04 Thread Raif S. Naffah

hello Mark,

On Saturday 04 February 2006 23:46, Mark Wielaard wrote:
 Hi,

 The latest ChangeLog entry from Raif had a string of
 A0A0A0A0A0A0A0A0 characters instead of a tab...

 Raif, could you see what produces those characters in your entries?

yes. i think i know how they got there.


cheers;
rsn


pgpZuc5aNZ4Wq.pgp
Description: PGP signature

Re: [cp-patches] DSSKeyPairGenerator JCE Adapter

2006-02-04 Thread Mark Wielaard

Hi Raif,

On Sat, 2006-02-04 at 22:19 +1100, Raif S. Naffah wrote:
   Although I don't want to claim to be a GNU source formatting
   expert.
 
  I am neither, but emacs is mostly right :)
  Normally we try to follow the generic GNU C formatting:
  http://www.gnu.org/prep/standards/html_node/Formatting.html
  The specific GNU Classpath java source code extensions are
  documented:
  http://www.gnu.org/software/classpath/docs/hacking.html#SEC7
 
 since we're at it ;-)  here is the output of the GNU
 (srcipts/eclipse-gnu.xml) and GNU Classpath (attached
 eclipse-gnu-classpath.xml) which one looks more acceptable?

I'll just go over it and say what looks wrong to me.

   // 
 --
 
   // gnu.java.security.key.IKeyPairCodec interface implementation 
 -

These lines look strange/wrong and are a pain to keep right (think
refactoring the class name and then having to keep these exactly the
same length). I would just remove them completely because the disturb
the reading flow.

 if (!(key instanceof DSSPublicKey))
   throw new InvalidParameterException(key);

Officially there is a space after each operator, so also for ! to make
it more clearly stand out. (This is not always/consistently done in our
sources though.) So write:

if (! (key instanceof DSSPublicKey))
  throw new InvalidParameterException(key);

 byte[] result = null;
 // - begin from gnu.java.security.provider.GnuDSAPublicKey

What is this comment trying to say me? There are a couple of these that
I don't immediately understand the relevance of.

 try
   {
 DERWriter.write(baos,
 new DERValue(DER.CONSTRUCTED | DER.SEQUENCE, spki));
 result = baos.toByteArray();
   }

Good, but personally I would write this:

  try
{
  DERValue val = new DERValue(DER.CONSTRUCTED | DER.SEQUENCE, spki);
  DERWriter.write(baos, val);
  result = baos.toByteArray();
}

 BigInteger p = null;
 BigInteger q = null;
 BigInteger g = null;
 BigInteger y = null;

Style comment. Since all these values should be definitely assigned on a
normal return from the method where they are used I would not assign
them a value here so the compiler can catch when they are used
uninitialized. (Note to compiler writers: A compiler could warn on such
assignments to constants that are never used.)

 try
   {
 DERWriter.write(baos,
 new DERValue(DER.CONSTRUCTED | DER.SEQUENCE, spki));
 result = baos.toByteArray();
   }

See above. The new DERValue should align with the baos after the
opening bracket.

Cheers,

Mark


signature.asc
Description: This is a digitally signed message part

Re: [cp-patches] RFC: Datatypes library

2006-02-04 Thread Mark Wielaard

Hi,

On Fri, 2006-02-03 at 12:46 +, Chris Burdess wrote:
 Mark Wielaard wrote:
  Arguably, if we change the name we lose any benefit of being able to
  plug in a 3rd party datatype library implementation. It would be
  trivial to duplicate just the part of the API we need in a private
  namespace and use that for our own providers, but we would only be
  able to use our own implementation.
 
  My primary reason for including this API is that it is the current
  standard API. I believe that much as with JAXP itself, free software
  benefits by being able to interface with alternate implementations,
  to provide more choice and facilitate testing.
 
  OK. Which other free datatype library implementations are there?
 
 James Clark's Jing (http://www.thaiopensource.com/relaxng/jing.html,  
 BSD licence)

It would indeed be nice to support that seamlessly. It seems it might
even be a starting point for a XML Schema validator. Although it doesn't
seem Jing is developed much lately.

Normally I would just say No to adding public packages that are not part
of other core library implementations. Just because that makes
compatibility a harder story for our users. But in this case I think we
could because:

1) This interface is really small and stable.
   - Users are unlikely to be using different versions from what we
 provide.
2) It seems this provides us a smooth path to get more/better
   implementations that we do need for the core library
   (xml.validation in this case).

But you should clearly document how this plugs into each other. If the
only people providing new validation support through the datatype
library is us then we can as well just use a private/renamed copy of the
package. And I would like for others to have a little more time to
comment on the proposal since it is kind of a precedent for including
such things (but the above 2 rules seems to prevent an explosion of
similar things).

So, does anybody else have any comments? Otherwise I think Chris should
go ahead with this (provided the interaction between xml.validation and
relaxng.datatype will be clearly documented).

Cheers,

Mark


signature.asc
Description: This is a digitally signed message part

[cp-patches] RFC: HTTPURLConnection fixlet

2006-02-04 Thread Wolfgang Baer

Hi,

this is the first fixlet for the failing fileNotFound test committed
to mauve.

2006-02-04  Wolfgang Baer  [EMAIL PROTECTED]

* gnu/java/net/protocol/http/HTTPURLConnection.java:
(connect): Don't throw FileNotFoundException.

OK to commit ?

Wolfgang
Index: HTTPURLConnection.java
===
RCS file: /cvsroot/classpath/classpath/gnu/java/net/protocol/http/HTTPURLConnection.java,v
retrieving revision 1.17
diff -u -r1.17 HTTPURLConnection.java
--- HTTPURLConnection.java	20 Jan 2006 22:15:58 -	1.17
+++ HTTPURLConnection.java	4 Feb 2006 14:24:42 -
@@ -352,7 +352,6 @@
 if (response.getCode() == 404)
 	  {
 		errorSink = responseSink;
-		throw new FileNotFoundException(url.toString());
 	  }
   }
   }

[cp-patches] RFC: gnu.regexp: (?=X), (?!X), (?X) supported

2006-02-04 Thread Ito Kazumitsu

ChangeLog
2006-02-05  Ito Kazumitsu  [EMAIL PROTECTED]

Fixes bug #25812
* gnu/regexp/CharIndexed.java(lookBehind),(length): New method.
* gnu/regexp/CharIndexedCharArray.java
(lookBehind),(length): Implemented.
* gnu/regexp/CharIndexedInputStream.java: Likewise.
* gnu/regexp/CharIndexedString.java: Likewise.
* gnu/regexp/CharIndexedStringBuffer.java: Likewise.
* gnu/regexp/REToken.java(getMaximumLength): New method.
* gnu/regexp/RE.java(internal constructor RE): Added new argument
maxLength.
(initialize): Parse (?=X), (?!X), (?X).
(getMaximumLength): Implemented.
* gnu/regexp/RETokenAny.java(getMaximumLength): Implemented.
* gnu/regexp/RETokenChar.java: Likewise.
* gnu/regexp/RETokenEnd.java: Likewise.
* gnu/regexp/RETokenEndSub.java: Likewise.
* gnu/regexp/RETokenLookAhead.java: Likewise.
* gnu/regexp/RETokenNamedProperty.java: Likewise.
* gnu/regexp/RETokenOneOf.java: Likewise.
* gnu/regexp/RETokenPOSIX.java: Likewise.
* gnu/regexp/RETokenRange.java: Likewise.
* gnu/regexp/RETokenRepeated.java: Likewise.
* gnu/regexp/RETokenStart.java: Likewise.
* gnu/regexp/RETokenWordBoundary.java: Likewise.
* gnu/regexp/RETokenIndependent.java: New file.
* gnu/regexp/RETokenLookBehind.java: New file.

Index: classpath/gnu/regexp/CharIndexed.java
===
RCS file: /cvsroot/classpath/classpath/gnu/regexp/CharIndexed.java,v
retrieving revision 1.2
diff -u -r1.2 CharIndexed.java
--- classpath/gnu/regexp/CharIndexed.java   2 Jul 2005 20:32:15 -   
1.2
+++ classpath/gnu/regexp/CharIndexed.java   4 Feb 2006 16:39:18 -
@@ -1,5 +1,5 @@
 /* gnu/regexp/CharIndexed.java
-   Copyright (C) 1998-2001, 2004 Free Software Foundation, Inc.
+   Copyright (C) 1998-2001, 2004, 2006 Free Software Foundation, Inc.
 
 This file is part of GNU Classpath.
 
@@ -81,4 +81,16 @@
  * position at a valid position in the input.
  */
 boolean isValid();
+
+/**
+ * Returns another CharIndexed containing length characters to the left
+ * of the given index. The given length is an expected maximum and
+ * the returned CharIndexed may not necessarily contain so many characters.
+ */
+CharIndexed lookBehind(int index, int length);
+
+/**
+ * Returns the effective length of this CharIndexed
+ */
+int length();
 }
Index: classpath/gnu/regexp/CharIndexedCharArray.java
===
RCS file: /cvsroot/classpath/classpath/gnu/regexp/CharIndexedCharArray.java,v
retrieving revision 1.2
diff -u -r1.2 CharIndexedCharArray.java
--- classpath/gnu/regexp/CharIndexedCharArray.java  2 Jul 2005 20:32:15 
-   1.2
+++ classpath/gnu/regexp/CharIndexedCharArray.java  4 Feb 2006 16:39:18 
-
@@ -1,5 +1,5 @@
 /* gnu/regexp/CharIndexedCharArray.java
-   Copyright (C) 1998-2001, 2004 Free Software Foundation, Inc.
+   Copyright (C) 1998-2001, 2004, 2006 Free Software Foundation, Inc.
 
 This file is part of GNU Classpath.
 
@@ -59,4 +59,13 @@
 public boolean move(int index) {
return ((anchor += index)  s.length);
 }
+
+public CharIndexed lookBehind(int index, int length) {
+   if (length  index) length = index;
+   return new CharIndexedCharArray(s, index - length);
+}
+
+public int length() {
+   return s.length - anchor;
+}
 }
Index: classpath/gnu/regexp/CharIndexedInputStream.java
===
RCS file: /cvsroot/classpath/classpath/gnu/regexp/CharIndexedInputStream.java,v
retrieving revision 1.3
diff -u -r1.3 CharIndexedInputStream.java
--- classpath/gnu/regexp/CharIndexedInputStream.java2 Jul 2005 20:32:15 
-   1.3
+++ classpath/gnu/regexp/CharIndexedInputStream.java4 Feb 2006 16:39:18 
-
@@ -1,5 +1,5 @@
 /* gnu/regexp/CharIndexedInputStream.java
-   Copyright (C) 1998-2001, 2004 Free Software Foundation, Inc.
+   Copyright (C) 1998-2001, 2004, 2006 Free Software Foundation, Inc.
 
 This file is part of GNU Classpath.
 
@@ -145,5 +145,15 @@
 public boolean isValid() {
return (cached != OUT_OF_BOUNDS);
 }
+
+public CharIndexed lookBehind(int index, int length) {
+   throw new UnsupportedOperationException(
+   difficult to look behind for an input stream);
+}
+
+public int length() {
+   throw new UnsupportedOperationException(
+   difficult to tell the length for an input stream);
+}
 }
 
Index: classpath/gnu/regexp/CharIndexedString.java
===
RCS file: /cvsroot/classpath/classpath/gnu/regexp/CharIndexedString.java,v
retrieving revision 1.2
diff -u -r1.2 CharIndexedString.java
--- classpath/gnu/regexp/CharIndexedString.java 2 Jul

Re: [cp-patches] RFC: HTTPURLConnection fixlet

2006-02-04 Thread Wolfgang Baer

Hi Chris,

Chris Burdess wrote:
 Wolfgang Baer wrote:

 Index: HTTPURLConnection.java
 ===
 RCS file: /cvsroot/classpath/classpath/gnu/java/net/protocol/http/
 HTTPURLConnection.java,v
 retrieving revision 1.17
 diff -u -r1.17 HTTPURLConnection.java
 --- HTTPURLConnection.java20 Jan 2006 22:15:58 -1.17
 +++ HTTPURLConnection.java4 Feb 2006 14:24:42 -
 @@ -352,7 +352,6 @@
  if (response.getCode() == 404)
{
  errorSink = responseSink;
 -throw new FileNotFoundException(url.toString());
}
}
}
 
 
 Woah there. This was definitely there for a reason - I believe we are 
 supposed to throw FileNotFoundException for a 404.

I looked a bit closer and found a FileNotFoundException being mentioned
in the getErrorStream method ...responds with a 404, which will cause a
FileNotFoundException to be thrown in connect

So its specified there but apparently (as the mauve test shows) it is
not done in the reference implementation. The question is what we should
do, following the api documentation of what the reference implementation does ?

Wolfgang

Re: [cp-patches] Re: RFC: Remove default 'Expect 100-continue' usage in HTTP Requests

2006-02-04 Thread David Daney


Wolfgang Baer wrote:

Hi,

David Daney wrote:


Wolfgang Baer wrote:



+String expect = getHeader(Expect);
+if (expect != null  expect.equals(100-continue))


^

This *may* have to be a case insensitive compare.  I think RFC2616
allows either upper or lower case.



I am not sure about this, Section 4.2 Message Headers of the RFC only
explicitly talks about case insensitiveness for the field name (which
is respected througth the getHeader() method) and nothing about the
field value.

I am fine with comparing through equalsIgnoreCase if you think so. I am
not familiar with reading RFC's - maybe its noted somewhere else and I
didn't found it.


It appears that you are correct.  I withdraw my objection.

David Daney.

Re: [cp-patches] RFC: HTTPURLConnection fixlet

2006-02-04 Thread David Daney


Wolfgang Baer wrote:

Hi Chris,

Chris Burdess wrote:


Wolfgang Baer wrote:




Index: HTTPURLConnection.java
===
RCS file: /cvsroot/classpath/classpath/gnu/java/net/protocol/http/
HTTPURLConnection.java,v
retrieving revision 1.17
diff -u -r1.17 HTTPURLConnection.java
--- HTTPURLConnection.java20 Jan 2006 22:15:58 -1.17
+++ HTTPURLConnection.java4 Feb 2006 14:24:42 -
@@ -352,7 +352,6 @@
if (response.getCode() == 404)
  {
errorSink = responseSink;
-throw new FileNotFoundException(url.toString());
  }
  }
  }



Woah there. This was definitely there for a reason - I believe we are 
supposed to throw FileNotFoundException for a 404.



I looked a bit closer and found a FileNotFoundException being mentioned
in the getErrorStream method ...responds with a 404, which will cause a
FileNotFoundException to be thrown in connect

So its specified there but apparently (as the mauve test shows) it is
not done in the reference implementation. The question is what we should
do, following the api documentation of what the reference implementation does ?

Wolfgang


I don't know what to do WRT to this spec/reference implementation 
disagreement, but this entire block of code is incorrect.


Please see:

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26081

David Daney.

Re: [cp-patches] DSSKeyPairGenerator JCE Adapter

2006-02-04 Thread Raif S. Naffah

hello Mark,

On Sunday 05 February 2006 00:03, Mark Wielaard wrote:
 On Sat, 2006-02-04 at 22:19 +1100, Raif S. Naffah wrote:
  ...
//
  ---
 ---
 
// gnu.java.security.key.IKeyPairCodec interface implementation
  -

 These lines look strange/wrong and are a pain to keep right (think
 refactoring the class name and then having to keep these exactly the
 same length). I would just remove them completely because the disturb
 the reading flow.

noted.


  if (!(key instanceof DSSPublicKey))
throw new InvalidParameterException(key);

 Officially there is a space after each operator, so also for ! to
 make it more clearly stand out...

yes we can do that: force a white space after a unary operator, but then 
we get:

boolean condition1 = false;
boolean condition2 = true;
// ...
if (condition1  ! condition2)
  {
// do something
  }

rather than 
if (condition1  !condition2)

if this is what we want then i'll update the style specs file 
accordingly.


  try
{
  DERWriter.write(baos,
  new DERValue(DER.CONSTRUCTED |
  DER.SEQUENCE, spki)); result = baos.toByteArray();
}

 Good...

the alternative uses a deep (2*indent) for continuation lines to avoid 
output like the one you see in 
gnu.java.security.key.DSSKeyPairGenerator; e.g. declaration of 
KEY_PARAMS_512.  i see from your later comments) though that this is 
not what we want.


  BigInteger p = null;
  BigInteger q = null;
  BigInteger g = null;
  BigInteger y = null;

 Style comment. Since all these values should be definitely assigned
 on a normal return from the method where they are used I would not
 assign them a value here so the compiler can catch when they are used
 uninitialized. (Note to compiler writers: A compiler could warn on
 such assignments to constants that are never used.)

good point.  a good compiler does catch these things.  they were 
assigned values before all the code that sets them was written to 
silence that compiler.  your comment is a valid reminder to re-visit 
the code once all the logic has been implemented.


i didn't see any comments on

a/ the line-wrapping before extends and implements.  i assume the 
alternative is the accepted one?

a.1:

public class Main extends KeyGenerator implements java.io.Serializable

or a.2:

public class Main
extends KeyGenerator
implements java.io.Serializable


b/ Javadoc style; which is more acceptable:

b1:

   * @param input the byte array to unmarshall into a valid DSS
   *  [EMAIL PROTECTED] PublicKey} instance.

or b2:

   * @param input
   *  the byte array to unmarshall into a valid DSS
  [EMAIL PROTECTED] PublicKey} instance.


TIA + cheers;
rsn


pgpdYCct1gRgY.pgp
Description: PGP signature

Re: [cp-patches] RFC: HTTPURLConnection fixlet

2006-02-04 Thread David Daney


Wolfgang Baer wrote:

Hi Chris,

Chris Burdess wrote:


Wolfgang Baer wrote:




Index: HTTPURLConnection.java
===
RCS file: /cvsroot/classpath/classpath/gnu/java/net/protocol/http/
HTTPURLConnection.java,v
retrieving revision 1.17
diff -u -r1.17 HTTPURLConnection.java
--- HTTPURLConnection.java20 Jan 2006 22:15:58 -1.17
+++ HTTPURLConnection.java4 Feb 2006 14:24:42 -
@@ -352,7 +352,6 @@
if (response.getCode() == 404)
  {
errorSink = responseSink;
-throw new FileNotFoundException(url.toString());
  }
  }
  }



Woah there. This was definitely there for a reason - I believe we are 
supposed to throw FileNotFoundException for a 404.



I looked a bit closer and found a FileNotFoundException being mentioned
in the getErrorStream method ...responds with a 404, which will cause a
FileNotFoundException to be thrown in connect

So its specified there but apparently (as the mauve test shows) it is
not done in the reference implementation. The question is what we should
do, following the api documentation of what the reference implementation does ?


After thinking about it a bit more (and reading Sun's API reference), I 
think that the exception should be thrown from getInputStream().  On any 
4??, 5?? response code getInputStream should throw an IOException.  On 
404 it should the FileNotFoundException.  Any time getInputStream() 
throws an exception because of a 4?? or 5?? status code, 
getErrorStream() must contain the response body if any.


connect() should only throw an exception if there are socket level 
IOExceptions.


I will update PR 26081 to reflect my new understanding.

David Daney.

Re: [cp-patches] DSSKeyPairGenerator JCE Adapter

Re: [cp-patches] Re: RFC: Remove default 'Expect 100-continue' usage in HTTP Requests

Re: [cp-patches] Patch: DefaultStyledDocument.ElementBuffer final fix

[cp-patches] FYI: JLayeredPane fixes / new Container methods

Re: [cp-patches] DSSKeyPairGenerator JCE Adapter

[cp-patches] Re: FYI: Fixup ChangeLog

Re: [cp-patches] DSSKeyPairGenerator JCE Adapter

Re: [cp-patches] RFC: Datatypes library

[cp-patches] RFC: HTTPURLConnection fixlet

[cp-patches] RFC: gnu.regexp: (?=X), (?!X), (?X) supported

Re: [cp-patches] RFC: HTTPURLConnection fixlet

Re: [cp-patches] Re: RFC: Remove default 'Expect 100-continue' usage in HTTP Requests

Re: [cp-patches] RFC: HTTPURLConnection fixlet

Re: [cp-patches] DSSKeyPairGenerator JCE Adapter

Re: [cp-patches] RFC: HTTPURLConnection fixlet

15 matches

Site Navigation

Mail list logo

Footer information