summaryrefslogtreecommitdiff
path: root/user/jkoenig
diff options
context:
space:
mode:
authorJeremie Koenig <jk@jk.fr.eu.org>2011-04-08 16:31:41 +0200
committerJeremie Koenig <jk@jk.fr.eu.org>2011-04-08 18:03:03 +0200
commitcd48e7119c3634550411daa66c3a617082d39630 (patch)
treed44ceb374c82cadf738debabd06a0de9d5209110 /user/jkoenig
parentb02cb9177df853ffef97e73f98a31b4204479747 (diff)
gsoc2011 (java): improve the structure of the proposal
Diffstat (limited to 'user/jkoenig')
-rw-r--r--user/jkoenig/gsoc2011_proposal.mdwn54
1 files changed, 41 insertions, 13 deletions
diff --git a/user/jkoenig/gsoc2011_proposal.mdwn b/user/jkoenig/gsoc2011_proposal.mdwn
index d9617ab5..e8f7679b 100644
--- a/user/jkoenig/gsoc2011_proposal.mdwn
+++ b/user/jkoenig/gsoc2011_proposal.mdwn
@@ -146,6 +146,14 @@ which makes some packages fail to build on Hurd
proposal). Porting Eclipse would be a good opportunity to test GCJ and
OpenJDK.
+### Deliverables
+
+ * The glibc pthreads patch and any other fixes on the Hurd side
+ would be submitted upstream
+ * Patches against Debian source packages
+ required to make them build on Hurd would be submitted
+ to the [Debian bug tracking system](http://bugs.debian.org/).
+
## Create Java bindings for the Hurd interfaces
@@ -172,7 +180,33 @@ to begin experimenting with what makes Hurd unique
without being faced right away with the complexity of
low-level systems programming.
-### Approach
+### Tasks summary
+
+ * Implement Java bindings for Mach
+ * Implement a libports-like library for Java
+ * Modify MIG to output Java code
+ * Implement libfoofs-like Java libraries
+
+### Design principles
+
+The principles I would use to guide the design
+of these Java bindings would be the following ones:
+ * The system should be hooked into at a low level,
+ to ensure that Java is a "first class citizen"
+ as far as the access to the Hurd's interfaces is concerned.
+ * At the same time, the memory safety of Java should be maintained
+ and extended to Mach primitives such as port names and
+ out-of-line memory regions.
+ * Higher-level interfaces should be provided as well
+ in order to make translator development
+ as easy as possible.
+ * A minimum amount of JNI code (ie. C code) should be used.
+ Most of the system should be built using Java itself
+ on top of a few low-level primitives.
+ * Hurd objects would map to Java objects.
+ * Using the same interfaces,
+ objects corresponding to local ports would be accessed directly,
+ and remote objects would be accessed over IPC.
One approach used previously to interface programming languages with the Hurd
has been to create bindings for helper libraries such as libtrivfs. Instead,
@@ -186,17 +220,6 @@ However, once an initial implementation is done it would be easier to maintain
in the long run and we would be able to provide Java bindings for a large
percentage of the Hurd’s interfaces.
-### Design goals
-
-FIXME: a completer
-
- * Give maximum flexibility to the Java code while maintaining the memory
- safety of Java, and using a minimum amount of C code.
- * Provide higher-level interfaces as well, ...
- * Hurd objects would map to Java objects.
- * Local objects can be accessed directly,
- remote objects can be accessed transparently over IPC.
-
### Bindings for Mach system calls
In this low-level approach, my intention is to enable Java code to use Mach
@@ -444,7 +467,12 @@ to implement the required ones.
I would draw inspiration from libtrivfs and libnetfs
to design and implement similar solutions for Java.
-### Packaging and long-term maintenance
+### Deliverables
+
+ * A hurd-java package would contain the Java code developped
+ in the context of this project.
+ * Modifications to MIG would be submitted upstream,
+ or a patched MIG package would be made available.
The Java libraries resulting from this work,
including any MIG support classes