It would be nice to ship a byte code generation/manipulation package as
part of the JVM since this would encourage many new types of libraries and
applications. It would also be nice if the JVM didn't grow much! Therefore
in the ideal world ASM would be publicly exposed and just the extra
patching
, Jul 3, 2012 at 1:28 PM, Howard Lovatt wrote:
>
>> I like the idea and something along these lines would be a great addition
>> to the standard library, which I will come back to as a PS.
>>
>> In com.sun.misc.Unsafe there are already getLong(Object, int) and
>>
I like the idea and something along these lines would be a great addition
to the standard library, which I will come back to as a PS.
In com.sun.misc.Unsafe there are already getLong(Object, int) and
setLong(Object, int, long) methods and the same for Object. No doubt if we
used getLong and setLon
It would be really nice if you could have a class that was something like
Double with overflow check initially and then when you detect an overflow
substitute in something like BigDecimal instead, i.e. hot swapping of the
object's class. This saves having to have a class with two fields and
checkin
ch 2011 10:53, John Rose wrote:
> On Mar 28, 2011, at 4:43 PM, Howard Lovatt wrote:
>
>> a) Easy to do
>
> Yes, it's easy to do. (Done now with Proxy, in a poor-man's way, and simple
> to improve upon.)
>
>> b) Doesn't prevent anything Project Lambda
I find this a difficult question because I haven't had chance to
experiment enough with them for my application; multiple dispatch.
asInterface is potentially useful but I need to trial different
approaches, which is currently work in progress. Therefore my answer
is include asInterface if it is:
Good idea, invoke seems natural since the conversions are the normal Java
conversions and the term generic does make you think of generics.
-- Howard Lovatt +61 419 971 263 (sent from my PDA)
On 27/03/2011, at 8:08 AM, John Rose wrote:
> One bit of review feedback we've gotte
e great work,
-- Howard.
On 23 March 2011 12:52, John Rose wrote:
> On Mar 6, 2011, at 3:25 PM, Howard Lovatt wrote:
>
>> The new API looks great. I think all the simplifications made,
>> particularly around CallSite and no longer having a Bootstrap, have
>> really helpe
On 22 March 2011 12:13, Charles Oliver Nutter wrote:
[snip]
>>
>> MethodHandle handle = Binder
>> .from(String.class, Integer.class, Float.class, String.class)
>> .invoke(target, Binder.arg(3), new File("foo"), Binder.arg(3));
A variation on this theme might be
Hi Charles,
Yes it is interesting to me, looks much easier to use and also nice
that you can chain calls because they are instance methods rather than
static functions.
I will give it a try once you have a version to download.
-- Howard.
On 21 March 2011 17:21, Charles Oliver Nutter wrote:
>
Yes, it is a file I am using to learn/experiment with lambdas.
On 18 March 2011 20:31, Christian Thalinger
wrote:
> On Mar 17, 2011, at 11:12 PM, Howard Lovatt wrote:
>> Hi Christian,
>>
>> Thanks for looking into this bug. It is possible that the bug is due
>> to a pr
further into this. Incase you want to proceed anyway I have
attached my test files.
Thanks again,
-- Howard.
On 17 March 2011 23:43, Christian Thalinger
wrote:
> On Mar 14, 2011, at 2:28 PM, Christian Thalinger wrote:
>> On Mar 7, 2011, at 10:15 AM, Howard Lovatt wrote:
>>> Hi,
x wrote:
> On 03/09/2011 12:15 AM, Howard Lovatt wrote:
>> R?mi Forax wrote:
>>> Hi Howard,
>>> thank you for your comments.
>>>
>>> On 03/07/2011 12:25 AM, Howard Lovatt wrote:
>>>> The new API looks great. I think all the simplifications m
R?mi Forax wrote:
> Hi Howard,
> thank you for your comments.
>
> On 03/07/2011 12:25 AM, Howard Lovatt wrote:
>> The new API looks great. I think all the simplifications made,
>> particularly around CallSite and no longer having a Bootstrap, have
>> really helped.
Hi,
I got the following when trying to use CallSites on Stephen Bannasch's
latest build (which isn't the latest latest build and therefore this
issue might have been found already):
# To suppress the following error report, specify this argument
# after -XX: or in .hotspotrc: SuppressErrorAt=/re
Another couple of nit picky Javadoc comments:
1. Constructor MutableCallSite(MethodType) doesn't describe its argument.
2. Constructor MutableCallSite(MethodHandle) says "Make a blank call
site object, possibly equipped with an initial target method handle.",
but a non-null target ius required.
-
I have found the following class useful for something similar, don't
know if it will be of help:
/** A {@link MutableCallSite} that can be reset to its initial target. */
public static class ResetableCallSite extends MutableCallSite {
private MethodHandle reset = null;
/**
* Make
The new API looks great. I think all the simplifications made,
particularly around CallSite and no longer having a Bootstrap, have
really helped. The methods isWrapperInstance, wrappedInstanceTarget,
and wrapperInstanceType are nice additions to the API.
The requirement that a SAM (in MethodHandle
Using Stephen's Mac OS X builds I find that the latest build:
java (JVM) Version:
openjdk version "1.7.0-internal-fastdebug"
OpenJDK Runtime Environment (build
1.7.0-internal-fastdebug-stephen_2011_02_07_15_42-b00)
Has a problem with a method reference:
final ActionListener al4 = Main#print(
Works great. Many thanks.
-- Howard.
___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
Many thanks Stephen, that build fixes the problem I was seeing.
On 24 December 2010 16:16, Stephen Bannasch
wrote:
> At 10:18 AM +1100 12/24/10, Howard Lovatt wrote:
>>Hi Stephen,
>>
>>John Rose has just fixed a bug that was affecting me:
>>
>>> Fixed. -- J
Hi Stephen,
John Rose has just fixed a bug that was affecting me:
> Fixed. -- John
>
> On Dec 23, 2010, at 3:36 AM, Christian Thalinger wrote:
>
> That seems to be a problem in meth-conv-6939861. MethodHandles::verify_klass
> should use jcc instead of jccb. John, will you fix it or should I t
Hi,
When I use this version on my lambda test code I get the following error:
VM option '+UnlockExperimentalVMOptions'
VM option '+EnableMethodHandles'
VM option '+EnableInvokeDynamic'
VM option 'SuppressErrorAt=/constantPoolOop.cpp:283'
# To suppress the following error report, specify this argu
I posted the following observation about different versions of the
MLVM on Lambda Dev and at the suggestion of Rémi Forax I am reposting
here. The following code:
class Test {
public static void print(ActionEvent e) { System.out.println("Hello!"); }
public static void main(String[] args
There are some minor Java Doc Bugs in:
http://cr.openjdk.java.net/~jrose/pres/indy-javadoc-mlvm/
In particular the Java Doc for:
MethodHandles.dropArguments
The example given is incorrect and should be something like:
final MethodType types = MethodType.methodType( String.class
@ Attila
> It strikes me as a mildly bad idea to be compiling within your Dropbox... :-)
Very observant. I normally turn drop box off, but surprisingly it
copes OK with a few 10's of files getting recompiled.
-- Howard.
___
mlvm-dev mailing list
mlvm
There is a minor bug when you use -Xlint:all, I get:
Compiling 1 source file to
/Users/lov080/Dropbox/Personal/Java/examples/Invoke Dynamic Multiple
Dispatch/build/classes
/Users/lov080/Dropbox/Personal/Java/examples/Invoke Dynamic Multiple
Dispatch/src/invokedynamicmultipledispatch/Cost.java:61:
Hi,
Glad to see such great progress.
Are there any examples/documentation/etc. that shows how the new
per-instruction BSMs work?
Keep up the good work,
-- Howard.
___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailm
Hi,
Glad to see such great progress.
Are there any examples/documentation/etc. that shows how the new
per-instruction BSMs work?
Keep up the good work,
-- Howard.
___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailm
Rémi Forax forax at univ-mlv.fr Tue Jun 22 05:30:48 PDT 2010 wrote:
> Le 22/06/2010 12:48, Howard Lovatt a écrit :
>> A couple of comments on the current MethodHandle API:
>>
>> 1. Having only one bootstrap method for InvokeDynamic is a bit
>> limiting, it it possib
A couple of comments on the current MethodHandle API:
1. Having only one bootstrap method for InvokeDynamic is a bit
limiting, it it possible to have one per use site?
2. Has thought been given to using the .( args ) notation (or what
ever it ends up as) from lambda dev for invokeGeneric( args )?
ve found the bug,
> in Dispatcher you use collectArguments instead of convertArguments.
>
> Rémi
>
>
> Le 21/06/2010 04:26, Howard Lovatt a écrit :
>>
>> Hi Rémi,
>>
>> A more complete listing is:
>>
>> public final class CostCalculatorDi
multiple dispatch method
*/
private static MethodHandle nearest( final Collection
mhs, final MethodType type )
throws MultipleDispatchException, PECBug {
[snip]
}
[snip]
}
Your help is much appreciated,
-- Howard.
On 19 June 2010 21:00, Rémi Fora
@Rémi,
Thanks for the advise about using a "slowPath" method to discover the
runtime types. I have coded up something along the lines you
suggested:
private static double slowPath( final CallSite callSite, final
CostCalculator cC, final Item i ) throws Throwable {
System.out.println("callSi
Thanks for the help.
The suggested solution doesn't work, I get a different error:
wizziewol-ln:Invoke Dynamic Multiple Dispatch lov080$ $b/java -ea
-XX:+UnlockExperimentalVMOptions -XX:+EnableMethodHandles
-XX:+EnableInvokeDynamic
-Xbootclasspath/p:/System/Library/Frameworks/JavaVM.framework/Ver
Ignore previous code. Typo in code.
Sorry,
--
-- Howard.
___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
In the following code:
public class Price extends CostCalculator {
/* Written by PEC! */ static {
final MethodHandles.Lookup l = MethodHandles.lookup();
MethodHandle mh;
mh = l.findSpecial( Price.class, "cost", MethodType.methodType(
double.class, Price.class, Book.class ), Price.cla
Hi,
I am seeing a change in behavior which I think might be a regression
from build 17.0-b10 to build 18.0-b04-fastdebug. I am using Stephen
Bannasch builds on Mac OS 10.6. The working version of my code with
17.0-b10 to build gives:
wizziewol-ln:Invoke Dynamic Multiple Dispatch lov080$ $a/java -e
This is probably my mistake, but I thought it worth checking anyway!
I am playing around with multiple dispatch in the MLVM, in particular.
public class Cost {
/* Written by PEC! */ static {
final MethodHandle bootstrap = MethodHandles.lookup().findStatic(
CostCalculatorDispatcher.class,
39 matches
Mail list logo
