parentBehaviouralEntity is nil for Java local variable declared in static block (FAMIXLocalVariable)

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

parentBehaviouralEntity is nil for Java local variable declared in static block (FAMIXLocalVariable)

Fuhrmanator
Here's another anomaly I found in my reasoning about Java interfaces through MSE files. In the example with ArgoUML 0.28.1 there's a class called ConfigurationFactory.java that declares a local variable in a static block:

static {
...
    IConfigurationFactory newFactory = null;
...
}

Within MOOSE, the FAMIXLocalVariable "newFactory" shows up in the structuresWithDeclaredTypes for the FAMIXClass "IConfigurationFactory". However, its parentBehaviouralEntity is nil.

Is this because static blocks in Java don't map to behavioural entities in FAMIX? I'm trying to understand the nil case, as it doesn't happen with all FAMIXLocalVariables.

The problem is obviously that I can't find the dependency on the interface in this case.

In the stated example, there's also a private static final Attribute, so the MOOSE dependency comes through that in the end (it's a redundant dependency). But I'm guessing there could be some cases where a dependency via local variable used in a static block might not always be stored in an Attribute.
 
Any ideas on how to work around this?

Possibly related: https://github.com/moosetechnology/moose/issues/785
Reply | Threaded
Open this post in threaded view
|

Re: parentBehaviouralEntity is nil for Java local variable declared in static block (FAMIXLocalVariable)

Tudor Girba-2
Hi,

The static blocks should map on an <init> stub method belonging to the parent class. The latest jdt2famix has this semantics.

Could it be that the MSE you are using is an old one? If so, could you redo the MSE with jdt2famix? If no, could you point me more closely to the source code?

Also, please only use this address: [hidden email] :)

Cheers,
Doru


> On Sep 12, 2016, at 6:00 PM, Fuhrmanator <[hidden email]> wrote:
>
> Here's another anomaly I found in my reasoning about Java interfaces through
> MSE files. In the example with ArgoUML 0.28.1 there's a class called
> ConfigurationFactory.java that declares a local variable in a static block:
>
> static {
> ...
>    IConfigurationFactory newFactory = null;
> ...
> }
>
> Within MOOSE, the FAMIXLocalVariable "newFactory" shows up in the
> structuresWithDeclaredTypes for the FAMIXClass "IConfigurationFactory".
> However, its parentBehaviouralEntity is nil.
>
> Is this because static blocks in Java don't map to behavioural entities in
> FAMIX? I'm trying to understand the nil case, as it doesn't happen with all
> FAMIXLocalVariables.
>
> The problem is obviously that I can't find the dependency on the interface
> in this case.
>
> In the stated example, there's also a private static final Attribute, so the
> MOOSE dependency comes through that in the end (it's a redundant
> dependency). But I'm guessing there could be some cases where a dependency
> via local variable used in a static block might not always be stored in an
> Attribute.
>
> Any ideas on how to work around this?
>
> Possibly related: https://github.com/moosetechnology/moose/issues/785
>
>
>
> --
> View this message in context: http://forum.world.st/parentBehaviouralEntity-is-nil-for-Java-local-variable-declared-in-static-block-FAMIXLocalVariable-tp4915235.html
> Sent from the Moose mailing list archive at Nabble.com.
> _______________________________________________
> Moose-dev mailing list
> [hidden email]
> https://www.list.inf.unibe.ch/listinfo/moose-dev

--
www.tudorgirba.com
www.feenk.com

"The coherence of a trip is given by the clearness of the goal."





_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.list.inf.unibe.ch/listinfo/moose-dev
Reply | Threaded
Open this post in threaded view
|

Re: parentBehaviouralEntity is nil for Java local variable declared in static block (FAMIXLocalVariable)

Fuhrmanator
OK - trying a reply via e-mail as opposed to the web-based interface (hope this helps). 

