ode-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hadrian Zbarcea (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (ODE-979) Upgrade jacob-ap to jsr-269
Date Thu, 10 Jan 2013 14:46:13 GMT

    [ https://issues.apache.org/jira/browse/ODE-979?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13549674#comment-13549674
] 

Hadrian Zbarcea commented on ODE-979:
-------------------------------------

I didn't close this issue because I was looking into a better way of doing it. The Channels
and ChannelListeners are basic concepts and any changes have significant impacts all over
the rest of the code. However they are not really necessary in this form.

Firstly the generated Channel is not really needed, because they are always used via Proxies.
However, Proxies could implement multiple interfaces so there is no real need for a (generated)
class that implements both T (the generic channel interface) and Channel. Things are a bit
more complicated with ChannelListeners and the challenge is to come up with a solution that
allows to change things incrementally.

There are 2 things that go against each other. The listener is invoked on to pass the message,
so they need to implement the generic channel interface T, but the implementation has to interact
with the runtime, so it needs to extend JacobObject as well. Since java does not allow a generic
class to implement (or extend) a generic type, the solution was code generation. The best
solution I could come up with that would allow an incremental transition is introducing a
new abstract class RecieveProcess that does not implement T, but uses a T: 

{code}
public abstract class ReceiveProcess<C extends Channel, R> extends ChannelListener<C>
{
    final R receiver;
[...]
    public Object receiver() {
        return receiver;
    }
    public Set<Method> getImplementedMethods() {
        if (_implementedMethods == null) {
            Set<Method> implementedMethods = new HashSet<Method>();
            ClassUtil.getImplementedMethods(implementedMethods, receiver.getClass());
            _implementedMethods = Collections.unmodifiableSet(implementedMethods);
        }
        return _implementedMethods;
    }
}
{code}

(NOTE: getImplementedMethods returns the list of methods supported by the channel. It's kinda
like the messages passed along the pi calculus channels are instances of java.lang.reflect.Method,
which are actuall, well, Continuations).

Then I modified JacobVpu.JacobThreadImpl.run() like this:
{code}
    _method.invoke(_methodBody instanceof ReceiveProcess ? 
        ((ReceiveProcess<?, ?>)_methodBody).receiver() : _methodBody, args);
{code}

Now given the fact that most of the listeners are implemented as anonymous classes within
the context of a JacobObject (Runnable), the JacobVPU (pi calculus) methods (object/instance/message/newChannel)
will be accessible. In the rare cases where not, the access will be provided by getting the
JacobThread from the TLS.

So the new code will look like:
{code}
      object(new ReceiveProcess<ValChannel, Val>(retChannel, new Val() {
          public void val(Object retVal) {
              _val = retVal;
            }
      }) {});
{code}

Once the whole code transitions to using ReceiveProcesses instead of generated ChannelListeners,
the code can be further simplified by eliminating the ChannelListener completely and changing
the ReceiveProcess to use only one generic argument.

Since this change will have ripple effect across the whole code, I would appreciate your thoughts
before committing.
                
> Upgrade jacob-ap to jsr-269
> ---------------------------
>
>                 Key: ODE-979
>                 URL: https://issues.apache.org/jira/browse/ODE-979
>             Project: ODE
>          Issue Type: Improvement
>            Reporter: Hadrian Zbarcea
>            Assignee: Hadrian Zbarcea
>             Fix For: 1.4
>
>         Attachments: examples-jacob.zip
>
>
>  Upgrade the apt support in jacob-ap to jsr-269. The old mirror api is deprecated anyway.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Mime
View raw message