> The guidelines I've seen say that if two items are equal, then their
> hashcodes should match. If they are unequal, their hashcodes should not
> match.
>
> I have implemented the equals function like so:
>
> public boolean equals(Object that)
> {
> if (that == this)
> return true
Hi Jeff,
> I'm just beating on the KerberosPrincipal class, and am trying to deal
> the comments given by people.
>
> The problem I'm having is that I have a name string and a type int.
>
> This is the comment at the top of my equals function:
>
>* From Section 7.2 of rfc1510: When compari
Hi!
Today I have again run the example-programs from GNU Classpath and wondered,
that there is a bug, which I haven't recognised before.
In the AWT-Demo under "Random Tests" the Text "Hi Red!" is with JamVM and
GNU Classpath red. But with Suns Java 1.4, 1.5 and 1.6 under Windows and
Linux it
hello all,
here is a proposed plan for the move:
* create a gnu.classpath.crypto package hierarchy which will contain the
following (GNU Crypto) sub-packages:
- auth
- hash
- jce --renamed java
- key
- keyring
- pki
- prng --weak algos
- sasl
- sig
- util
* create a new sou
Michael Barker wrote:
Given that the toString() must be the same in order to be equal
Huh? I don't believe there is any such requirement. One would
normally expect toString to match for equal objects, but it is
not required. Atter all, the default toString will not satisfy
this requirement i
On Tue, 2005-12-27 at 10:26 -0800, Per Bothner wrote:
> Michael Barker wrote:
> > Given that the toString() must be the same in order to be equal
>
> Huh? I don't believe there is any such requirement. One would
> normally expect toString to match for equal objects, but it is
> not required. At
Michael Barker wrote:
>>From the equals() code, its applicable in this case:
// The toString output must match.
if (! toString().equals(((KerberosPrincipal)that).toString()))
return false;
In your message you did phrase things in terms of general contracts.
More to the point: U
Hi,
The closeDialog in BasicFileChooserUI has default access, and so can't be
accessed from MetalFileChooserUI. Is this intentional? If that functionality
is required (in particular, it seems appropriate to be able to make a
selection entirely from the fileTextField), is the correct thing to do to
Hi,
The following is a class I've developed to be added as an ActionListener to
the fileTextField component in a MetalFileChooserUI's ui for JFileChooser.
It implements the same (or at least very similar, right now) behavior to
Sun's file text field.
Please note: while I've sent my copyright assi
On Tue, 2005-12-27 at 11:14 -0800, Per Bothner wrote:
> Michael Barker wrote:
> >>From the equals() code, its applicable in this case:
> >
> > // The toString output must match.
> > if (! toString().equals(((KerberosPrincipal)that).toString()))
> > return false;
>
> In your messag
Chris Burdess wrote:
> We discovered over IRC that there is a major problem with XML parsing using
> the StAX driver, caused by a bug in BufferedInputStream. I'm therefore
> reverting the default XML parser to aelfred2 until this is resolved.
Further investigation revealed that the problem was mor
> "Chris" == Chris Lansdown <[EMAIL PROTECTED]> writes:
Chris> The closeDialog in BasicFileChooserUI has default access, and
Chris> so can't be accessed from MetalFileChooserUI. Is this
Chris> intentional?
According to the online javadoc, there is no public or protected
method named 'closeDia
--- Comment #4 from dog at gnu dot org 2005-12-27 20:14 ---
Please test with Classpath HEAD following fixes to the stream handling code in
the XML parser.
--
dog at gnu dot org changed:
What|Removed |Added
--
> "Robert" == Robert Schuster <[EMAIL PROTECTED]> writes:
Robert> I have worked on the XMLEncoder once more.
Unless you think there are potentially big design flaws, requiring a
lot of work to fix, I would say that it would be better to simply
check in what you have. This won't break anythin
> "Chris" == Chris Burdess <[EMAIL PROTECTED]> writes:
Chris> Note that the behaviour of BufferedInputStream is correct - but
Chris> that of BufferedReader is not.
Please file a PR for this.
Tom
___
Classpath mailing list
Classpath@gnu.org
http:/
> "Raif" == Raif S Naffah <[EMAIL PROTECTED]> writes:
>> I think we ought to change Mauve to use JUnit as well...
Raif> do you see this as a new module under the Mauve CVS, say "junit" or a
Raif> folder-hierarchy under the current "mauve" module?
I mean simply converting the whole mauve to
> ">" == theUser BL <[EMAIL PROTECTED]> writes:
>> In the AWT-Demo under "Random Tests" the Text "Hi Red!" is with JamVM
>> and GNU Classpath red. But with Suns Java 1.4, 1.5 and 1.6 under
>> Windows and Linux it is cyan!
I see this too. The demo sets XOR mode, which is somewhat odd.
Tom
On Dec 27, 2005, at 8:49 AM, Raif S. Naffah wrote:
hello all,
here is a proposed plan for the move:
* create a gnu.classpath.crypto package hierarchy which will
contain the
following (GNU Crypto) sub-packages:
- auth
- hash
- jce --renamed java
- key
- keyring
- pki
Don't mer
18 matches
Mail list logo