Yes, I was using the MSE files from the moose book reference, which are old. So, I regenerated the MSE using the latest jdt2famix, but I've run into another problem (being a smalltalk/pharo newbie).

Before I could find all interfaces limited to the argouml namespace with the following expression:

interfaces := (MooseModel root allModels third allClasses select: 
   [ :each | (each container name beginsWith:'org::argouml') and: (each isInterface)]) asSet.

However, the latest jdt2famix model has a namespaces such that a container name is just e.g. "core" and then one has to traverse to the parent namespace, etc. The "org::argouml' part I'm looking for is at the end of such a traversal. I used the Inspector on the instances and couldn't understand how to get a fully qualified name as before. I'm not enough of a Pharo/SmallTalk coder to figure out how to concatenate it (build it myself). Is there some magic to make this simple as before?

Cheers! 

On Mon, Sep 12, 2016 at 12:46 PM, Tudor Girba <[hidden email]> wrote:
Hi,

The static blocks should map on an <init> stub method belonging to the parent class. The latest jdt2famix has this semantics.

Could it be that the MSE you are using is an old one? If so, could you redo the MSE with jdt2famix? If no, could you point me more closely to the source code?

Also, please only use this address: [hidden email] :)

Cheers,
Doru


> On Sep 12, 2016, at 6:00 PM, Fuhrmanator <[hidden email]> wrote:
>
> Here's another anomaly I found in my reasoning about Java interfaces through
> MSE files. In the example with ArgoUML 0.28.1 there's a class called
> ConfigurationFactory.java that declares a local variable in a static block:
>
> static {
> ...
>    IConfigurationFactory newFactory = null;
> ...
> }
>
> Within MOOSE, the FAMIXLocalVariable "newFactory" shows up in the
> structuresWithDeclaredTypes for the FAMIXClass "IConfigurationFactory".
> However, its parentBehaviouralEntity is nil.
>
> Is this because static blocks in Java don't map to behavioural entities in
> FAMIX? I'm trying to understand the nil case, as it doesn't happen with all
> FAMIXLocalVariables.
>
> The problem is obviously that I can't find the dependency on the interface
> in this case.
>
> In the stated example, there's also a private static final Attribute, so the
> MOOSE dependency comes through that in the end (it's a redundant
> dependency). But I'm guessing there could be some cases where a dependency
> via local variable used in a static block might not always be stored in an
> Attribute.
>
> Any ideas on how to work around this?
>
> Possibly related: https://github.com/moosetechnology/moose/issues/785
>
>
>
> --
> View this message in context: http://forum.world.st/parentBehaviouralEntity-is-nil-for-Java-local-variable-declared-in-static-block-FAMIXLocalVariable-tp4915235.html
> Sent from the Moose mailing list archive at Nabble.com.
> _______________________________________________
> Moose-dev mailing list
> [hidden email]
> https://www.list.inf.unibe.ch/listinfo/moose-dev

--
www.tudorgirba.com
www.feenk.com

"The coherence of a trip is given by the clearness of the goal."





_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.list.inf.unibe.ch/listinfo/moose-dev


_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.list.inf.unibe.ch/listinfo/moose-dev
Reply | Threaded
Open this post in threaded view
|

Re: parentBehaviouralEntity is nil for Java local variable declared in static block (FAMIXLocalVariable)

Fuhrmanator
OK - I went message surfing in the inspector after a good lunch and found the new way -- it's mooseName instead of name:

interfaces := (MooseModel root allModels third allClasses select: 
   [ :each | (each container mooseName beginsWith:'org::argouml') and: (each isInterface)]) asSet.

I also confirm that the init block variables have a good parentBehaviouralEntity. Thanks again!


On Tue, Sep 13, 2016 at 1:15 PM, Cris Fuhrman <[hidden email]> wrote:
OK - trying a reply via e-mail as opposed to the web-based interface (hope this helps). 

