-
Notifications
You must be signed in to change notification settings - Fork 14
/
Copy pathTODO.txt
112 lines (96 loc) · 6.72 KB
/
TODO.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
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)
https://github.com/luontola/jumi-actors/issues/1
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()?
https://groups.google.com/d/topic/jumi-test-runner/xQYPeqB00UQ/discussion
- 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
actor.tell().doSomething().then(this::myCallback);
...
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)
https://github.com/kriskowal/q#handling-errors
- make the resulting JAR under 100KB; using Guava makes it easily 1MB because shade plugin doesn't remove unused methods
http://wvengen.github.io/proguard-maven-plugin/
http://proguard.sourceforge.net/
- 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?
http://lets-code.orfjackal.net/2013/04/lets-code-jumi-231-monitoredexecutor.html
- 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
https://groups.google.com/forum/#!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)
http://blog.cedarsoft.com/2010/08/code-generation-done-right/
http://www.eclipse.org/jdt/core/index.php
http://help.eclipse.org/indigo/topic/org.eclipse.jdt.doc.isv/reference/api/org/eclipse/jdt/core/dom/package-summary.html
- walking skeleton
1. take the old generator's output
2. parse it to AST
example: http://help.eclipse.org/indigo/topic/org.eclipse.jdt.doc.isv/reference/api/org/eclipse/jdt/core/dom/AST.html
http://help.eclipse.org/indigo/topic/org.eclipse.jdt.doc.isv/reference/api/org/eclipse/jdt/core/dom/ASTParser.html
3. convert AST to string
example: http://help.eclipse.org/indigo/topic/org.eclipse.jdt.doc.isv/reference/api/org/eclipse/jdt/core/dom/AST.html
http://help.eclipse.org/indigo/topic/org.eclipse.platform.doc.isv/reference/api/org/eclipse/jface/text/Document.html
http://help.eclipse.org/indigo/topic/org.eclipse.platform.doc.isv/reference/api/org/eclipse/jface/text/IDocument.html#get()
4. format using Eclipse Formatter
http://help.eclipse.org/indigo/topic/org.eclipse.jdt.doc.isv/reference/api/org/eclipse/jdt/core/ToolFactory.html#createCodeFormatter
http://help.eclipse.org/indigo/topic/org.eclipse.jdt.doc.isv/reference/api/org/eclipse/jdt/core/formatter/package-summary.html
http://www.eclipse.org/jdt/core/codecoverage/B01/org.eclipse.jdt.core/org.eclipse.jdt.core.formatter/CodeFormatterApplication.java.html#L204
5. use the Organize Imports operation, unless formatter already adds imports
? http://help.eclipse.org/indigo/topic/org.eclipse.jdt.doc.isv/reference/api/org/eclipse/jdt/ui/actions/OrganizeImportsAction.html
? http://plugins.intellij.net/plugin/?idea&id=6546
http://stackoverflow.com/questions/2644440/simplifying-fully-qualified-names-in-eclipse
- 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
http://www.vineetmanohar.com/2009/04/how-to-auto-generate-maven-plugin-documentation/
http://stackoverflow.com/questions/2912665/maven-plugin-site
http://maven.apache.org/guides/mini/guide-site.html