Andrew Haley aph at redhat.com writes:
No, I don't mean that. I mean that if we change this behaviour today,
we can't guarantee that someone won't chnage it back tomorrow.
So, use this as a temporary hack if you must, but prepare to be
disappointed.
So are you saying you'd oppose the
Andrew Haley aph at redhat.com writes:
No, that's not what I mean by illegal. It's illegal in the sense that
the specification places requirements on the implementors of
subclasses, and that a subclass which does not meet these requirements
is not a well-defined Java program.
public class
Roman Kennke [EMAIL PROTECTED] writes:
The attached patch adds support for CSS borders. This implementation is
actually much better than Sun's because it not only recognizes the
border-width attribute (which Sun doesn't, except for 0 and 1 borders),
it also recognizes the border-top-width,
Tom Tromey tromey at redhat.com writes:
If it is a bogus test, please remove it.
Thanks.
Wouldn't it be better to modify the test to test that the outcome *is* whatever
the RI gives in whatever the situation is?
Stuart.
Tom Tromey tromey at redhat.com writes:
I'm not sure this is really ready to go in. Perhaps I need to
preserve the old ;-stripping code... I will do that.
Possibly stupid question: Could a Mauve test determine whether this is necessary
or not? Presumably the behavior of Sun's implementation in
Hmm, and it didn't actually work in Japi for some reason anyway. I'll
investigate.
Stuart.
--
http://sab39.dev.netreach.com/
Tom Tromey tromey at redhat.com writes:
- public boolean getBoolean(SynthContext ctx, Object key, boolean
defaultValue
-throws NotImplementedException
+ /**
+ * A convenience method to fetch an integer property.
+ * If the property's value is a { at link Boolean}, then the
That
On 3/19/06, Stuart Ballard [EMAIL PROTECTED] wrote:
As far as I can figure out, an annotation is pretty much the only way
to get these kinds of methods to get flagged by Japi.
Actually, I figured out (and implemented in Japi) a place where we can
carry a flag on any method without requiring 1.5
On 3/20/06, Andrew John Hughes [EMAIL PROTECTED] wrote:
It sounds like a bad hack on the JAPI side, but it's up to you if you're
maintaining this.
True enough, but I think the problem of stub-inflated japi reports is
important enough to try to find some way of tackling it. Obviously an
On 3/19/06, Andrew John Hughes [EMAIL PROTECTED] wrote:
I think the interface problem you mention is the most obvious, but I
think this should be solvable by declaring the class abstract (which
shows up in JAPI too).
It's a shame that we can't use annotations on the trunk; it wouldn't
be hard
On 3/19/06, Andrew John Hughes [EMAIL PROTECTED] wrote:
I'm only thinking about this for interfaces, where e.g. part of the
interface is implemented, the rest is stubbed. You remove the stubs,
and declare the rest abstract so it will at least compile (and be
comparable). Yes, it will break
Andrew John Hughes A.Hughes at dcs.shef.ac.uk writes:
There seem to be an awful lot of 'missing' classes on this reverse
JAPI run. Presumably, these are not missing, but we are wrongly
exposing them in GNU Classpath?
That's pretty much right. You have to read the results backwards in this
Thomas Fitzsimmons fitzsim at redhat.com writes:
Would it be wrong to just remove them?
One thing I'd like to do once the generics branch becomes the main development
trunk is to scan the source for FIXME, Not Implemented, etc and add a @Fixme or
@Stub or @NotImplemented or something annotation
Stuart Ballard [EMAIL PROTECTED]
* java/util/zip/ZipConstants.java
(LOCSIG): Change type to long.
(EXTSIG): Likewise.
(CENSIG): Likewise.
(ENDSIG): Likewise.
* javax/swing/undo/StateEditable.java
(writeLeInt): New overload with parameter as long.
--
http
D'oh, screwed up the changelog (can you tell I copy and pasted it from
my previous patch?)
Obviously should have been:
2006-02-20 Stuart Ballard [EMAIL PROTECTED]
* java/util/zip/ZipConstants.java
(LOCSIG): Change type to long.
(EXTSIG): Likewise.
(CENSIG): Likewise
Mark Wielaard mark at klomp.org writes:
The problem is that some runtimes (like cacao and jamvm) dynamically
load the javalang reference library through System.loadLibrary(). But
we were relying on Math to do this since obviously it cannot be done in
(VM)System/Runtime directly while those are
;)
Here's the changelog to go along with the patch, anyway. I updated the
comments in the patch to reflect that the value has never changed in
Sun's releases.
2006-02-10 Stuart Ballard [EMAIL PROTECTED]
* javax/swing/undo/StateEdit.java (RCSID): Match Sun's value.
* javax/swing/undo
RTFP ;)
On 2/10/06, Michael Koch [EMAIL PROTECTED] wrote:
On Fri, Feb 10, 2006 at 05:33:37PM +, David Gilbert wrote:
FWIW, I'm in favour of committing this patch...
Note that you need to disable CVS keyword substitiution. Otherwise value
of the RCSID will change on every commit of this
the string directly
would be better, then by all means let's do that instead.
Stuart.
On 2/10/06, Michael Koch [EMAIL PROTECTED] wrote:
On Fri, Feb 10, 2006 at 02:50:32PM -0500, Stuart Ballard wrote:
RTFP ;)
hmmm, you are right. I would prefer the disbaled to make at least the
definition
On 12/11/05, Guilhem Lavaux [EMAIL PROTECTED] wrote:
Bah ! I would rather use a native function that will throw directly
InvalidClassException. The problem is that's will be anyway hidden to
the general user and that he/she may be surprised getting that sort of
exception.
I dunno, this seems
Why not do similar and throw the InvalidClassException from
ObjectStreamClass.lookup()?
(But then document that clearly in our version of course.)
Because we would not have the same API. ObjectStreamClass.lookup may not
throw any exception (except the default ones like Error, NPE, ...).
Anthony Balkissoon abalkiss at redhat.com writes:
JAPI pointed out that this method ( at since 1.5) wasn't implemented so I
wrote it.
JAPI also said that Boolean.compareTo(Object) is missing, but I don't
believe that's actually in the JDK library. It's not in the specs and a
testcase I
[snip]
+Lillian Angel (langel at redhat.com)
Stuart Ballard (stuart.ballard at mcmail.com)
Mark Benvenuto (mcb54 at columbia.edu)
Hmm, that email address for me hasn't worked in years. I don't mind being
removed from AUTHORS completely since I haven't done any actual coding on
classpath
Thomas Fitzsimmons fitzsim at redhat.com writes:
I added the two missing methods to ImageReaderWriterSpi. Now
javax.imageio.spi is 1.5-complete.
2005-10-24 Thomas Fitzsimmons fitzsim at redhat.com
* javax/imageio/spi/ImageReaderWriterSpi.java
(getStreamMetadataFormat):
the JDK
- my concern is whether *more* work is needed here to cover all the
cases).
Here's a changelog for the RMI one (hope I got the format right):
2005-10-04 Stuart Ballard [EMAIL PROTECTED]
* java/rmi/LoaderHandler.java (packagePrefix): Match Sun's value.
* java/rmi
On 10/5/05, Jeroen Frijters [EMAIL PROTECTED] wrote:
Stuart Ballard wrote:
Not that it matters much, but I didn't see any changes from 1.3 to 1.4
to 1.5, and given the fact that the dates are both in 1997, I assumed it
was just a historical thing.
The values in the japi results are different
26 matches
Mail list logo
