12:51 p.m.
Would like to share this excellent article with Drools and JBPM
developers...
http://blog.osgi.org/2011/05/what-you-should-know-about-class.html
cheers,
Cristiano
4:23 p.m.
Some things cause other problems:
"Class.forName is Evil - Class.forName will pin classes in memory forever (almost,
but long enough to cause problems). If you're forced to do dynamic class loading use
ClassLoader.loadClass instead. All variations of the Class.forName suffer from the same
problem. See BJ Hargrave's blog about this."
There is a bug in JDK which means that serialisation will not work with String[] when
using loadClass, and Class.forName must be used:
http://bugs.sun.com/view_bug.do?bug_id=6434149
We hit this, and had to move all our stuff to Class.forName.
Mark
On 16 Apr 2013, at 18:51, Cristiano Gavião <cvgaviao(a)gmail.com> wrote:
Would like to share this excellent article with Drools and JBPM
developers...
http://blog.osgi.org/2011/05/what-you-should-know-about-class.html
cheers,
Cristiano
_______________________________________________
rules-dev mailing list
rules-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
12:36 p.m.
Well, I could find only a few places where the Class.forName() with the
array parameter is needed.
Probably the tip number 6 - Centralize would help with that.
2013/4/16 Mark Proctor <mproctor(a)codehaus.org>
Some things cause other problems:
*"Class.forName is Evil* - Class.forName will pin classes in memory
forever (almost, but long enough to cause problems). If you're forced to do
dynamic class loading use ClassLoader.loadClass instead. All variations of
the Class.forName suffer from the same problem. See BJ Hargrave's blog
about
this<http://blog.bjhargrave.com/2007/09/classforname-caches-defined-cl...
."
There is a bug in JDK which means that serialisation will not work with
String[] when using loadClass, and Class.forName must be used:
http://bugs.sun.com/view_bug.do?bug_id=6434149
We hit this, and had to move all our stuff to Class.forName.
Mark
On 16 Apr 2013, at 18:51, Cristiano Gavião <cvgaviao(a)gmail.com> wrote:
Would like to share this excellent article with Drools and JBPM
developers...
http://blog.osgi.org/2011/05/what-you-should-know-about-class.html
cheers,
Cristiano
_______________________________________________
rules-dev mailing list
rules-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
_______________________________________________
rules-dev mailing list
rules-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
--
"Tudo vale a pena se a alma não é pequena..."
1:37 p.m.
Hopefully not too off-topic here. The most interesting thing I found from
BJ Hargrave's blog (
http://blog.bjhargrave.com/2007/09/classforname-caches-defined-class-in.html)
(thanks for linking to that) was a comment that basically refutes him.
That comment quotes a Sun source:
*Applications should basically never call Classloader.loadClass(). It may
appear to work but it is often subtly wrong, can be a source of latent
bugs, and is almost never the best choice. They should instead call
Class.forName() using the 3 parameter version that takes a specific
Classloader instance.*
*
*
Anyway, I found that very interesting indeed; I now use
Class.forName("someName", true /* most times */,
Thread.currentThread().getContextClassLoader()). Note that if for some
crazy reason the TCCL is null then the calling classloader will be used
instead.
Best,
Laird
On Wed, Apr 17, 2013 at 10:36 AM, Cristiano Gavião <cvgaviao(a)gmail.com>wrote:
Well, I could find only a few places where the Class.forName() with
the
array parameter is needed.
Probably the tip number 6 - Centralize would help with that.
2013/4/16 Mark Proctor <mproctor(a)codehaus.org>
> Some things cause other problems:
> *"Class.forName is Evil* - Class.forName will pin classes in memory
> forever (almost, but long enough to cause problems). If you're forced to do
> dynamic class loading use ClassLoader.loadClass instead. All variations of
> the Class.forName suffer from the same problem. See BJ Hargrave's blog
> about
this<http://blog.bjhargrave.com/2007/09/classforname-caches-defined-cl...
> ."
>
> There is a bug in JDK which means that serialisation will not work with
> String[] when using loadClass, and Class.forName must be used:
> http://bugs.sun.com/view_bug.do?bug_id=6434149
>
> We hit this, and had to move all our stuff to Class.forName.
>
> Mark
>
> On 16 Apr 2013, at 18:51, Cristiano Gavião <cvgaviao(a)gmail.com> wrote:
>
> Would like to share this excellent article with Drools and JBPM
> developers...
>
> http://blog.osgi.org/2011/05/what-you-should-know-about-class.html
>
> cheers,
>
> Cristiano
> _______________________________________________
> rules-dev mailing list
> rules-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-dev
>
>
>
> _______________________________________________
> rules-dev mailing list
> rules-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-dev
>
--
"Tudo vale a pena se a alma não é pequena..."
_______________________________________________
rules-dev mailing list
rules-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
--
http://about.me/lairdnelson
4272
days inactive
4273
days old
3 comments
3 participants
participants (3)
-
Cristiano Gavião -
Laird Nelson -
Mark Proctor