If you want to get rid of the of the method lookup you do need to pass in the Runnable also to the continueWith ...not sure if I like that.No, I don't think you have to. That Runnable object is a part of Continuation already. The continueWith method can look it up from there. Specifically, it already retains a reference to that object in Stack. We just need to make it explicitly accessible (instead of fiddling with references in stacks to get to it.)
I *do* think you have to :) ...think about the serialization. The continuation has been restored. THERE IS NO REFERENCE TO A METHOD OR RUNNABLE. Please check with the current implementation. For debugging you can add logging to see what's been put onto the stack.
I had similar idea in the beginning: startWith(Method, ContinuationContext) continueWith(Method, Continuation, ContinuationContext) What I did not like: Passing in of the Continuation already implies the Method.I agree. That's why I originally suggested to use Runnable in this level, to get rid of Method altogether.
Well ...that's not the point. I really do think you have to pass in the Runnable or Method to "continueWith" ...if you don't have a lookup. That's why I don't like this either: startWith(Runnable, ContinuationContext) continueWith(Runnable, Continuation, ContinuationContext)
Beforehand the method was saved inside the Continuation object. But this does not work when it comes down to serialization.By calling Runnable.run() method, you no longer have to save the Method object in Continuation. That means no MethodLookup is necessary, no method name is necessary.
...does not matter whether we are talking about Method or Runnable. If you want to get rid of passing in the parameter you have to store it somewhere inside the continuation - which is not ok for the serialization.
BTW: IIRC I needed to mark the static as transient for the XStream serialization ..but not totally sure.I used XStream in other projects, and I believe it didn't persist static fields. But I will put that back. Maybe we are using different versions.
Maybe just give the serialization testcase a try and turn it on/off based on that result.
See the attachments for the exact code. All in all, I didn't think this re-write is ugly, but that is always a subjective issue.I don't understand this forking and cloning stuff - you don't need that. A continuation should be re-entrant and always create a new one as a result.Unlike Continuation, Fiber is a mutable object. It updates itself as you continue execution. That's why sometimes you want a "fork" to create an identical copy.
...that also means for persistence you would have to serialize the Fiber object, too. Hmm...
Fiber.fork doesn't deep-copy Continuation, as Continuation itself doesn't need to be copied. It's just Fiber object that needs to be copied, hence the use of clone().
Hmmm... why do you need a mutable object at all?
If you don't mind I would prefer if you keep that code in your codebase for now. Let's get back to that once we have the rewriting based on ASM in place. I would like to focus on the hard part first ;)> > Would that be ok for you? Hmm...Even if Fiber doesn't change any of the existing Continuation class, do you still feel uncomfortable with it?
Well ...point is - it's a second API.
As an user, it doesn't really matter to me what byte-code manipulation library javaflow is using, because it's completely behind the scene.
Sure ...but don't you think it's more important the guts are working properly before abstracting the further abstracting the API?
The current BCEL one seems to be working, so it's not very high priority for me to rewrite javaflow by using ASM. Besides, I doubt if I can be of any help when it comes to porting javaflow from BCEL to ASM. That part is the guts of javaflow and it takes you to change it.
...too bad - hoped you could help me there as well :)
For me, the javaflow API surface is of a higher priority, because in the end my goal is to use it. I suspect that a thread-like API connects to users more easily, as there's less learning involved. I'm hoping that this contributes to an improved user experience. For this reason, I hope it's beneficial to the javaflow project.
It does lower the barrier ...but I am not sure whether it really helps people to understand the concept behind it. It might even blur that a bit.
Once again, I'm not trying to convince you to change the existing Continuation class in any substantial way. I'm only asking you to put this Fiber class side-by-side with the current Continuation class.Please please can I have this class? I promise I won't talk about the Continuation class signature change any more :-)
LOL :o) Comeon ...it's not big difference whether it's in your codebase or inside the javaflow codebase, isn't it? ...I am not saying "no" but "convince me" ;)
If not, I guess I just need to accumulate more small improvements to make you feel comfortable with me. It's disappointing for me for now, but that's certainly fair, I guess.
Sorry, don't want to come across to negative or protective. I just don't feel too good having two APIs in the first release already. cheers -- Torsten
PGP.sig
Description: This is a digitally signed message part
