«

Hello,

For my master thesis I have to create a customer relationship management
system (CRM). The final program should be a J2EE component. The
interesting part of this system is that the user can specify the data
schema (model) of the CRM system at runtime. To define this model I
created a metamodel. In order to allow an easy access to the model, I
will generate java source classes according to the model (that is
defined as instances of the meta classes). One problem is that the user
is allowed to change the model at runtime, meaning that the source code
files have to be recreated and compiled again.

So much for the introduction . After creating the source files I need
to compile them at runtime, is there a possibility to do so?

As I said before if the model changes, the new source code files need to
be compiled again. Is there a way to "unload" possible classes that were
created for the last model, so that there won't be a clash with the
newly created classes?

Any suggestions?
Best regards,
Stefan

On Tue, 07 Sep 2004 09:39:13 +0200, Stefan Siegl wrote:

> After creating the source files I need
> to compile them at runtime, is there a possibility to do so?

Yes, but only by invoking classes for which
Sun issues no public documentation, and
reserves the right to change at any time.

> As I said before if the model changes, the new source code files need to
> be compiled again. Is there a way to "unload" possible classes that were
> created for the last model, so that there won't be a clash with the
> newly created classes?

I am on unfamiliar ground here, but you
might try using a custom class loader,
and refreshing it.

Better suggestions are probably forthcoming.

But.. why does a CRM need to compile source
'on the fly', it seems like you might be
approaching the problem wrong. (And again,
I am not that experienced with the area,
but it has a strong whiff of 'overkill'.)

--
Andrew Thompson
http://www.PhySci.org/ Open-source software suite
http://www.PhySci.org/codes/ Web & IT Help
http://www.1point1C.org/ Science & Technology

On Tue, 07 Sep 2004 08:48:30 GMT, Andrew Thompson wrote:
> On Tue, 07 Sep 2004 09:39:13 +0200, Stefan Siegl wrote:
>> After creating the source files I need
>> to compile them at runtime, is there a possibility to do so?
>
> Yes, but only by invoking classes for which Sun issues no public
> documentation, and reserves the right to change at any time.

Sun does advise against using classes in the sun.* hierarchy.

However this Sun article showing how to use com.sun.tools.javac.Main
to compile code from within a Java program seems to imply that the
advice doesn't hold for the com.sun.* classes:

http://java.sun.com/developer/JDCTec.../tt0722.html#2

/gordon

--
[ do not email me copies of your followups ]
g o r d o n + n e w s @ b a l d e r 1 3 . s e

Andrew Thompson wrote:
> On Tue, 07 Sep 2004 09:39:13 +0200, Stefan Siegl wrote:
>
>
>>After creating the source files I need
>>to compile them at runtime, is there a possibility to do so?
>
>
> Yes, but only by invoking classes for which
> Sun issues no public documentation, and
> reserves the right to change at any time.

