Find file Copy path
Fetching contributors…
Cannot retrieve contributors at this time
113 lines (96 sloc) 6.72 KB
OK - remove Maven plugin, cleanup this TODO list, push up issues that can now be solved more easily
OK - generating event stubs when method argument types take type parameters (now causes JavaType to throw IllegalArgumentException: unsupported type)
OK - the new generator doesn't add imports for nested type parameters
OK - easier access to an ActorRef to the current actor, e.g. Actors.selfRef() using a thread-local, or perhaps Actors.currentThread()?
- find all use cases in Jumi, see how they would benefit from this change, design the API appropriately
!! - support for non-void actor methods which return a Future
private void myCallback(String result) {...}
public Promise<String> doSomething() {
return Promise.of("the return value");
OK - allow methods which return futures
OK - dynamic eventizer support
OK - mutable promise handle, make promise itself read-only
- returning null instead of a promise; should crash early?
- support for exceptions, pass as a second parameter to callback.then(value, error)
- make the resulting JAR under 100KB; using Guava makes it easily 1MB because shade plugin doesn't remove unused methods
- use the actor thread pool in JdkFutureAdapters.listenInPoolThread to avoid thread leaks
- support for non-shaded ListenableFuture
- javadocs for Promise
- javadocs for Callback
- generated eventizer support
- make dynamic and generated events support equals and hashCode methods
- refactor EventSpy: always call await() from assertContains() to avoid duplication?
- find all usages and see if await be done everywhere
- do the change
- set timeout through constructor? or use test timeouts and throw InterruptedException?
- remove duplicated calls to await()
- thread-safety-checker: when an inner class is missing the annotation, use the annotation of the enclosing class or default to @NotThreadSafe when the enclosing class has any concurrency annotation
- APT generator: support inherited methods? would somehow have to get the parent's AST (workaround is to override every method)
- extract AbstractMessageLogger from PrintStreamMessageLogger, to support multiple logging frameworks
- make it possible to give names to actor threads!topic/jumi-test-runner/BYyEfzLnX4A
- at least make it possible to use a fixed name
- should there be a convenience factory method for generating unique names? e.g. "jumi-actors-1-thread-1" format.
- should we still use an Executor? is it anyways needed for testing purposes? create NamedThreadExecutor interface and adapter for Executor?
- find all usages of MultiThreadedActors and analyze how it is used (especially in tests); do we interrupt the threads with shutdownNow()?
- make it possible to plug in your own MessageQueue implementation when creating a particular actor thread
interface MessageQueue<T> {
MessageSender<T> getMessageSender();
MessageReceiver<T> getMessageReceiver();
- rename current impl to UnboundedManyToManyMessageQueue
- create BoundedBatchingManyToOneMessageQueue
- reader consumes its own queue first, then all the others in fair round robin fashion with batch reads
- create a mechanism to avoid the actor thread sending itself so many messages that it deadlocks (reader's queue 2x larger? expand automatically?)
- benchmarks for all the queue types
- actors examples & benchmarks:
- create jumi-actors-examples, put there the examples and benchmarks
- create a benchmark to compare against Akka Actors
- ring round trip
- warm startup
- cold startup (can't use Caliper, need a main method in a fresh JVM, or could it be done with custom class loaders?)
- create a benchmark to compare reflection vs code generation based eventizers
- also use it as an example of using the code generator plugin
- add the benchmark results to the web site
- evaluate using Eclipse JDT DOM for code generation, create an internal DSL as necessary (factory methods to avoid setter hell)
- walking skeleton
1. take the old generator's output
2. parse it to AST
3. convert AST to string
4. format using Eclipse Formatter
5. use the Organize Imports operation, unless formatter already adds imports
- might need to transform the AST ourselves?
- migrate to generating code with JDT AST
- generate code with fully qualified names, rely on the formatter for imports
- migrate to AST one method at a time, if possible
- try using AST.newMethodDeclaration or AST.newBlock instead of AST.newCompilationUnit
- delete the old code generator
- a trace of intermediate actors: logging actor messages could benefit from seeing that from which actor(s) a message originated
- web site improvements
- site for jumi-actors-maven-plugin