javapathfinder-devel

[Javapathfinder-devel] Extending JPF class

[Michal K. <mic...@gm...>]

Hi,

will it be possible to extend JPF class so that it allows to pass a custom 
Object in it? I mean one getter and setter, for example Object getTag() and void 
setTag(Object o).

I would like to access this object from my peer like:
MyObject o = (MyObject) env.getJPF().getTag();

You may have already read something about running JUnit under JPF and collecting 
output from JUnit listener in javapathfinder-user list. If I could pass a custom 
object to JPF object it would very easy to forward information from listener's 
peer outside into that object.

Michal

Re: [Javapathfinder-devel] Extending JPF class

[Peter C. M. <Pet...@na...>]

Since this object would only be processed by your own listeners/native  
peers, why don't you pass it directly between them (e.g. by using a  
static field)?

-- Peter


On Sep 10, 2008, at 4:53 AM, Michal Kebrt wrote:

> Hi,
>
> will it be possible to extend JPF class so that it allows to pass a  
> custom
> Object in it? I mean one getter and setter, for example Object  
> getTag() and void
> setTag(Object o).
>
> I would like to access this object from my peer like:
> MyObject o = (MyObject) env.getJPF().getTag();
>
> You may have already read something about running JUnit under JPF  
> and collecting
> output from JUnit listener in javapathfinder-user list. If I could  
> pass a custom
> object to JPF object it would very easy to forward information from  
> listener's
> peer outside into that object.
>
> Michal

Re: [Javapathfinder-devel] Extending JPF class

[Michal K. <mic...@gm...>]

I don't like the idea of a static field very much and will explain why. Suppose 
I have a JPFJUnit class which is a wrapper above JPF+JUnit and runs JUnit under 
pathfinder through the JPF class. JPFJUnit will be used from different kinds of 
applications to embed the test framework - e.g. from Eclipse plugin or Ant task.

What happens when a JPFJUnit's static field is used for communication with 
JUnit's listener peer and is launched twice (e.g. on different test cases in 
Eclipse plugin) at the _same moment_. Then both peer instances will forward 
information to the same static field. I don't like this.

I would like to have so called JPFJUnitListener that will receive information 
from both JPF and JUnit listeners. It could be used from a plugin in the 
following way:

JPFJUnit jpfjunit = new JPFJUnit();
// do some config on jpfjunit
jpfjunit.addListener(new MyJPFJUnitListener());
jpfjunit.run() {
   jpf = new JPF();
   // do some config on jpf
   jpf.setTag(listeners);
   jpf.run();
}

Michal

Peter C. Mehlitz wrote:
> Since this object would only be processed by your own listeners/native 
> peers, why don't you pass it directly between them (e.g. by using a 
> static field)?
> 
> -- Peter
> 

Re: [Javapathfinder-devel] Extending JPF class

[Peter C. M. <Pet...@na...>]

it doesn't have to be a static field. Your listeners are created  
outside of JPF, so you can pass whatever shared object you want into  
their constructors:

   ..
   Config conf = JPF.createConfig(..)
   SharedData shared = ...
   Listener1 l1 = new Listener1(conf,..shared..);
   Listener2 l2 = new Listener2(conf,..shared..);
   JPF jpf = new JPF(conf);
   jpf.addListener(l1);
   jpf.addListener(l2);
   jpf.run();
   ..

A generic per-run object in the JPF instance wouldn't work because  
Listeners shouldn't be forced to know about each other, and could  
therefore easily compete for this field.

So even if you need to share data between a native peer (static  
methods) and a listener, this requires a per-run registry, and we  
already have one - Config. You can stick whatever object you want in  
there, it's just a Hashtable. Just make sure it doesn't contain a  
conflicting key before you do so.

-- Peter 



On Sep 11, 2008, at 6:02 AM, Michal Kebrt wrote:

> I don't like the idea of a static field very much and will explain  
> why. Suppose I have a JPFJUnit class which is a wrapper above JPF 
> +JUnit and runs JUnit under pathfinder through the JPF class.  
> JPFJUnit will be used from different kinds of applications to embed  
> the test framework - e.g. from Eclipse plugin or Ant task.
>
> What happens when a JPFJUnit's static field is used for  
> communication with JUnit's listener peer and is launched twice (e.g.  
> on different test cases in Eclipse plugin) at the _same moment_.  
> Then both peer instances will forward information to the same static  
> field. I don't like this.
>
> I would like to have so called JPFJUnitListener that will receive  
> information from both JPF and JUnit listeners. It could be used from  
> a plugin in the following way:
>
> JPFJUnit jpfjunit = new JPFJUnit();
> // do some config on jpfjunit
> jpfjunit.addListener(new MyJPFJUnitListener());
> jpfjunit.run() {
>  jpf = new JPF();
>  // do some config on jpf
>  jpf.setTag(listeners);
>  jpf.run();
> }
>
> Michal
>
> Peter C. Mehlitz wrote:
>> Since this object would only be processed by your own listeners/ 
>> native peers, why don't you pass it directly between them (e.g. by  
>> using a static field)?
>> -- Peter

Re: [Javapathfinder-devel] Extending JPF class

[Michal K. <mic...@gm...>]

Peter C. Mehlitz wrote:
> it doesn't have to be a static field. Your listeners are created  
> outside of JPF, so you can pass whatever shared object you want into  
> their constructors:
> 
>    ..
>    Config conf = JPF.createConfig(..)
>    SharedData shared = ...
>    Listener1 l1 = new Listener1(conf,..shared..);
>    Listener2 l2 = new Listener2(conf,..shared..);
>    JPF jpf = new JPF(conf);
>    jpf.addListener(l1);
>    jpf.addListener(l2);
>    jpf.run();
>    ..
> 
> A generic per-run object in the JPF instance wouldn't work because  
> Listeners shouldn't be forced to know about each other, and could  
> therefore easily compete for this field.

That's clear. JPF listener (I won't need more than one) is ok, it is constructed 
in my code so I can pass whatever I want in its constructor. What is problem is 
JUnit listener called through native peers. Config object seems to be a good 
idea, thanks.

> 
> So even if you need to share data between a native peer (static  
> methods) and a listener, this requires a per-run registry, and we  
> already have one - Config. You can stick whatever object you want in  
> there, it's just a Hashtable. Just make sure it doesn't contain a  
> conflicting key before you do so.
> 
> -- Peter