Tom Tromey wrote:
> Jeroen> Another interesting trick with the finalizer is creating
> Jeroen> instances of classes that have a private constructor! The
> Jeroen> attached runtime.j creates an instance of (a subclass of)
> Jeroen> java.lang.Runtime.
>
> Interesting test case.
>
> With gij this pr
> serialization is more interesting to you then check out 'serialize'
> and 'serialcompat' parts of japitools. We should check serialized
> compatibility with 1.1 through current releases.
Ok. Will do that.
Thanks.
Bhun.
___
Classpath mailing list
Hi,
Great job, this is almost exactly like I envisioned it. A few minor
suggestions:
- FileOutputStream should not request read access, so the modes should
be "w" and "a"
- write(byte[] buf, long offset, long length) should not use longs for
offset and length
- nativeReadByte shouldn't return a l
Hi Brian,
I will attempt to answer some of your questions. Dr. Rupp will probably correct
any error I make in my answers.
I'm confused about when to worry about this. Does it matter for
synchronized methods?
Yes, as the system/library call you are doing might also be done by *another*
method
> "Jeroen" == Jeroen Frijters <[EMAIL PROTECTED]> writes:
Jeroen> Sun's ClassLoader has a hack that prevents this from being exploitable:
Jeroen> http://www.securingjava.com/chapter-five/chapter-five-8.html
Sounds like we need this in ClassLoader and in any other class that
performs security
Jeroen Frijters ([EMAIL PROTECTED]) wrote:
> Great job, this is almost exactly like I envisioned it. A few minor
> suggestions:
Thanks.
> - FileOutputStream should not request read access, so the modes should
> be "w" and "a"
Good observation. Have you actually tested the JDK to see what it
do
"Jeroen Frijters" <[EMAIL PROTECTED]> writes:
> Hi,
>
> Attached is a patch for object serialization, to use the proper classes
> when getting and setting fields in the object (and when calling
> readObject/writeObject). Also some minor changes to make caching the
> Field and Method objects possi
"Jeroen Frijters" <[EMAIL PROTECTED]> writes:
> Hi,
>
> I made another attempt at reducing the number of ClassNotFoundExceptions
> that are thrown when loading a class, this time I believe the patch can
> be integrated without breaking anything. No API changes and existing
> code should continue
> "Dalibor" == Dalibor Topic <[EMAIL PROTECTED]> writes:
>> java.util.zip.[De|In]flater both have an empty finalize method "for
>> compatibility". Is this really necessary?
Dalibor> Yes, in order to have reflection on these methods
Dalibor> working. A pretty good reason in my opinion.
I'm no
Ok, moving on in the gcj/classpath merger.
1. I'm thinking we should adopt the gcj LineNumberReader. It appears to
be more efficient. However, skip() is definitely buggy (inserting regular
skip()'s into your code leads to more lines than the file actually has).
All Mauve tests pass, so I'll try
Hi,
Aaron M. Renn wrote:
> Jeroen Frijters ([EMAIL PROTECTED]) wrote:
> > - FileOutputStream should not request read access, so the
> modes should
> > be "w" and "a"
>
> Good observation. Have you actually tested the JDK to see what it
> does in this situation? Is the file actually opened "wri
> Aaron M. Renn wrote:
> > Jeroen Frijters ([EMAIL PROTECTED]) wrote:
> > > - FileOutputStream should not request read access, so the=20
> > modes should
> > > be "w" and "a"
> >=20
> > Good observation. Have you actually tested the JDK to see what it
> > does in this situation? Is the file actu
I was trying to debug a GTK peer crash with kissme and TestAWT, but
while investigating this I noticed some strange behaviour for the Dialog
window.
Running this on the linux JDK from IBM and also on a Windows machine, I
noticed that you have to push the OK button twice to close the Dialog
window.
> "John" == John Leuner <[EMAIL PROTECTED]> writes:
John> Running this on the linux JDK from IBM and also on a Windows machine, I
John> noticed that you have to push the OK button twice to close the Dialog
John> window.
John> Has anyone else seen this?
The peers have all kinds of bugs. This
14 matches
Mail list logo