Hi there,
Jeroen Frijters schrieb:
Roman Kennke wrote:
What about
|| (l == VMClassLoader.getSystemClassLoader())
instead ?
You shouldn't call VMClassLoader.getSystemClassLoader() (it creates a
new instance of the system class loader), but apart from that comparing
against the system class
Hi there again,
What about this pending patch? I didn't quite understand the discussion
around it. IMO the file handling is very platform dependend and while we
could handle this generically, I find this path very inconvenient, as it
clutters the code, where it could be easy, and it certainly
Roman Kennke wrote:
Jeroen Frijters schrieb:
Roman Kennke wrote:
What about
|| (l == VMClassLoader.getSystemClassLoader())
instead ?
You shouldn't call VMClassLoader.getSystemClassLoader() (it
creates a
new instance of the system class loader), but apart from
that comparing
Roman Kennke wrote:
What about this pending patch?
I certainly would like to see it go.
Regards,
Jeroen
Hi,
Jeroen Frijters schrieb:
Roman Kennke wrote:
What about this pending patch?
I certainly would like to see it go.
Ok. Dalibor also expressed that he'd like to see it in. So here it goes.
2006-08-21 Roman Kennke [EMAIL PROTECTED]
* java/io/File.java
(getAbsolutePath):
I'm committing this on behalf of Ingo. He implemented a caching
mechanism in InputStreamReader to avoid allocation of new byte[] on
every call of read(byte[],int,int).
2006-08-21 Ingo Proetel [EMAIL PROTECTED]
* java/io/InputStreamReader.java
(bytesCache): New field.
This changes the CSSScanner to compare the ints directly, rather then
casting to char everytime. Now it only casts to char when putting the
char into the char[] buffer.
2006-08-21 Roman Kennke [EMAIL PROTECTED]
* gnu/javax/swing/text/html/css/CSSScanner.java
(main): Use
Hi,
I committed the attached patch to fix the handling of paths consisting
only of a double separator character. Our normalization would previously
turn this into an empty string, instead of a single separator character.
This happened both on Windows and on *nix.
Regards,
Jeroen
2006-08-21
Jeroen Frijters wrote:
There are several places in our codebase were we need/want to cache
stuff that is associated with a class or class loader. Currently these
places retain a strong reference to the class loader, which is not
correct, because the class loader should be garbage collectable.
Jeroen Frijters wrote:
Archie Cobbs wrote:
Dumb question.. why wouldn't it work to just use a
WeakHashMap instead of a HashMap in all those places?
Not a dumb question at all. That *would* work. The problem
is that (at least on some runtimes) WeakHashMap is much more
expensive than
Hey,
The application JabRef was not even starting on Classpath. This patch
enables it to start up. However, it seems to freeze once that happens.
It still needs some work.
Could someone kindly approve this patch so that I may commit it.
Thanks!
Tania
2006-08-21 Tania Bento [EMAIL
Roman Kennke wrote:
This fixes two little issues that I had when porting the LocalSocketImpl
to JamaicaVM:
- It only loads the library dynamically when actually supported by the
runtime.
- It includes config.h unconditionally. Actually it doesn't seem to make
sense to do:
#if
On Sun, 2006-08-20 at 18:12 -0700, Casey Marshall wrote:
Since this finally cleans up the target layer stuff I would like this to
go in now and then we build on this for your further improvements to NIO
and the socket timeouts. OK?
OK. Since I'm working off of cvs head I'm probably
Hey Tania,
On Mon, 2006-08-21 at 15:00 -0400, Tania Bento wrote:
The application JabRef was not even starting on Classpath. This patch
enables it to start up. However, it seems to freeze once that happens.
It still needs some work.
Cool. CCed Egon who was interested JabRef.
Could one of you
Roman Kennke wrote:
Hi there again,
What about this pending patch? I didn't quite understand the discussion
around it. IMO the file handling is very platform dependend and while we
could handle this generically, I find this path very inconvenient, as it
clutters the code, where it could be
15 matches
Mail list logo
