[RFC/PATCH] Invokedynamic API stubs
Hi!
I'd like to check in these simple invokedynamic API stubs into CVS HEAD.
The APIs are not final but I think now is as good time as any to start
working on them especially as it needs work on the VM side. Furthermore,
there's already open source projects such as JRuby out there that use
invokedynamic so I think GNU Classpath probably needs to support it at
some point anyway.
Pekka
>From 6dca9b60d6c2380164920e40302f08616a6874b6 Mon Sep 17 00:00:00 2001
From: Pekka Enberg
Date: Thu, 3 Feb 2011 16:47:15 +0200
Subject: [PATCH] Invokedynamic API stubs
This patch implements the work-in-progress invokedynamic API stubs described
here:
http://download.oracle.com/javase/7/docs/api/java/dyn/package-summary.html
The classes don't do anything useful yet and don't even contain all the
specified methods.
Signed-off-by: Pekka Enberg
---
java/lang/dyn/BootstrapMethod.java | 52 +
java/lang/dyn/CallSite.java| 57 +++
java/lang/dyn/ClassValue.java | 45 ++
java/lang/dyn/ConstantCallSite.java| 46 ++
java/lang/dyn/InvokeDynamic.java | 49
java/lang/dyn/InvokeDynamicBootstrapError.java | 47 +++
java/lang/dyn/Linkage.java | 45 ++
java/lang/dyn/LinkagePermission.java | 55 ++
java/lang/dyn/MethodHandle.java| 59
java/lang/dyn/MethodHandleProvider.java| 52 +
java/lang/dyn/MethodHandles.java | 52 +
java/lang/dyn/MethodType.java | 50
java/lang/dyn/NoAccessException.java | 47 +++
java/lang/dyn/WrongMethodTypeException.java| 47 +++
14 files changed, 703 insertions(+), 0 deletions(-)
create mode 100644 java/lang/dyn/BootstrapMethod.java
create mode 100644 java/lang/dyn/CallSite.java
create mode 100644 java/lang/dyn/ClassValue.java
create mode 100644 java/lang/dyn/ConstantCallSite.java
create mode 100644 java/lang/dyn/InvokeDynamic.java
create mode 100644 java/lang/dyn/InvokeDynamicBootstrapError.java
create mode 100644 java/lang/dyn/Linkage.java
create mode 100644 java/lang/dyn/LinkagePermission.java
create mode 100644 java/lang/dyn/MethodHandle.java
create mode 100644 java/lang/dyn/MethodHandleProvider.java
create mode 100644 java/lang/dyn/MethodHandles.java
create mode 100644 java/lang/dyn/MethodType.java
create mode 100644 java/lang/dyn/NoAccessException.java
create mode 100644 java/lang/dyn/WrongMethodTypeException.java
diff --git a/java/lang/dyn/BootstrapMethod.java
b/java/lang/dyn/BootstrapMethod.java
new file mode 100644
index 000..d2ec24a
--- /dev/null
+++ b/java/lang/dyn/BootstrapMethod.java
@@ -0,0 +1,52 @@
+/* BootstrapMethod.java --
+ Copyright (C) 2011 Free Software Foundation
+
+This file is part of GNU Classpath.
+
+GNU Classpath is free software; you can redistribute it and/or modify
+it under the terms of the GNU General Public License as published by
+the Free Software Foundation; either version 2, or (at your option)
+any later version.
+
+GNU Classpath is distributed in the hope that it will be useful, but
+WITHOUT ANY WARRANTY; without even the implied warranty of
+MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+General Public License for more details.
+
+You should have received a copy of the GNU General Public License
+along with GNU Classpath; see the file COPYING. If not, write to the
+Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
+02110-1301 USA.
+
+Linking this library statically or dynamically with other modules is
+making a combined work based on this library. Thus, the terms and
+conditions of the GNU General Public License cover the whole
+combination.
+
+As a special exception, the copyright holders of this library give you
+permission to link this library with independent modules to produce an
+executable, regardless of the license terms of these independent
+modules, and to copy and distribute the resulting executable under
+terms of your choice, provided that you also meet, for each linked
+independent module, the terms and conditions of the license of that
+module. An independent module is a module which is not derived from
+or based on this library. If you modify this library, you may extend
+this exception to your version of the library, but you are not
+obligated to do so. If you do not wish to do so, delete this
+exception statement from your version. */
+
+package java.dyn;
+
+import java.lang.annotation.Retention;
+import java.lang.annotation.Target;
+import static java.lang.annotation.RetentionPolicy.SOURCE;
+import static java.lang.annotation.ElementType.*;
+
+/**
+ * @since 1.7
+ */
+@Target(value={/*TYPE_USE,*/TY
Re: [RFC/PATCH] Invokedynamic API stubs
Hi Pekka, On Thu, 2011-02-03 at 16:47 +0200, Pekka Enberg wrote: > I'd like to check in these simple invokedynamic API stubs into CVS HEAD. > The APIs are not final but I think now is as good time as any to start > working on them especially as it needs work on the VM side. Furthermore, > there's already open source projects such as JRuby out there that use > invokedynamic so I think GNU Classpath probably needs to support it at > some point anyway. > The classes don't do anything useful yet and don't even contain all > the specified methods. I have to admit that I don't like putting in stubs. In the past we have decided to just leave things really unimplemented if we don't support it. And as you say it needs a bit more design thinking. So I would suggest you do this on a branch first (grmbl CVS...) and/or first try to spec it out against a jato VM implementation. BTW. John Rose has lots of background material online: http://cr.openjdk.java.net/~jrose/pres/ Cheers, Mark
Re: [RFC/PATCH] Invokedynamic API stubs
On Fri, Feb 04, 2011 at 09:11:50AM +0100, Mark Wielaard wrote: > Hi Pekka, > > On Thu, 2011-02-03 at 16:47 +0200, Pekka Enberg wrote: > > I'd like to check in these simple invokedynamic API stubs into CVS HEAD. > > The APIs are not final but I think now is as good time as any to start > > working on them especially as it needs work on the VM side. Furthermore, > > there's already open source projects such as JRuby out there that use > > invokedynamic so I think GNU Classpath probably needs to support it at > > some point anyway. > > > The classes don't do anything useful yet and don't even contain all > > the specified methods. > > I have to admit that I don't like putting in stubs. In the past we have > decided to just leave things really unimplemented if we don't support > it. And as you say it needs a bit more design thinking. So I would > suggest you do this on a branch first (grmbl CVS...) and/or first try to > spec it out against a jato VM implementation. > I'd also rather see implementation than stubs :-) Or if you do add stubs, please use the gnu.classpath.NotImplementedException to mark them as such. Also, as JDK7 stuff, I don't think this is 100% final yet. There's lots of JDK6 stuff that needs doing :-D > BTW. John Rose has lots of background material online: > http://cr.openjdk.java.net/~jrose/pres/ > > Cheers, > > Mark > > -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and IcedTea http://www.gnu.org/software/classpath http://icedtea.classpath.org PGP Key: F5862A37 (https://keys.indymedia.org/) Fingerprint = EA30 D855 D50F 90CD F54D 0698 0713 C3ED F586 2A37
Re: [RFC/PATCH] Invokedynamic API stubs
Hi! On Thu, 2011-02-03 at 16:47 +0200, Pekka Enberg wrote: >> I'd like to check in these simple invokedynamic API stubs into CVS HEAD. >> The APIs are not final but I think now is as good time as any to start >> working on them especially as it needs work on the VM side. Furthermore, >> there's already open source projects such as JRuby out there that use >> invokedynamic so I think GNU Classpath probably needs to support it at >> some point anyway. > >> The classes don't do anything useful yet and don't even contain all >> the specified methods. On Fri, Feb 4, 2011 at 10:11 AM, Mark Wielaard wrote: > I have to admit that I don't like putting in stubs. In the past we have > decided to just leave things really unimplemented if we don't support > it. And as you say it needs a bit more design thinking. So I would > suggest you do this on a branch first (grmbl CVS...) and/or first try to > spec it out against a jato VM implementation. Sure, I want to start looking at implementing invokedynamic for Jato which is why I implemented these stubs in the first place. I expect that to take some time so the question is where to put the work-in-progress implementation. I don't see any reason to keep it stashed on my local hard disk but I have to admit I'm not entirely happy with the idea of using CVS branches for it either... I guess I could keep it on my Github mirror until I have something concrete enough to be merged to trunk. On Fri, Feb 4, 2011 at 10:11 AM, Mark Wielaard wrote: > BTW. John Rose has lots of background material online: > http://cr.openjdk.java.net/~jrose/pres/ Thanks! Pekka
Re: [RFC/PATCH] Invokedynamic API stubs
On 7 February 2011 11:30, Pekka Enberg wrote: > Hi! > > On Thu, 2011-02-03 at 16:47 +0200, Pekka Enberg wrote: >>> I'd like to check in these simple invokedynamic API stubs into CVS HEAD. >>> The APIs are not final but I think now is as good time as any to start >>> working on them especially as it needs work on the VM side. Furthermore, >>> there's already open source projects such as JRuby out there that use >>> invokedynamic so I think GNU Classpath probably needs to support it at >>> some point anyway. >> >>> The classes don't do anything useful yet and don't even contain all >>> the specified methods. > > On Fri, Feb 4, 2011 at 10:11 AM, Mark Wielaard wrote: >> I have to admit that I don't like putting in stubs. In the past we have >> decided to just leave things really unimplemented if we don't support >> it. And as you say it needs a bit more design thinking. So I would >> suggest you do this on a branch first (grmbl CVS...) and/or first try to >> spec it out against a jato VM implementation. > > Sure, I want to start looking at implementing invokedynamic for Jato > which is why I implemented these stubs in the first place. I expect > that to take some time so the question is where to put the > work-in-progress implementation. I don't see any reason to keep it > stashed on my local hard disk but I have to admit I'm not entirely > happy with the idea of using CVS branches for it either... > > I guess I could keep it on my Github mirror until I have something > concrete enough to be merged to trunk. > I'd prefer to have it in HEAD as long as it's clearly marked as stubs (the NotImplementedException I mentioned) and there is work actively taking place. Then there's always the (slim) possibility someone else can work on it :-) > On Fri, Feb 4, 2011 at 10:11 AM, Mark Wielaard wrote: >> BTW. John Rose has lots of background material online: >> http://cr.openjdk.java.net/~jrose/pres/ > > Thanks! > > Pekka > > -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: F5862A37 (https://keys.indymedia.org/) Fingerprint = EA30 D855 D50F 90CD F54D 0698 0713 C3ED F586 2A37
Re: [RFC/PATCH] Invokedynamic API stubs
On Mon, 2011-02-07 at 15:24 +0100, Dr Andrew John Hughes wrote: > > I guess I could keep it on my Github mirror until I have something > > concrete enough to be merged to trunk. > > > I'd prefer to have it in HEAD as long as it's clearly marked as stubs > (the NotImplementedException I mentioned) and there is work actively > taking place. > Then there's always the (slim) possibility someone else can work on it :-) That was my original thinking as well. Does the included patch look better to you? Mark, what do you think about this? Pekka >From 81362427a842e815bfe354036cd4201ee781880a Mon Sep 17 00:00:00 2001 From: Pekka Enberg Date: Thu, 3 Feb 2011 16:29:15 +0200 Subject: [PATCH] Invokedynamic API stubs This patch implements the work-in-progress invokedynamic API stubs described here: http://download.oracle.com/javase/7/docs/api/java/dyn/package-summary.html The classes don't do anything useful yet and don't even contain all the specified methods. Signed-off-by: Pekka Enberg --- java/dyn/BootstrapMethod.java | 52 java/dyn/CallSite.java| 60 java/dyn/ClassValue.java | 45 + java/dyn/ConstantCallSite.java| 46 + java/dyn/InvokeDynamic.java | 49 +++ java/dyn/InvokeDynamicBootstrapError.java | 47 ++ java/dyn/Linkage.java | 45 + java/dyn/LinkagePermission.java | 56 ++ java/dyn/MethodHandle.java| 62 + java/dyn/MethodHandleProvider.java| 52 java/dyn/MethodHandles.java | 52 java/dyn/MethodType.java | 50 +++ java/dyn/NoAccessException.java | 47 ++ java/dyn/WrongMethodTypeException.java| 47 ++ 14 files changed, 710 insertions(+), 0 deletions(-) create mode 100644 java/dyn/BootstrapMethod.java create mode 100644 java/dyn/CallSite.java create mode 100644 java/dyn/ClassValue.java create mode 100644 java/dyn/ConstantCallSite.java create mode 100644 java/dyn/InvokeDynamic.java create mode 100644 java/dyn/InvokeDynamicBootstrapError.java create mode 100644 java/dyn/Linkage.java create mode 100644 java/dyn/LinkagePermission.java create mode 100644 java/dyn/MethodHandle.java create mode 100644 java/dyn/MethodHandleProvider.java create mode 100644 java/dyn/MethodHandles.java create mode 100644 java/dyn/MethodType.java create mode 100644 java/dyn/NoAccessException.java create mode 100644 java/dyn/WrongMethodTypeException.java diff --git a/java/dyn/BootstrapMethod.java b/java/dyn/BootstrapMethod.java new file mode 100644 index 000..d2ec24a --- /dev/null +++ b/java/dyn/BootstrapMethod.java @@ -0,0 +1,52 @@ +/* BootstrapMethod.java -- + Copyright (C) 2011 Free Software Foundation + +This file is part of GNU Classpath. + +GNU Classpath is free software; you can redistribute it and/or modify +it under the terms of the GNU General Public License as published by +the Free Software Foundation; either version 2, or (at your option) +any later version. + +GNU Classpath is distributed in the hope that it will be useful, but +WITHOUT ANY WARRANTY; without even the implied warranty of +MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU +General Public License for more details. + +You should have received a copy of the GNU General Public License +along with GNU Classpath; see the file COPYING. If not, write to the +Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA +02110-1301 USA. + +Linking this library statically or dynamically with other modules is +making a combined work based on this library. Thus, the terms and +conditions of the GNU General Public License cover the whole +combination. + +As a special exception, the copyright holders of this library give you +permission to link this library with independent modules to produce an +executable, regardless of the license terms of these independent +modules, and to copy and distribute the resulting executable under +terms of your choice, provided that you also meet, for each linked +independent module, the terms and conditions of the license of that +module. An independent module is a module which is not derived from +or based on this library. If you modify this library, you may extend +this exception to your version of the library, but you are not +obligated to do so. If you do not wish to do so, delete this +exception statement from your version. */ + +package java.dyn; + +import java.lang.annotation.Retention; +import java.lang.annotation.Target; +import static java.lang.annotation.RetentionPolicy.SOURCE; +import static java.lang.annotation.ElementType.*; + +/** + *
Re: [RFC/PATCH] Invokedynamic API stubs
On Mon, 2011-02-07 at 22:01 +0200, Pekka Enberg wrote: > On Mon, 2011-02-07 at 15:24 +0100, Dr Andrew John Hughes wrote: > > > I guess I could keep it on my Github mirror until I have something > > > concrete enough to be merged to trunk. > > > > > I'd prefer to have it in HEAD as long as it's clearly marked as stubs > > (the NotImplementedException I mentioned) and there is work actively > > taking place. > > Then there's always the (slim) possibility someone else can work on it :-) > > That was my original thinking as well. Does the included patch look > better to you? Mark, what do you think about this? I admit to still just not like stubs, however they are setup. If creating branches wasn't such a pain with CVS I would really recommend doing all this on a branch and only merge when ready and it can actually be used with some VM. I guess it is just time to bite the bullet and create some time to move to mercurial and setup some rules about how to create working branches. I won't veto getting this in right now if that is really what you and Andrew want, but I am not particularly excited either. > This patch implements the work-in-progress invokedynamic API stubs described > here: > > http://download.oracle.com/javase/7/docs/api/java/dyn/package-summary.html > > The classes don't do anything useful yet and don't even contain all the > specified methods. Might be better to find some other reference to point people at. This screams it isn't finished yet, might move. I don't have a good suggestion though. The java doc in OpenJDK is distributed under the GPL though, but doesn't seem to be online yet. Cheers, Mark
Re: [RFC/PATCH] Invokedynamic API stubs
Hi Mark, On Mon, 2011-02-07 at 15:24 +0100, Dr Andrew John Hughes wrote: >> > > I guess I could keep it on my Github mirror until I have something >> > > concrete enough to be merged to trunk. >> > > >> > I'd prefer to have it in HEAD as long as it's clearly marked as stubs >> > (the NotImplementedException I mentioned) and there is work actively >> > taking place. >> > Then there's always the (slim) possibility someone else can work on it :-) On Mon, 2011-02-07 at 22:01 +0200, Pekka Enberg wrote: >> That was my original thinking as well. Does the included patch look >> better to you? Mark, what do you think about this? On Tue, Feb 8, 2011 at 2:28 PM, Mark Wielaard wrote: > I admit to still just not like stubs, however they are setup. > If creating branches wasn't such a pain with CVS I would really > recommend doing all this on a branch and only merge when ready and it > can actually be used with some VM. I guess it is just time to bite the > bullet and create some time to move to mercurial and setup some rules > about how to create working branches. I won't veto getting this in right > now if that is really what you and Andrew want, but I am not > particularly excited either. Well, I'd like to keep everyone involved excited so maybe Mercural branch is the way to go here? Pekka
Re: [RFC/PATCH] Invokedynamic API stubs
On 13:28 Tue 08 Feb , Mark Wielaard wrote: > On Mon, 2011-02-07 at 22:01 +0200, Pekka Enberg wrote: > > On Mon, 2011-02-07 at 15:24 +0100, Dr Andrew John Hughes wrote: > > > > I guess I could keep it on my Github mirror until I have something > > > > concrete enough to be merged to trunk. > > > > > > > I'd prefer to have it in HEAD as long as it's clearly marked as stubs > > > (the NotImplementedException I mentioned) and there is work actively > > > taking place. > > > Then there's always the (slim) possibility someone else can work on it :-) > > > > That was my original thinking as well. Does the included patch look > > better to you? Mark, what do you think about this? > > I admit to still just not like stubs, however they are setup. > If creating branches wasn't such a pain with CVS I would really > recommend doing all this on a branch and only merge when ready and it > can actually be used with some VM. I guess it is just time to bite the > bullet and create some time to move to mercurial and setup some rules > about how to create working branches. I won't veto getting this in right > now if that is really what you and Andrew want, but I am not > particularly excited either. > I assume by Mercurial 'branching', you mean what we do with IcedTea6 HEAD and the releases at present, not the in-tree support? Because that's worse than CVS IME. > > This patch implements the work-in-progress invokedynamic API stubs described > > here: > > > > http://download.oracle.com/javase/7/docs/api/java/dyn/package-summary.html > > > > The classes don't do anything useful yet and don't even contain all the > > specified methods. > > Might be better to find some other reference to point people at. This > screams it isn't finished yet, might move. I don't have a good > suggestion though. The java doc in OpenJDK is distributed under the GPL > though, but doesn't seem to be online yet. > Is there anything stopping us having the docs generated by IcedTea online? Maybe the builder could produce them? > Cheers, > > Mark > > > -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and IcedTea http://www.gnu.org/software/classpath http://icedtea.classpath.org PGP Key: F5862A37 (https://keys.indymedia.org/) Fingerprint = EA30 D855 D50F 90CD F54D 0698 0713 C3ED F586 2A37
Re: [RFC/PATCH] Invokedynamic API stubs
On 7 February 2011 20:01, Pekka Enberg wrote: > On Mon, 2011-02-07 at 15:24 +0100, Dr Andrew John Hughes wrote: >> > I guess I could keep it on my Github mirror until I have something >> > concrete enough to be merged to trunk. >> > >> I'd prefer to have it in HEAD as long as it's clearly marked as stubs >> (the NotImplementedException I mentioned) and there is work actively >> taking place. >> Then there's always the (slim) possibility someone else can work on it :-) > > That was my original thinking as well. Does the included patch look > better to you? Mark, what do you think about this? > > Pekka > In case nobody else has noticed : "The package for JSR 292 is no longer java.dyn. It is java.lang.invoke" http://blogs.sun.com/jrose/entry/jsr_292_formal_public_review Rob. > From 81362427a842e815bfe354036cd4201ee781880a Mon Sep 17 00:00:00 2001 > From: Pekka Enberg > Date: Thu, 3 Feb 2011 16:29:15 +0200 > Subject: [PATCH] Invokedynamic API stubs > > This patch implements the work-in-progress invokedynamic API stubs described > here: > > http://download.oracle.com/javase/7/docs/api/java/dyn/package-summary.html > > The classes don't do anything useful yet and don't even contain all the > specified methods. > > Signed-off-by: Pekka Enberg > --- > java/dyn/BootstrapMethod.java | 52 > java/dyn/CallSite.java | 60 > java/dyn/ClassValue.java | 45 + > java/dyn/ConstantCallSite.java | 46 + > java/dyn/InvokeDynamic.java | 49 +++ > java/dyn/InvokeDynamicBootstrapError.java | 47 ++ > java/dyn/Linkage.java | 45 + > java/dyn/LinkagePermission.java | 56 ++ > java/dyn/MethodHandle.java | 62 > + > java/dyn/MethodHandleProvider.java | 52 > java/dyn/MethodHandles.java | 52 > java/dyn/MethodType.java | 50 +++ > java/dyn/NoAccessException.java | 47 ++ > java/dyn/WrongMethodTypeException.java | 47 ++
Re: [RFC/PATCH] Invokedynamic API stubs
On Tue, 2011-02-08 at 21:52 +, Dr Andrew John Hughes wrote: > I assume by Mercurial 'branching', you mean what we do with IcedTea6 HEAD > and the releases at present, not the in-tree support? Because that's worse > than CVS IME. I don't know yet. The in-tree support was bad pre-1.0. But that was years ago. Are you sure it is still not workable? I'll try and figure out what savannah supports soon. > > > This patch implements the work-in-progress invokedynamic API stubs > > > described > > > here: > > > > > > > > > http://download.oracle.com/javase/7/docs/api/java/dyn/package-summary.html > > > > > > The classes don't do anything useful yet and don't even contain all the > > > specified methods. > > > > Might be better to find some other reference to point people at. This > > screams it isn't finished yet, might move. I don't have a good > > suggestion though. The java doc in OpenJDK is distributed under the GPL > > though, but doesn't seem to be online yet. > > Is there anything stopping us having the docs generated by IcedTea online? > Maybe the builder could produce them? The builder does already produce them, it just doesn't publish them anywhere yet :) I'll look into pushing them public somewhere. Probably to the main icedtea server. And as Robert just pointed out John Rose has been keeping a GPL derived version of the spec/javadoc here: http://cr.openjdk.java.net/~jrose/pres/indy-javadoc-mlvm/ Cheers, Mark
Re: [RFC/PATCH] Invokedynamic API stubs
On 9 February 2011 14:24, Mark Wielaard wrote: > On Tue, 2011-02-08 at 21:52 +, Dr Andrew John Hughes wrote: >> I assume by Mercurial 'branching', you mean what we do with IcedTea6 HEAD >> and the releases at present, not the in-tree support? Because that's worse >> than CVS IME. > > I don't know yet. The in-tree support was bad pre-1.0. But that was > years ago. Are you sure it is still not workable? > I'll try and figure out what savannah supports soon. > No, but I don't really have time to look into it either. Let's just keep with what we know for now. >> > > This patch implements the work-in-progress invokedynamic API stubs >> > > described >> > > here: >> > > >> > > >> > > http://download.oracle.com/javase/7/docs/api/java/dyn/package-summary.html >> > > >> > > The classes don't do anything useful yet and don't even contain all the >> > > specified methods. >> > >> > Might be better to find some other reference to point people at. This >> > screams it isn't finished yet, might move. I don't have a good >> > suggestion though. The java doc in OpenJDK is distributed under the GPL >> > though, but doesn't seem to be online yet. >> >> Is there anything stopping us having the docs generated by IcedTea online? >> Maybe the builder could produce them? > > The builder does already produce them, it just doesn't publish them > anywhere yet :) I'll look into pushing them public somewhere. Probably > to the main icedtea server. > > And as Robert just pointed out John Rose has been keeping a GPL derived > version of the spec/javadoc here: > http://cr.openjdk.java.net/~jrose/pres/indy-javadoc-mlvm/ I think we need public ones from both IcedTea 6 & 7 so we know what they are based on. > Cheers, > > Mark > > > -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8
