Eclipse and dynamic code: Not the current but an old class is used.

Discussion in 'Java' started by Ulrich Scholz, Dec 5, 2005.

  1. Dear all,

    my project dynamically generates a Java-file, compiles it, and creates
    an object of that type. Unfortunately, it seems that the eclipse sdk
    does not realize that the class file changed and sometimes generates
    objects of an older version of the class, usually the one of the last
    run.

    How can I make eclipse always use the current class?

    Is this a problem of eclipse or of Java, i.e., will I have a similar
    problem by using the Java virtual machine w/o eclipse?

    Thank you,

    Uli
     
    Ulrich Scholz, Dec 5, 2005
    #1
    1. Advertising

  2. Ulrich Scholz

    Chris Smith Guest

    Ulrich Scholz <> wrote:
    > my project dynamically generates a Java-file, compiles it, and creates
    > an object of that type. Unfortunately, it seems that the eclipse sdk
    > does not realize that the class file changed and sometimes generates
    > objects of an older version of the class, usually the one of the last
    > run.
    >
    > How can I make eclipse always use the current class?


    Once a Java virtual machine loads a class, that class cannot change for
    the remainder of the application. Overwriting a class file that's in
    use is dangerous, but will probably do nothing.

    If you need to load newly generated code, then you will need to create a
    new ClassLoader, which will then be able to load the new class in that
    new ClassLoader.

    --
    www.designacourse.com
    The Easiest Way To Train Anyone... Anywhere.

    Chris Smith - Lead Software Developer/Technical Trainer
    MindIQ Corporation
     
    Chris Smith, Dec 5, 2005
    #2
    1. Advertising

  3. Ulrich Scholz

    Roedy Green Guest

    On Mon, 5 Dec 2005 12:34:45 -0700, Chris Smith <>
    wrote, quoted or indirectly quoted someone who said :

    >Once a Java virtual machine loads a class, that class cannot change for
    >the remainder of the application. Overwriting a class file that's in
    >use is dangerous, but will probably do nothing.
    >
    >If you need to load newly generated code, then you will need to create a
    >new ClassLoader, which will then be able to load the new class in that
    >new ClassLoader.


    The other simpler way to do it is to have the class implement some
    fixed interface, and give the class a new name each time you generate
    it.
    --
    Canadian Mind Products, Roedy Green.
    http://mindprod.com Java custom programming, consulting and coaching.
     
    Roedy Green, Dec 5, 2005
    #3
  4. Re: Eclipse and dynamic code: Not the current but an old class isused.

    Roedy Green wrote:
    >
    > The other simpler way to do it is to have the class implement some
    > fixed interface, and give the class a new name each time you generate
    > it.


    Probably somewhat faster than creating a new ClassLoader every time, but
    it will leak.

    Tom Hawtin
    --
    Unemployed English Java programmer
    http://jroller.com/page/tackline/
     
    Thomas Hawtin, Dec 5, 2005
    #4
  5. Ulrich Scholz

    Roedy Green Guest

    On Mon, 05 Dec 2005 21:09:45 +0000, Thomas Hawtin
    <> wrote, quoted or indirectly quoted someone
    who said :

    >Probably somewhat faster than creating a new ClassLoader every time, but
    >it will leak.


    Technically it is not a leak, but correct, the method code for the old
    versions will never be garbage collected.

    see http://mindprod.com/jgloss/leak.html
    http://mindprod.com/jgloss/packratting.html
    --
    Canadian Mind Products, Roedy Green.
    http://mindprod.com Java custom programming, consulting and coaching.
     
    Roedy Green, Dec 5, 2005
    #5
  6. Re: Eclipse and dynamic code: Not the current but an old class isused.

    Roedy Green wrote:
    > On Mon, 05 Dec 2005 21:09:45 +0000, Thomas Hawtin
    > <> wrote, quoted or indirectly quoted someone
    > who said :
    >
    >
    >>Probably somewhat faster than creating a new ClassLoader every time, but
    >>it will leak.

    >
    >
    > Technically it is not a leak, but correct, the method code for the old
    > versions will never be garbage collected.


    Okay, object lifetime contention issues.

    > see http://mindprod.com/jgloss/leak.html
    > http://mindprod.com/jgloss/packratting.html


    I suspect some of your examples may be out of date. Not sure. AWT and
    Swing are such a mess.

    My favorite example is a ThreadLocal assigned to a static variable of
    class with the same class loader as a class referenced by the value
    (following? - the normal case for ThreadLocal), causes the the class
    loader with all its classes to become ineligible for collection. Sun
    refuses to fix that one.

    Tom Hawtin
    --
    Unemployed English Java programmer
    http://jroller.com/page/tackline/
     
    Thomas Hawtin, Dec 6, 2005
    #6
  7. Thanks for your explanation. It points me to another problem that I
    will have in the future (right now, I haven't gotten so far).

    >Once a Java virtual machine loads a class, that class cannot change for
    >the remainder of the application.


    I have to change that class once in a while. Now I know that I cannot
    just overwrite the .java file. Would it be a solution to use the
    defineClass method, i.e., would the following guaranteed always crate
    an instance of the new .java file? Are there backdraws?

    - write the .java file to the file system and compile it
    - load the new .class file into a byte array b
    - Class newClass = defineClass(" .... .MyType", b, 0, b.length());
    - MyType MyObject = newClass.newInstance();

    Thank you, Uli
     
    Ulrich Scholz, Dec 6, 2005
    #7
  8. Ulrich Scholz

    Chris Uppal Guest

    Ulrich Scholz wrote:

    > I have to change that class once in a while. Now I know that I cannot
    > just overwrite the .java file. Would it be a solution to use the
    > defineClass method, i.e., would the following guaranteed always crate
    > an instance of the new .java file?


    To be able to define a new version of a class you /HAVE/ to use a new
    Classloader. It's that simple and there are no exceptions.

    So you start off with classloader #1 which is used to load the first version of
    your code. If you then decide you need a new version of that code, you will
    have to discard the orginal classloader, create a new one, classsloader #2, and
    use that to load the next version of your class. If you want to redefine your
    class again then you'll have to create classloader #3. And so on.

    Note very carefully that introducing a new definition of a class via a new
    classloader does not, in itself, remove the old one. The old one will only go
    away when there are no more references to that class, or to the classloader, or
    to any other class loaded by that classloader.

    Even more importantly, you must realise that instantances of the old class are
    not changed to become instances of the new version. So changing the class
    definition (or more acurately defining a new class with the same name) will not
    change the behaviour of existing objects.

    -- chris
     
    Chris Uppal, Dec 6, 2005
    #8
  9. > To be able to define a new version of a class you /HAVE/ to use a new
    > Classloader.


    OK, I got that!

    Will the objects of two different classes with same class name
    (generated by separate class loaders) have the same type? In other
    words, if both have a function foo with the same signature, can I store
    instances of both classes one after the other in the same variable and
    call that function? So, does the following work:

    MyClass class;
    MyObject obj;
    class = ... ; // (the first version)
    obj = class.newInstance();
    obj.foo(); // 1st call
    class = ... ; // (the second version)
    obj = class.newInstance();
    obj.foo(); // 2nd call

    Uli
     
    Ulrich Scholz, Dec 6, 2005
    #9
  10. Ulrich Scholz

    Chris Smith Guest

    Ulrich Scholz <> wrote:
    > Will the objects of two different classes with same class name
    > (generated by separate class loaders) have the same type? In other
    > words, if both have a function foo with the same signature, can I store
    > instances of both classes one after the other in the same variable and
    > call that function?


    The two classes are different, so you can't use a reference to the class
    itself. However, the two may have a common supertype (this is,
    interface or superclass) which can be the type of the reference. That
    supertype should be loaded in a COMMON classloader, generally the normal
    Eclipse classloader. Your new classloaders, from which you create the
    customized classes, should be loaded in a classloader that has that one
    as a parent.

    --
    www.designacourse.com
    The Easiest Way To Train Anyone... Anywhere.

    Chris Smith - Lead Software Developer/Technical Trainer
    MindIQ Corporation
     
    Chris Smith, Dec 6, 2005
    #10
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Jim Hill
    Replies:
    3
    Views:
    428
    Jim Hill
    Feb 12, 2007
  2. *Prot3anThr3ad*

    old repository for old C++ source code

    *Prot3anThr3ad*, Sep 29, 2006, in forum: C++
    Replies:
    6
    Views:
    399
    *Prot3anThr3ad*
    Oct 2, 2006
  3. Travis
    Replies:
    6
    Views:
    572
    Markus Schoder
    Jun 28, 2007
  4. John Henry
    Replies:
    24
    Views:
    1,044
    alex23
    May 30, 2008
  5. Replies:
    3
    Views:
    186
Loading...

Share This Page