Not only. You can also use
java.lang.Runtime.getRuntime().exec("javac", ...) or
java.lang.Runtime.getRuntime().exec("jikes", ...), see Runtime javadoc.
Other option is for example using KJC (part of Kopi
(http://www.dms.at/kopi/)) it was not too fast 1,5 year ago, but authors
improved it(i hope), and it had public API (should be still
public).You can maybe find other compilers for java by googling

--jungi

>
>
>>As I said before if the model changes, the new source code files need to
>>be compiled again. Is there a way to "unload" possible classes that were
>>created for the last model, so that there won't be a clash with the
>>newly created classes?
>
>
> I am on unfamiliar ground here, but you
> might try using a custom class loader,
> and refreshing it.
>
> Better suggestions are probably forthcoming.
>
> But.. why does a CRM need to compile source
> 'on the fly', it seems like you might be
> approaching the problem wrong. (And again,
> I am not that experienced with the area,
> but it has a strong whiff of 'overkill'.)
>

On 7 Sep 2004 11:10:12 +0200, Gordon Beaton wrote:
> However this Sun article showing how to use com.sun.tools.javac.Main
> to compile code from within a Java program seems to imply that the
> advice doesn't hold for the com.sun.* classes:

Ok I spoke too quickly, the article does seem to include a warning
about using those classes too, although I'm certain it didn't when I
first read it a year ago.

It does refer to an API expected in 1.5 though. Could this be it?

http://java.sun.com/j2se/1.5.0/docs/.../Compiler.html

/gordon

--
[ do not email me copies of your followups ]
g o r d o n + n e w s @ b a l d e r 1 3 . s e

Stefan Siegl wrote:

> So much for the introduction . After creating the source files I need
> to compile them at runtime, is there a possibility to do so?

Yes. You can invoke Sun's compiler directly (I can't remember the precise
class off-hand, but it's mentioned in another thread in this newsgroup today).
Andrew's warning is to be taken seriously, but I wouldn't let it worry /me/ --
I believe that Sun are intending to provide a public API to compilation soon
(and that it only missed 1.5 because of time pressure), so I'd hope that if Sun
do remove the private classes, then they'll replace them with something else
you can use. You can always fall back to using javac if it really becomes
necessary, anyway.

However, if /I/ were doing this then I think I'd look at the option of
interpreting the meta-model directly, rather than generating new classes. I
think that would be easier, and I can't imagine it causing performance
problems. Still, there's nothing wrong with generating classes, if that's
what appeals to you, so...

> As I said before if the model changes, the new source code files need to
> be compiled again. Is there a way to "unload" possible classes that were
> created for the last model, so that there won't be a clash with the
> newly created classes?

You need to load all the "disposable" classes through a specially created
classloader (the standard URLClassLoader, or whatever it's called, should work
OK, but you might want to write your own anyway). When you drop the reference
to the classloader, and when there are no more instances of the classes
themselves alive, then the classes will be removed from the runtime. When you
want to create a new batch of classes, you create a new classloader to load
them, so there's no interference with any defunct classes that might still be
hanging around.

You'll probably find it worthwhile to define a bunch of interfaces that are
/not/ disposable, and which the various generated classes implement. Otherwise
you'll have difficulty "talking about" instances of the disposable classes in
other contexts.

One thing that isn't helped by classloaders is migrating the state of the
system as it is modified. If you create a new "version" of a class, the
instances of the existing class won't be migrated. You'll have to transfer the
state of the system from the old collection of objects to the new. Somehow...

Again, I think that migration would probably be easier if you were interpreting
the meta-model, and that's one reason why I'd consider that first.

-- chris

Andrew Thompson wrote:

> On Tue, 07 Sep 2004 09:39:13 +0200, Stefan Siegl wrote:
>
>
>>After creating the source files I need
>>to compile them at runtime, is there a possibility to do so?
>
>
> Yes, but only by invoking classes for which
> Sun issues no public documentation, and
> reserves the right to change at any time.
>
>
>>As I said before if the model changes, the new source code files need to
>>be compiled again. Is there a way to "unload" possible classes that were
>>created for the last model, so that there won't be a clash with the
>>newly created classes?
>
>
> I am on unfamiliar ground here, but you
> might try using a custom class loader,
> and refreshing it.

I hope this is possible, I will give it a try, but I suspect that it
will not be that easy. I just thought that it must be possible to unload
the classes, because other Java application can do it too, i.e. the
JBoss app server with its hotdeploy feature.

> Better suggestions are probably forthcoming.
>
> But.. why does a CRM need to compile source
> 'on the fly', it seems like you might be
> approaching the problem wrong. (And again,
> I am not that experienced with the area,
> but it has a strong whiff of 'overkill'.)

The central requirement of the system is that the user should be allowed
to define his specific CRM model at runtime. Therefore a metamodel is
provided by me to define the general constructs a model can have (like a
class, associations, and so on). The model will then be represented by
instances of these metaclasses. based on this model the user is allowed
to insert/query/delete data.

The problem is that the handling of model is not easy if the model is
stored as meta instances, because then i do not have a nice connection
between the entered data and the model. That is why I wanted to have
java classes that represent this model and instances of this model to
represent the data. Using this approach I can directly check if the
rules of the models are kept within the offered data.

Gordon Beaton wrote:

> It does refer to an API expected in 1.5 though

I'm pretty sure I remember Neil saying here that the compiler interface was
dropped from 1.5 for lack of time.

> Could this be it?
>
> http://java.sun.com/j2se/1.5.0/docs/.../Compiler.html

That is, I think, part of the architecture for allowing the JVM to host
pluggable JITs.

-- chris

On 7 Sep 2004 11:17:54 +0200, Gordon Beaton wrote:

(Compile from within Java)
> http://java.sun.com/j2se/1.5.0/docs/.../Compiler.html

...hmmm, dunno. It does not look like it,
(it mentions hooks to alternate compilers),
I would have to play with it to be sure,
though what Chris was saying, suggests that
whatever changes were in the pipeline missed 1.5.

--
Andrew Thompson
http://www.PhySci.org/ Open-source software suite
http://www.PhySci.org/codes/ Web & IT Help
http://www.1point1C.org/ Science & Technology

On Tue, 7 Sep 2004 10:50:29 +0100, Chris Uppal wrote:

> Andrew's warning is to be taken seriously, but I wouldn't let it worry /me/ --

(chuckles) It did not slow me down.

I figure Sun would only change those classes
if they saw good reason to do so, and given
they have been in the same place/form through
a number of releases, it suggests they are happy
with them as is.

<big snip>
> One thing that isn't helped by classloaders is migrating the state of the
> system as it is modified. If you create a new "version" of a class, the
> instances of the existing class won't be migrated.

At first I thought Serialize them, but then
it struck me that this is one case where
Sun's warning on serialization would become
relevant. The class files change.

XMLEncoder?

--
Andrew Thompson
http://www.PhySci.org/ Open-source software suite
http://www.PhySci.org/codes/ Web & IT Help
http://www.1point1C.org/ Science & Technology