[Article] The Future of OSS Desktop Development: Java, Mono, or C++?
Sorry for keeping you from your productive work, but one recent article Java, Mono, or C++ referenced in OSNews is quite interesting and detailed. It mentions GNU Classpath, GCJ, and IKVM. The article Java, Mono, or C++: http://ometer.com/desktop-language.html The OSNews news item and discussion around it: http://www.osnews.com/story.php?news_id=6379 Cheers, Patrik Patrik Reali http://www.reali.ch/~patrik/ ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Java, Mono, or C++?
Hello Havoc, a very interesting article! I write this mail without having asked the others who work on GNU Classpath, but I think I can speak for everyone when I say that we all are glad about such thoughtful writings! Just a minor comment: There actually exist quite a variety of open-source JVMs, many more than were mentioned in your text. For an overview (basically a few bullet points for each VM), see e.g. the Classpath talk at last FOSDEM: http://www.dandelis.ch/people/brawer/articles/classpathFeb2004/ (The VM overview starts at page 24. Before, the talk tries to explain why we think that Java is a reasonable choice for free software, and tells about the current state of implementation). Personally, I'm not sure whether having so many VMs is good. But as you noted in your text, it doesn't really matter that much, because most development gets shared via GNU Classpath. Best regards, -- Sascha Sascha Brawer, [EMAIL PROTECTED], http://www.dandelis.ch/people/brawer/ ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: currentClassLoader problem
On the subject of VMClassLoader, I had to make some changes to
VMClassLoader.getSystemClassLoader to make it more correct. At least,
according to my reading of the spec.
In particular, I think a class loader specified by
java.system.class.loader has to be loaded with the default system
class loader, but Classpath doesn't do this.
I've appended my version of VMClassLoader.getSystemClassLoader.
It has some gcj-specific bits in it. I'd be curious to hear what
other people think...
Tom
static native ClassLoader getSystemClassLoaderInternal();
static ClassLoader getSystemClassLoader()
{
// This method is called as the initialization of systemClassLoader,
// so if there is a null value, this is the first call and we must check
// for java.system.class.loader.
String loader = System.getProperty(java.system.class.loader);
ClassLoader default_sys = getSystemClassLoaderInternal();
if (loader != null)
{
try
{
Class load_class = Class.forName(loader, true, default_sys);
Constructor c
= load_class.getConstructor(new Class[] { ClassLoader.class });
default_sys
= (ClassLoader) c.newInstance(new Object[] { default_sys });
}
catch (Exception e)
{
System.err.println(Requested system classloader
+ loader + failed, using
+ gnu.gcj.runtime.VMClassLoader);
e.printStackTrace();
}
}
return default_sys;
}
___
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath
RE: currentClassLoader problem
Tom, In particular, I think a class loader specified by java.system.class.loader has to be loaded with the default system class loader, but Classpath doesn't do this. Your reading is correct. In our system the externally defined system class loader must have our default system class loader as a parent otherwise it could never load a class in our system. I'm doing this by simply by passing the default loader as the parent in the constructor because at this stage of initialization Class.forName wouldn't work for us. David Holmes ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Sockets remain unclosed
With reference to
http://www.kaffe.org/pipermail/kaffe/2004-March/045645.html
I suggest the following patch, which I committed in Kaffe.
ChangeLog entry:
2004-03-17 Ito Kazumitsu [EMAIL PROTECTED]
* libraries/javalib/java/net/ServerSocket.java
(accept): Close the socket when error occured.
--- java/net/ServerSocket.java.orig Wed Feb 25 06:38:46 2004
+++ java/net/ServerSocket.java Thu Mar 18 07:34:01 2004
@@ -323,7 +323,21 @@
sm.checkListen (impl.getLocalPort ());
Socket socket = new Socket();
-implAccept (socket);
+try
+ {
+implAccept (socket);
+ }
+catch (IOException e)
+ {
+ try
+ {
+ socket.close ();
+ }
+ catch (IOException e)
+ {
+ }
+ throw e;
+ }
return socket;
}
___
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath
Re: currentClassLoader problem
Tom Tromey wrote:
On the subject of VMClassLoader, I had to make some changes to
VMClassLoader.getSystemClassLoader to make it more correct. At least,
according to my reading of the spec.
In particular, I think a class loader specified by
java.system.class.loader has to be loaded with the default system
class loader, but Classpath doesn't do this.
I've appended my version of VMClassLoader.getSystemClassLoader.
It has some gcj-specific bits in it. I'd be curious to hear what
other people think...
Your analysis seems correct to me.. ie, Classpath is erroneously
using the bootstrap loader instead of the default system class loader
as the loader and parent for the user-specified class loader.
Is is correct that getSystemClassLoaderInternal() is a gcj-specific
method? And why is native code needed, i.e., why can't you just
load an instance of gnu.java.lang.SystemClassLoader (or
gnu.gcj.runtime.VMClassLoader in gcj's case) using the bootstrap
loader, and then use it to load the user-specified class loader?
E.g. something like this (not handling exceptions here):
static ClassLoader getSystemClassLoader()
{
// Get default system class loader.
// Load class using bootstrap class loader.
String defaultLoaderClass = gnu.java.lang.SystemClassLoader);
ClassLoader systemClassLoader = Class.forName(defaultLoaderClass,
true, null).getConstructor(new Class[] { ClassLoader.class })
.newInstance(new Object[1]);
// Get user-specified system class loader class, if any
String loaderClass = System.getProperty(java.system.class.loader,
defaultLoaderClass);
// Replace system class loader with user-specified loader if different.
// Load class using default system class loader.
if (!loaderClass.equals(defaultLoaderClass))
{
systemClassLoader = Class.forName(loaderClass, true, systemClassLoader)
.getConstructor(new Class[] { ClassLoader.class })
.newInstance(new Object[] { systemClassLoader });
}
// Done
return systemClassLoader;
}
-Archie
__
Archie Cobbs *CTO, Awarix* http://www.awarix.com
___
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath
RE: currentClassLoader problem
Archie Cobbs wrote: Is is correct that getSystemClassLoaderInternal() is a gcj-specific method? And why is native code needed, i.e., why can't you just load an instance of gnu.java.lang.SystemClassLoader (or gnu.gcj.runtime.VMClassLoader in gcj's case) using the bootstrap loader, and then use it to load the user-specified class loader? Given that this all occurs at bootstrap time when the only pre-existing loader is the null bootstrap loader why not just instantiate the default system loader directly rather than using Class.forName? The construction will implicitly load the class using the internal VM mechanism associated with doing new. As I mentioned before I don't think Class.forName would actually work in our system at this stage of the game. David Holmes ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
