Re: [RFC/PATCH] Invokedynamic API stubs

2011-02-07 Thread Pekka Enberg
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 m...@klomp.org 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 m...@klomp.org 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

2011-02-07 Thread Dr Andrew John Hughes
On 7 February 2011 11:30, Pekka Enberg penb...@kernel.org 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 m...@klomp.org 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 m...@klomp.org 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

2011-02-07 Thread Pekka Enberg
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 penb...@kernel.org
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 penb...@kernel.org
---
 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