Hi all,
FYI, I've now checked gnu.classpath.ServiceFactory into cvs. Its purpose
is to load plug-in services that are specified via META-INF/services
resources (usually located in JAR files in the VM's extension directory).
By default, services will be loaded via the calling thread's context
Am Mittwoch, 24. März 2004 09:27 schrieb Sascha Brawer:
Hi all,
FYI, I've now checked gnu.classpath.ServiceFactory into cvs. Its
purpose is to load plug-in services that are specified via
META-INF/services resources (usually located in JAR files in the VM's
extension directory). By default,
Yes, I agree (but see my comment below). Iin fact, I suggested moving
findLoadedClass to the VMClassLoader in my last post. The next release of
JamVM, which should be out tonight, will have this. This means releasing a
modified ClassLoader as a VM class but it'll be a while before this makes
David Holmes wrote:
[...]
I fill in user.timezone during insertSystemProperties at the same time as
all the other dynamic properties that have to be obtained from the OS: file
encoding, user name, os name, current dir etc etc.
Jikes RVM sets those in runrvm, a shell script that calls the actual
C
This makes sense, yes. Now I know why I want to set it; my test program
that calls TimeZone.getDefault().getDisplayName() always prints Greenwich
Mean Time if I don't.
Thanks for the information -- something I should do in JamVM as well.
However, the above explains why I've never noticed the
David Holmes wrote:
[...]
http://java.sun.com/j2se/1.4.2/docs/guide/extensions/index.html
[...]
When the VM starts up it should create the extensions classloader, with the
bootstrap loader as parent, then create the system/application class loader
with the extensions loader as parent.
This is
Robert Lougher wrote:
This makes sense, yes. Now I know why I want to set it; my test
program that calls TimeZone.getDefault().getDisplayName() always
prints Greenwich Mean Time if I don't.
Thanks for the information -- something I should do in JamVM as well.
However, the above explains why
Aaron M. Renn wrote:
Can I just say Wow!? That is super cool. It's fantastic to see
actual Swing screens.
I can add another teaser from the branch. olga rodimina has chased down
most of the major rendering, geometry, and image transfer bugs in our
native Graphics2D (cairo) backend. as a
http://people.redhat.com/~graydon/free-swing-mar-23-2004.png
OK SableVM guys! I'd like to see this in SableVM's staging tree *now*!
To get get SableVM staging to work out-of-the-box with
a Classpath CVS, using:
$ # [go to classpath working copy]
$ cd classpath
$ ./configure --with-vm=sablevm
Steven Augart wrote:
David Holmes wrote:
Also note that once you start playing this game the role of the context
classloader for a thread becomes much more important :)
I assume that's for the applications programmers to worry about, no?
Or are there particular gotchas for the VM?
The
This makes sense, yes. Now I know why I want to set it; my test program
that calls TimeZone.getDefault().getDisplayName() always prints
Greenwich Mean Time if I don't.
Our MAC OSX users suffer the same problem :-) OSX doesn't support the OSI
extensions so I have no idea how to obtain the
Robert Lougher wrote:
Yes, I agree (but see my comment below).
...
A pure Java reference implementation won't work. At the Java level
VMClassLoader can only keep track of classes defined by a loader (when it
calls VMClassLoader.defineClass). A call back will be needed so
that the VM can
I assume your VM is implemented in C or C++, based on your discussion
of the OSI extensions. In that case, how 'bout strftime() with the %Z
format? If you set user.timezone to the string that strftime( ...,
%Z, ...) generates, Classpath's java.util.TimeZone will do the right
thing when it
13 matches
Mail list logo
