On 05/03/2011 10:53 PM, Charles Oliver Nutter wrote: > Brainstorming coro package names... > > java.lang.invoke isn't bad, perhaps, but it is a different form of invocation > than invokedynamic. > > This is a core JVM feature, so something under java.lang seems appropriate in > any case... > > java.lang.coroutine (or coro) is maybe too specific? > > How far off would it be to call coroutines "fibers" outright? Perhaps fiber > does not sufficiently cover all uses of coroutines. > > I'll throw out java.lang.fiber as an option. > > java.lang.stack would cover the wider uses of stack-swapping, > stack-memoizing, and microthreading happening here... > > If the primary classes for coro lived directly under java.lang then other > lang classes could depend on them, like Thread, and every package that deals > with Runnable could depend on Coroutine the same way.
why not java.lang ? as you said, coroutines have strong links with java.lang classes. > Perhaps we should bite the bullet and use this as an opportunity to introduce > java.lang.fp or java.lang.function, to host this and other future utilities > that might be useful to functional programming? I could see tail-call related > utilities fitting there as well, and any classes in the system (like > Executors, etc) could start to be *consistent* with external package > dependencies. tailcall doesn't require any API support. Also as lambda is currently specified, there is no function type thus no need of packages like java.lang.function. But there is a good chance that a package under java.util will be introduced to add lambda support to collection. > Just a few thoughts. The justifications for not introducing java.dyn seem > applicable to this situation. > > - Charlie (mobile) Rémi > On May 3, 2011, at 10:42, Lukas Stadler<[email protected]> wrote: > >> Ah - since invokedynamic doesn't use the java.dyn package any more the >> necessary build infrastructure went missing... I just re-added it. >> One of the tests still fails, but at least it compiles... >> >> - Lukas >> >> On 05/02/2011 05:27 PM, Stephen Bannasch wrote: >>> I've uploaded a build of mlvm with coro enabled: >>> >>> http://www.concord.org/~sbannasch/mlvm/java-1.7.0-internal-mlvm-2011_05_02.tar.gz >>> >>> but running these tests fail: jdk/test/java/dyn/CoroutineTest.java >>> >>> #section:compile >>> ----------messages:(3/175)---------- >>> command: compile >>> /Users/stephen/dev/java/src/mlvm/sources/jdk/test/java/dyn/CoroutineTest.java >>> reason: .class file out of date or does not exist >>> elapsed time (seconds): 0.778 >>> ----------System.out:(1/101)---------- >>> OpenJDK 64-Bit Server VM warning: Use -XX:+UnlockDiagnosticVMOptions >>> before EnableInvokeDynamic flag >>> ----------System.err:(172/7390)---------- >>> >>> /Users/stephen/dev/java/src/mlvm/sources/jdk/test/java/dyn/CoroutineTest.java:33: >>> error: package java.dyn does not exist >>> import java.dyn.Coroutine; >>> ^ >>> >>> /Users/stephen/dev/java/src/mlvm/sources/jdk/test/java/dyn/CoroutineTest.java:34: >>> error: package java.dyn does not exist >>> import java.dyn.AsymCoroutine; >>> ^ >>> >>> /Users/stephen/dev/java/src/mlvm/sources/jdk/test/java/dyn/CoroutineTest.java:54: >>> error: cannot find symbol >>> Coroutine coro = new Coroutine() { >>> ^ >>> symbol: class Coroutine >>> location: class CoroutineTest >>> _______________________________________________ >>> mlvm-dev mailing list >>> [email protected] >>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev >> _______________________________________________ >> mlvm-dev mailing list >> [email protected] >> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev > _______________________________________________ > mlvm-dev mailing list > [email protected] > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev _______________________________________________ mlvm-dev mailing list [email protected] http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
