I'm checking this in.
This adds a missing import.
Tom
2005-12-27 Tom Tromey [EMAIL PROTECTED]
* gnu/java/nio/SelectorImpl.java: Added import.
Index: gnu/java/nio/SelectorImpl.java
===
RCS file:
import java.io.File;
^
error: required type 'java.lang.Object' not found; check your class path
￾
^
batch/org/eclipse/jdt/internal/compiler/batch/FileFinder.java:13:0: error: type
named 'java.io.File' is undefined
import java.io.File;
^
error: required type 'java.lang.Object' not found;
--
1. ERROR in compiler/org/eclipse/jdt/core/compiler/CategorizedProblem.java
(at line 1)
/***
^
The type java.lang.Object cannot be resolved. It is indirectly referenced from
required .class
Baseline from: Wed Dec 28 03:22:15 UTC 2005
Regressions:
FAIL: Thread_Sleep -O3 output - bytecode-native test
FAIL: Thread_Sleep -O3 output - source compiled test
Totals:
PASS: 3376
XPASS: 0
FAIL: 2
XFAIL: 10
___
Classpath-testresults mailing list
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;
if
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 comparing
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 is
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
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
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. Atter
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:
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
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
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 message you did
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 more
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 'closeDialog' in
--- 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 anything (any
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
== 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
CVSROOT:/cvsroot/classpath
Module name:classpath
Branch:
Changes by: Tom Tromey [EMAIL PROTECTED] 05/12/27 08:32:12
Modified files:
. : ChangeLog
gnu/java/nio : SelectorImpl.java
Log message:
* gnu/java/nio/SelectorImpl.java:
CVSROOT:/cvsroot/classpath
Module name:classpath
Branch:
Changes by: Chris Burdess [EMAIL PROTECTED] 05/12/27 19:56:16
Modified files:
. : ChangeLog
gnu/java/net : CRLFInputStream.java
gnu/xml/stream : SAXParser.java
23 matches
Mail list logo
