To use reflection on a class (which the JessDE will do now, because
it uses ReflectionClassResearcher), you have to load the class. That
means that if, say, you're editing a file that includes "(defclass
Foo Foo)", that your class Foo will be loaded into Eclipse. Normally,
this isn't a big deal, but what if that class does something weird in
its static init block -- like register itself as a JDBC driver or
something? A problem like this has actually already hit an existing
JessDE user.
Eclipse itself learns about library classes *not* by using
reflection, but with its own library that parses class files without
loading them. Eclipse developers are supposed to use this API rather
than reflection. So far, the JessDE doesn't do the right thing, but
soon it will.
Maybe the best thing to do would be to, instead of extending
ReflectionClassResearcher, to implement ClassResearcher and hold a
reference to the previous ClassResearcher; forward calls to it, then
modify and return the results. Make sense? That would work regardless
of the technology in use.
On Oct 25, 2007, at 5:17 PM, Wolfgang Laun wrote:
Can you rely on Jess ClassResearcher and whatever is used under
Eclipse
to always produce the same result?
Granted (and I do assume) that you can: What is the benefit of using
some JDE library function as compared to the ClassResearcher? It can't
be a performance issue, because obtaining the template definition from
a Java class is highly unlikely to be required frequently.
Which classes, exaclty, are "your classes" which won't be loaded
under the JessDE?
Thanks
Wolfgang
On 10/25/07, Ernest Friedman-Hill <[EMAIL PROTECTED]> wrote:
Interesting idea! I hadn't thought about ClassResearcher as a user
hook; It was introduced as a way to let Jess use reflection most of
the time, but use Eclipse's JDE libraries inside the JessDE so that
the JessDE doesn't actually load your classes. Therefore this must be
used cautiously because at some point it will break inside Eclipse
(although of course an Eclipse-specific version would also be
possible.)
On Oct 25, 2007, at 12:01 PM, Wolfgang Laun wrote:
> Deriving a deftemplate from a Java class with, e.g.,
> (deftemplate Account (declare (from-class Account)))
> invariably adds a slot "class", due to getClass() inherited from
> java.lang.Object.
>
> If you want to get rid of this, see the Jess userfunction I've
> added to the
> Jess Wiki: http://herzberg.ca.sandia.gov/jesswiki/view?
> NoClassSlotUserFunction
>
> Cheers,
> Wolfgang
>
---------------------------------------------------------
Ernest Friedman-Hill
Informatics & Decision Sciences Phone: (925) 294-2154
Sandia National Labs FAX: (925) 294-2234
PO Box 969, MS 9012 [EMAIL PROTECTED]
Livermore, CA 94550 http://www.jessrules.com
--------------------------------------------------------------------
To unsubscribe, send the words 'unsubscribe jess-users
[EMAIL PROTECTED]'
in the BODY of a message to [EMAIL PROTECTED], NOT to the list
(use your own address!) List problems? Notify owner-jess-
[EMAIL PROTECTED]
--------------------------------------------------------------------
---------------------------------------------------------
Ernest Friedman-Hill
Informatics & Decision Sciences Phone: (925) 294-2154
Sandia National Labs FAX: (925) 294-2234
PO Box 969, MS 9012 [EMAIL PROTECTED]
Livermore, CA 94550 http://www.jessrules.com
--------------------------------------------------------------------
To unsubscribe, send the words 'unsubscribe jess-users [EMAIL PROTECTED]'
in the BODY of a message to [EMAIL PROTECTED], NOT to the list
(use your own address!) List problems? Notify [EMAIL PROTECTED]
--------------------------------------------------------------------
