Jvm inside webworkers
add basic web worker support for javapoly.
One idea for organising the code:
Since the main difference between web-worker and existing code is the dispatch mechanism, you could define two classes:
NormalDispatcher. All the differences could be implemented in these two classes (registering handlers, dispatching logic, etc).
When JavaPoly is instantiated, it can create the chosen Dispatcher instance and use that instance through out the code, without worrying about the exact dispatch mechanism.
I think webworkers are strictly more restrictive, right? So any dispatcher that works for webworkers will work on the main thread? I wonder if it might be better to have a single unified codepath/dispatcher.
@jimsproch That's right. Another way to look at it: our existing dispatcher goes from
JS <-> JVM. Whereas, the webworker needs an additional hop:
JS <-> Worker <-> JVM.
It should be possible to use the same code path in both cases, but there would be an extra hop for the normal dispatching case.
Yes, I guess what I'm saying is: "If the JVM API we expose is effectively just
postMessage(ie. very similar to the Worker API) then the worker hop is almost invisible (it literally just forwards the message)". Then both event paths would look nearly exactly the same (
JS <-> SuperThinFakeWorker <-> JVMand
JS <-> Worker <-> JVM)
I'll stop talking now, you guys are smart, you'll figure out whatever is best :).
@jimsproch I am with you and please don't stop talking :)
The following is a recap for @coderrooftrellen's benefit:
My suggestion was about how the wiring code could be organised. In this PR, the wiring logic is scattered across different files. If it can be bundled into two classes (for webworker and normal dispatch respectively), then the rest of the code doesn't have to bother about it. It will just call
If I understand right, @jimsproch's observation is that the two dispatcher classes will be mostly the same (except for one extra hop for web-worker), so they could be merged into a single dispatcher. I think that is a fine (and separate) idea, that is also worth considering. Though I don't think the two classes will be very similar.
@hrjet9 will update the code indentation problem shortly.
@jimsproch @hrjet9 thanks for you suggestion. I will first try to refactor/collect some code logic about message listerner/dispatcher into separate class. then to try make a common(default) Dispatcher from what i have collected, and maybe one/two sub Dispatchers depends on the code similarity for browser and webworker.
Jim is right, the webworkers is much more strictly.
we don't have access for Dom/window object/ document object in webworkers. we can't use local storage... .and there is some other restrictions.
another important thing for us is diptaching message.
when running javapoly core in browser, we could easily share args/return data, callback function when dispatch message. listener can get those things easily by access global var.
but for workers, we could not easily share those thing( browser and webworker are in different context), we need to pass the data in message using JSON, Blob, ArrayBuffer. (though there is some browser support 'transferable_objects' https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers_API/Using_web_workers#Passing_data_by_transferring_ownership_(transferable_objects) )
Added 19 new commits:
- ed9c37fb - Merge branch 'master' of git.javadeploy.net:jimsproch/JavaPoly into jvm_inside_webworkers
- 332af054 - refactor the code for web worker and message dispatching
- fcd0d7c9 - #28 fixed
- c8378590 - Types added for natives
- 3201edfb - Printing 'caused by' added to make stack trace complete
- 5f5b445e - #33 Required java classes added to libListings
- 76f84de9 - Fix broken test. Closes #33
- 957bff1d - cast returned boolean values to JS booleans. For #32
- c44451ed - better implementation for printing exceptions
- 0456a36d - #13 copy doppiojvm into test directory
- ccab2122 - #13 moved to tasks common task 'compare_version' and added browserfs copying
- 84a048ac - close #13
- 3fdf602f - Avoid returning rawValue through a function, instead use directly.
- ccd7e7de - minor: use single line comment style
- ea7584c9 - Use the fast-dev build of doppio for testing
- 86d2d470 - Merge branch 'useFastDev' into 'master'
- 9d76d999 - minor: simplify creation of wrapper method
- c882261d - Only public static methods should be accessible in class wrapper
- a64209fc - Merge branch 'master' of git.javadeploy.net:jimsproch/JavaPoly into jvm_inside_webworkers
Status changed to merged