Classloaders are implemented the right way. So don't change this (The exception messages could be improved though).
Ack. The classloader architecture is one of the most poorly designed and inconsistently implemented parts of Java. The problem is that almost no one has to delve that deep into the doo-doo to get things done.
However, if you're unlucky enough to be building an enterprise server architecture that requires separate classloaders (to avoid the JAR-version-hell of the classpath) get ready for fun:
Half of the APIs in Java don't correctly use classloaders when they should. For example, when initializing the security API, you can't pass in a classloader - Java assumes that you will be using the standard classpath. WRONG!
Statics allocated in classes are NOT garbage collected when the classloader is destroyed. So, if you use a classloader to manage your resources and allow a graceful stop and restart, all of your strings, objects, what have you will never get GCd. UNBELIEVABLY WRONG!
The list goes on and on...
As I said, the only reason that people believe the classloader API isn't broken is that they probably haven't had to use it. It needs serious help, above and beyond the ridiculously pervasive classpath issues.
Carl Sagan talks at length about exactly this issue in "The Demon Haunted World: Science as a Candle in the Dark". Specifically, he talks about the rise of pseudoscience, and the roles of education and ignorance in people's beliefs.
This book, tied with studies like the one referred to in this article, make my stomach turn. We should all make an effort to get in front of our respective scholastic representatives and volunteer to help in any way we can. After all, we are probably one of the largest groups of pro-science/education people around.
Unfortunately, we also seem to be one of the most apathetic.:(
I think that this is an instance of an unclear question. The question is not "Is it possible to implement functional languages in.Net?", but rather, "Do the bytecode primitives efficiently support execution of functional language primitives?"
You might be able to implement a functional language interpreter supporting closures, lazy evaluation, etc., in the standard bytecode, but that's not the point. The point of the CLI is to effectively support efficient execution of programs written in ANY language. Therefore, writing another layer on top of the bytecode to support features unique to functional languages eliminates many advantages functional languages provide, and can potentially disallow correct execution of complex functional programs.
So, if the bytecode representation was designed to support object-oriented languages, it's probable that it WILL NOT efficiently support recursion and partial evaluation. This is the crux of the argument, and why people are concerned with the existing bytecode spec.
There is a lot of work being done in this area, though, so there is hope that this will be resolved. After all, Microsoft does have some of the best minds in functional programming thinking about the problem.
Slashdot Mirror
Ack. The classloader architecture is one of the most poorly designed and inconsistently implemented parts of Java. The problem is that almost no one has to delve that deep into the doo-doo to get things done.
However, if you're unlucky enough to be building an enterprise server architecture that requires separate classloaders (to avoid the JAR-version-hell of the classpath) get ready for fun:
As I said, the only reason that people believe the classloader API isn't broken is that they probably haven't had to use it. It needs serious help, above and beyond the ridiculously pervasive classpath issues.
Carl Sagan talks at length about exactly this issue in "The Demon Haunted World: Science as a Candle in the Dark". Specifically, he talks about the rise of pseudoscience, and the roles of education and ignorance in people's beliefs.
:(
This book, tied with studies like the one referred to in this article, make my stomach turn. We should all make an effort to get in front of our respective scholastic representatives and volunteer to help in any way we can. After all, we are probably one of the largest groups of pro-science/education people around.
Unfortunately, we also seem to be one of the most apathetic.
I think that this is an instance of an unclear question. The question is not "Is it possible to implement functional languages in .Net?", but rather, "Do the bytecode primitives efficiently support execution of functional language primitives?"
You might be able to implement a functional language interpreter supporting closures, lazy evaluation, etc., in the standard bytecode, but that's not the point. The point of the CLI is to effectively support efficient execution of programs written in ANY language. Therefore, writing another layer on top of the bytecode to support features unique to functional languages eliminates many advantages functional languages provide, and can potentially disallow correct execution of complex functional programs.
So, if the bytecode representation was designed to support object-oriented languages, it's probable that it WILL NOT efficiently support recursion and partial evaluation. This is the crux of the argument, and why people are concerned with the existing bytecode spec.
There is a lot of work being done in this area, though, so there is hope that this will be resolved. After all, Microsoft does have some of the best minds in functional programming thinking about the problem.
For more information, see:
http://research.microsoft.com/~dsyme
http://www.research.microsoft.com/~emeijer
http://www.mondrian-script.org
- j