Yes, I was using the MSE files from the moose book reference, which are old. So, I regenerated the MSE using the latest jdt2famix, but I've run into another problem (being a smalltalk/pharo newbie).

Before I could find all interfaces limited to the argouml namespace with the following expression:

interfaces := (MooseModel root allModels third allClasses select: 
   [ :each | (each container name beginsWith:'org::argouml') and: (each isInterface)]) asSet.

However, the latest jdt2famix model has a namespaces such that a container name is just e.g. "core" and then one has to traverse to the parent namespace, etc. The "org::argouml' part I'm looking for is at the end of such a traversal. I used the Inspector on the instances and couldn't understand how to get a fully qualified name as before. I'm not enough of a Pharo/SmallTalk coder to figure out how to concatenate it (build it myself). Is there some magic to make this simple as before?

Cheers! 

On Mon, Sep 12, 2016 at 12:46 PM, Tudor Girba <[hidden email]> wrote:
Hi,

The static blocks should map on an <init> stub method belonging to the parent class. The latest jdt2famix has this semantics.

Could it be that the MSE you are using is an old one? If so, could you redo the MSE with jdt2famix? If no, could you point me more closely to the source code?

Also, please only use this address: [hidden email] :)

Cheers,
Doru


> On Sep 12, 2016, at 6:00 PM, Fuhrmanator <[hidden email]> wrote:
>
> Here's another anomaly I found in my reasoning about Java interfaces through
> MSE files. In the example with ArgoUML 0.28.1 there's a class called
> ConfigurationFactory.java that declares a local variable in a static block:
>
> static {
> ...
>    IConfigurationFactory newFactory = null;
> ...
> }
>
> Within MOOSE, the FAMIXLocalVariable "newFactory" shows up in the
> structuresWithDeclaredTypes for the FAMIXClass "IConfigurationFactory".
> However, its parentBehaviouralEntity is nil.
>
> Is this because static blocks in Java don't map to behavioural entities in
> FAMIX? I'm trying to understand the nil case, as it doesn't happen with all
> FAMIXLocalVariables.
>
> The problem is obviously that I can't find the dependency on the interface
> in this case.
>
> In the stated example, there's also a private static final Attribute, so the
> MOOSE dependency comes through that in the end (it's a redundant
> dependency). But I'm guessing there could be some cases where a dependency
> via local variable used in a static block might not always be stored in an
> Attribute.
>
> Any ideas on how to work around this?
>
> Possibly related: https://github.com/moosetechnology/moose/issues/785
>
>
>
> --
> View this message in context: http://forum.world.st/parentBehaviouralEntity-is-nil-for-Java-local-variable-declared-in-static-block-FAMIXLocalVariable-tp4915235.html
> Sent from the Moose mailing list archive at Nabble.com.
> _______________________________________________
> Moose-dev mailing list
> [hidden email]
> https://www.list.inf.unibe.ch/listinfo/moose-dev

--
www.tudorgirba.com
www.feenk.com

"The coherence of a trip is given by the clearness of the goal."





_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.list.inf.unibe.ch/listinfo/moose-dev



_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.list.inf.unibe.ch/listinfo/moose-dev
Reply | Threaded
Open this post in threaded view
|

Re: parentBehaviouralEntity is nil for Java local variable declared in static block (FAMIXLocalVariable)

Tudor Girba-2
Hi,

Great. You found it! :)

Cheers,
Doru


