user/jkoenig/java: Integrate most of the action items from the discussion page.

1 files changed, 90 insertions, 1 deletions

diff --git a/user/jkoenig/java.mdwn b/user/jkoenig/java.mdwn
index 90f51028..fcd316b7 100644
--- a/user/jkoenig/java.mdwn
+++ b/user/jkoenig/java.mdwn
@@ -38,7 +38,7 @@ I have submitted
 [preliminary patches](http://lists.gnu.org/archive/html/bug-hurd/2011-05/msg00182.html)
 for global signal dispositions,
 which I'm currently testing.
-I have since fixed a few thinks and implemented `SA_SIGINFO`
+I have since fixed a few things and implemented `SA_SIGINFO`
 (which is required by OpenJDK.)
 My latest code is available on
 [github](http://github.com/jeremie-koenig/glibc/commits/master-beware-rebase),
@@ -56,6 +56,7 @@ at which point we will alias the interim version
 to the new one in debian packages.
 
 I have modified libc0.3 to include a `deb-symbols(5)` file
+(alternatively see <http://wiki.debian.org/Projects/ImprovedDpkgShlibdeps>)
 so that we get an accurate libc dependency in `hurd` and other packages
 when the symbols in question are pulled in.
 
@@ -71,6 +72,28 @@ I expect only the last patch (implement global dispositions) will change,
 and new ones will be added on top of it.
 
 
+##### Open Items
+
+  * Test patches: in progress, [[jkoenig]], Svante.  More volunteers welcome,
+    of course.
+
+  * If [[jkoenig]] thinks it's mature enough: should ask Samuel to test this
+    (that is, only the refactoring patches for starters?) on the buildds.
+
+  * Get patches reviewed (Roland?), and integrated into official sources: [!]
+    [[tschwinge]].
+
+  * Documentations bits (from [[proposal]] and elsewhere) should probably be
+    moved either into the appropriate glibc or Hurd documentation
+    files/reference manuals, or to [[glibc/signal]].
+
+  * libthreads (cthreads) integration.
+
+      * [[tschwinge]] suggests to leave them as-is?
+
+  * [[libpthread]] integration.
+
+
 ### Port OpenJDK
 
 As suggested by [[tschwinge]], I have targeted OpenJDK 7 at first.
@@ -107,8 +130,74 @@ although the current toolchain issues
 have so far prevented me from testing it.
 
 
+##### Open Items
+
+  * They seem to have a rather heavy-weight process for such projects: confer
+    <http://mail.openjdk.java.net/pipermail/announce/2011-January/000092.html>,
+    for example.  Do we need this, too?
+
+  * Eclipse
+
+    OK for testing -- but I'd very much hope that it *just works* as soon as we
+    provide the required Java platform.  But it may perhaps have some
+    Linux-specifics (needlessly?) in its basement.  Is it available for Debian
+    GNU/kFreeBSD already?
+
+
 ### Java bindings for Mach
 
+
+#### Plans
+
 (just started.)
 
 
+##### Open Items
+
+  * [[tschwinge]] has to read about RMI and CORBA.
+
+  * MIG
+
+      * Hacking [[microkernel/mach/MIG]] shouldn't be too difficult.
+
+          * (Unless you want to make MIG's own code (that is, not the generated
+            code, but MIG itself) look a bit more nice, too.)  ;-)
+
+      * There are also alternatives to MIG.  If there is interest, the following
+        could be considered:
+
+          * FLICK ([[!GNU_Savannah_task 5723]]).  [[tschwinge]] has no idea yet if
+            there would be any benefits over MIG, like better modularity (for the
+            backends)?  If we feel like it, we could spend a little bit of time on
+            this.
+
+          * For [[microkernel/Viengoos]], Neal has written a RPC stub generator
+            entirely in C Preprocessor macros.  While this is obviously not
+            directly applicable, perhaps we can get some ideas from it.
+
+          * Anything else that would be worth having a look at?  (What are other
+            microkernels using?)
+
+  * `mach_msg`
+
+      * Seems like the right approach to [[tschwinge]], but he hasn't digested
+        all the pecularities yet.  Will definitely need more time.
+
+
+## Postponed
+
+Might get back to these as time/interest permits.
+
+
+### GCJ
+
+  * [[tschwinge]] has the feeling that Java in GCC (that is, GCJ) is mostly
+    dead?  (True?)
+
+  * Thus perhaps not too much effort should be spent with it.
+
+    If the POSIX threads signal semantics makes it going, then great, otherwise
+    we should get a feeling what else is missing.
+
+
+### Joe-E.