> On Sep 13, 2016, at 8:37 PM, Cris Fuhrman <[hidden email]> wrote:
>
> OK - I went message surfing in the inspector after a good lunch and found the new way -- it's mooseName instead of name:
>
> interfaces := (MooseModel root allModels third allClasses select:
>    [ :each | (each container mooseName beginsWith:'org::argouml') and: (each isInterface)]) asSet.
>
> I also confirm that the init block variables have a good parentBehaviouralEntity. Thanks again!
>
>
> On Tue, Sep 13, 2016 at 1:15 PM, Cris Fuhrman <[hidden email]> wrote:
> OK - trying a reply via e-mail as opposed to the web-based interface (hope this helps).
>
> Yes, I was using the MSE files from the moose book reference, which are old. So, I regenerated the MSE using the latest jdt2famix, but I've run into another problem (being a smalltalk/pharo newbie).
>
> Before I could find all interfaces limited to the argouml namespace with the following expression:
>
> interfaces := (MooseModel root allModels third allClasses select:
>    [ :each | (each container name beginsWith:'org::argouml') and: (each isInterface)]) asSet.
>
> However, the latest jdt2famix model has a namespaces such that a container name is just e.g. "core" and then one has to traverse to the parent namespace, etc. The "org::argouml' part I'm looking for is at the end of such a traversal. I used the Inspector on the instances and couldn't understand how to get a fully qualified name as before. I'm not enough of a Pharo/SmallTalk coder to figure out how to concatenate it (build it myself). Is there some magic to make this simple as before?
>
> Cheers!
>
> On Mon, Sep 12, 2016 at 12:46 PM, Tudor Girba <[hidden email]> wrote:
> Hi,
>
> The static blocks should map on an <init> stub method belonging to the parent class. The latest jdt2famix has this semantics.
>
> Could it be that the MSE you are using is an old one? If so, could you redo the MSE with jdt2famix? If no, could you point me more closely to the source code?
>
> Also, please only use this address: [hidden email] :)
>
> Cheers,
> Doru
>
>
> > On Sep 12, 2016, at 6:00 PM, Fuhrmanator <[hidden email]> wrote:
> >
> > Here's another anomaly I found in my reasoning about Java interfaces through
> > MSE files. In the example with ArgoUML 0.28.1 there's a class called
> > ConfigurationFactory.java that declares a local variable in a static block:
> >
> > static {
> > ...
> >    IConfigurationFactory newFactory = null;
> > ...
> > }
> >
> > Within MOOSE, the FAMIXLocalVariable "newFactory" shows up in the
> > structuresWithDeclaredTypes for the FAMIXClass "IConfigurationFactory".
> > However, its parentBehaviouralEntity is nil.
> >
> > Is this because static blocks in Java don't map to behavioural entities in
> > FAMIX? I'm trying to understand the nil case, as it doesn't happen with all
> > FAMIXLocalVariables.
> >
> > The problem is obviously that I can't find the dependency on the interface
> > in this case.
> >
> > In the stated example, there's also a private static final Attribute, so the
> > MOOSE dependency comes through that in the end (it's a redundant
> > dependency). But I'm guessing there could be some cases where a dependency
> > via local variable used in a static block might not always be stored in an
> > Attribute.
> >
> > Any ideas on how to work around this?
> >
> > Possibly related: https://github.com/moosetechnology/moose/issues/785
> >
> >
> >
> > --
> > View this message in context: http://forum.world.st/parentBehaviouralEntity-is-nil-for-Java-local-variable-declared-in-static-block-FAMIXLocalVariable-tp4915235.html
> > Sent from the Moose mailing list archive at Nabble.com.
> > _______________________________________________
> > Moose-dev mailing list
> > [hidden email]
> > https://www.list.inf.unibe.ch/listinfo/moose-dev
>
> --
> www.tudorgirba.com
> www.feenk.com
>
> "The coherence of a trip is given by the clearness of the goal."
>
>
>
>
>
> _______________________________________________
> Moose-dev mailing list
> [hidden email]
> https://www.list.inf.unibe.ch/listinfo/moose-dev
>
>
> _______________________________________________
> Moose-dev mailing list
> [hidden email]
> https://www.list.inf.unibe.ch/listinfo/moose-dev

--
www.tudorgirba.com
www.feenk.com

"We can create beautiful models in a vacuum.
But, to get them effective we have to deal with the inconvenience of reality."

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.list.inf.unibe.ch/listinfo/moose-dev