Smalltalk › Redline Smalltalk

Invoking Java

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

4 messages Options

vivo

Invoking Java

Hi!

What are your thoughts on invoking Java methods with multiple
parameters?

Imagine an "image" object that has a Java method "overlay", which
allows to add another image
on top of the first at a certain position:

overlay(otherImage, x, y)

In Smalltalk this might be

overlayWithImage: atX: atY:

But when I look at the vast amount of existing libraries, how do I
invoke all the methods?
I could imagine:

1) create a Java Source Parser that generates some kind of Smalltalk
Wrappers
If the source code is not available, it is not possible to get at
the names of the parameters,
and to use a naming heuristic. But still the "translation" of the
above Java method into
"smalltalkish" messages could not be done completely automatic.
If you use the generated code as a starting point to be finetuned
manually you need
But whenever a new version of that library is published you have a
problem.
You need to keep your changes as a sort of "patch" to be applied
again after
the wrappers have again been generated.
Instead of full Wrappers you could just generate a mapping from
Smalltalk names to
Java methods that have to be interpreted at runtime.
2) invoke Java methods, with more than one parameter with an array of
objects

overlay: #(otherImage, x, y)

if there is more than one method with the same number of
parameters, it depends on some
type conversion rules at runtime to determine the correct method.

James Ladd

Re: Invoking Java

I have thought long about the integration with Java.

Just wrapping Java objects would work but it would not be idiomatic Smalltalk and that for me is a big
problem. While it would be quick and easy for users the result would not be what a Smalltalker expects.

The approach available in the branch of Redline (pushed to head very soon now) enables you to
emit any bytecode the JVM supports, enabling you to call any Java method.

This is low level and done this way to encourage users of Java objects to create a very Smalltalk like
interface.

These are the currently supported primitives/pragmas:

    <insn: jvmOpcode>
    <ldcInsn: stringConstant >
    <varInsn: jvmOpcode , DIGITS >
    <methodInsn: jvmOpcode , stringConstant , stringConstant , stringConstant >
    <typeInsn: jvmOpcode , stringConstant >
    <iincInsn: DIGITS , DIGITS >
    <intInsn: jvmOpcode , DIGITS >
    <fieldInsn: jvmOpcode , stringConstant , stringConstant , stringConstant >
    <loadJavaValue>
    <storeJavaValue>

Where:

jvmOpcode is on of the opcodes supported by ASM - essentially and UPPERCASE equivalent of the Asm Web documented opcode.
eg: <insn: POP>

stringConstant is a Smalltalk String. Eg: 'string'
(Including single quote)

They map 1 to 1 with the ObjectWeb ASM methods in MethodVisitor http://asm.ow2.org/asm33/javadoc/user/org/objectweb/asm/MethodVisitor.html
with the exception of the last two which get/set a java value into a Smalltalk object so it can be passes around / stored.

There will be a tutorial on this very soon.

On Fri, Aug 26, 2011 at 11:29 PM, vivo <[hidden email]> wrote:

Hi!

What are your thoughts on invoking Java methods with multiple
parameters?

Imagine an "image" object that has a Java method "overlay", which
allows to add another image
on top of the first at a certain position:

overlay(otherImage, x, y)

In Smalltalk this might be

overlayWithImage: atX: atY:

But when I look at the vast amount of existing libraries, how do I
invoke all the methods?
I could imagine:

1) create a Java Source Parser that generates some kind of Smalltalk
Wrappers
If the source code is not available, it is not possible to get at
the names of the parameters,
and to use a naming heuristic. But still the "translation" of the
above Java method into
"smalltalkish" messages could not be done completely automatic.
If you use the generated code as a starting point to be finetuned
manually you need
But whenever a new version of that library is published you have a
problem.
You need to keep your changes as a sort of "patch" to be applied
again after
the wrappers have again been generated.
Instead of full Wrappers you could just generate a mapping from
Smalltalk names to
Java methods that have to be interpreted at runtime.
2) invoke Java methods, with more than one parameter with an array of
objects

overlay: #(otherImage, x, y)

if there is more than one method with the same number of
parameters, it depends on some
type conversion rules at runtime to determine the correct method.

vivo

Re: Invoking Java

So if I want to use a Java image library from Redline like this:

image := Image new: 'file.png'
image overlayWithImage: (Image new: 'file2.jpg') atX: 10 atY: 20

I would need to create a Smalltalk 'Image' class that emits the
necessary byte code for each and every method:

new:
overlayWithImage:atX:atY:
...

That sounds like too much overhead for me. One of the most important
reasons to use a language on the JVM is -- at least for me -- the huge
amount of existing libraries.

I will have a look at your branch when it is pushed and try to create
a generalized invocation mechanism.

Especially difficult might be inheriting from Java classes,
implementing interfaces and vice versa

On Aug 27, 10:16 am, James Ladd <[hidden email]> wrote:

> I have thought long about the integration with Java.
>
> Just wrapping Java objects would work but it would not be idiomatic
> Smalltalk and that for me is a big
> problem. While it would be quick and easy for users the result would not be
> what a Smalltalker expects.
>
> The approach available in the branch of Redline (pushed to head very soon
> now) enables you to
> emit any bytecode the JVM supports, enabling you to call any Java method.
>
> This is low level and done this way to encourage users of Java objects to
> create a very Smalltalk like
> interface.
>
> These are the currently supported primitives/pragmas:
>
> <insn: jvmOpcode>
> <ldcInsn: stringConstant >
> <varInsn: jvmOpcode , DIGITS >
> <methodInsn: jvmOpcode , stringConstant , stringConstant ,
> stringConstant >
> <typeInsn: jvmOpcode , stringConstant >
> <iincInsn: DIGITS , DIGITS >
> <intInsn: jvmOpcode , DIGITS >
> <fieldInsn: jvmOpcode , stringConstant , stringConstant , stringConstant
>
> <loadJavaValue>
> <storeJavaValue>
>
> Where:
>
> jvmOpcode is on of the opcodes supported by ASM - essentially and UPPERCASE
> equivalent of the Asm Web documented opcode.
> eg: <insn: POP>
>
> stringConstant is a Smalltalk String. Eg: 'string'
> (Including single quote)
>
> They map 1 to 1 with the ObjectWeb ASM methods in MethodVisitorhttp://asm.ow2.org/asm33/javadoc/user/org/objectweb/asm/MethodVisitor...
> with the exception of the last two which get/set a java value into a
> Smalltalk object so it can be passes around / stored.
>
> There will be a tutorial on this very soon.
>
>
>
> On Fri, Aug 26, 2011 at 11:29 PM, vivo <[hidden email]> wrote:
> > Hi!
>
> > What are your thoughts on invoking Java methods with multiple
> > parameters?
>
> > Imagine an "image" object that has a Java method "overlay", which
> > allows to add another image
> > on top of the first at a certain position:
>
> > overlay(otherImage, x, y)
>
> > In Smalltalk this might be
>
> > overlayWithImage: atX: atY:
>
> > But when I look at the vast amount of existing libraries, how do I
> > invoke all the methods?
> > I could imagine:
>
> > 1) create a Java Source Parser that generates some kind of Smalltalk
> > Wrappers
> > If the source code is not available, it is not possible to get at
> > the names of the parameters,
> > and to use a naming heuristic. But still the "translation" of the
> > above Java method into
> > "smalltalkish" messages could not be done completely automatic.
> > If you use the generated code as a starting point to be finetuned
> > manually you need
> > But whenever a new version of that library is published you have a
> > problem.
> > You need to keep your changes as a sort of "patch" to be applied
> > again after
> > the wrappers have again been generated.
> > Instead of full Wrappers you could just generate a mapping from
> > Smalltalk names to
> > Java methods that have to be interpreted at runtime.
> > 2) invoke Java methods, with more than one parameter with an array of
> > objects
>
> > overlay: #(otherImage, x, y)
>
> > if there is more than one method with the same number of
> > parameters, it depends on some
> > type conversion rules at runtime to determine the correct method.

SeanTAllen

Re: Invoking Java

Most likely, this is going to be a step towards something else.

The general approach James and I have taken is make it work, then make it nice.

We think that bytecode emission is the most flexible way to do interop, however,

it isnt going to be for most.

Think of bytecode emission as being like modifying a vm to add a primitive.

We are working through what the equivalent FFI would be.

The analogy isnt great but its decent. Current thought being kicked around is generation

of bytecode for you via a tool that could then be tweaked.

Why bytecode in general? We think its the best way to be able to interoperate with any language

on the jvm so at the lowest level, that is what we want to be doing.

We'd welcome thoughts on how to give that a more 'human' interface.

From my perspective, generating static wrappers that can be tweaked is better than creating

an on the fly proxy as it allows for more tweaking etc and would fit fairly well with some other

stuff we have going on for being able to still support multiple versions of an api as library X

changes over time.

I could see auto proxy generation being handy in an exploratory scenario much like rails' db scaffolding is

great during exploration.

-Sean-

On Sat, Aug 27, 2011 at 8:24 AM, vivo <[hidden email]> wrote:

So if I want to use a Java image library from Redline like this:

image := Image new: 'file.png'
image overlayWithImage: (Image new: 'file2.jpg') atX: 10 atY: 20

I would need to create a Smalltalk 'Image' class that emits the
necessary byte code for each and every method:

new:
overlayWithImage:atX:atY:
...

That sounds like too much overhead for me. One of the most important
reasons to use a language on the JVM is -- at least for me -- the huge
amount of existing libraries.

I will have a look at your branch when it is pushed and try to create
a generalized invocation mechanism.

Especially difficult might be inheriting from Java classes,
implementing interfaces and vice versa

On Aug 27, 10:16 am, James Ladd <[hidden email]> wrote:
> I have thought long about the integration with Java.
>
> Just wrapping Java objects would work but it would not be idiomatic
> Smalltalk and that for me is a big
> problem. While it would be quick and easy for users the result would not be
> what a Smalltalker expects.
>
> The approach available in the branch of Redline (pushed to head very soon
> now) enables you to
> emit any bytecode the JVM supports, enabling you to call any Java method.
>
> This is low level and done this way to encourage users of Java objects to
> create a very Smalltalk like
> interface.
>
> These are the currently supported primitives/pragmas:
>
> <insn: jvmOpcode>
> <ldcInsn: stringConstant >
> <varInsn: jvmOpcode , DIGITS >
> <methodInsn: jvmOpcode , stringConstant , stringConstant ,
> stringConstant >
> <typeInsn: jvmOpcode , stringConstant >
> <iincInsn: DIGITS , DIGITS >
> <intInsn: jvmOpcode , DIGITS >
> <fieldInsn: jvmOpcode , stringConstant , stringConstant , stringConstant
>
> <loadJavaValue>
> <storeJavaValue>
>
> Where:
>
> jvmOpcode is on of the opcodes supported by ASM - essentially and UPPERCASE
> equivalent of the Asm Web documented opcode.
> eg: <insn: POP>
>
> stringConstant is a Smalltalk String. Eg: 'string'
> (Including single quote)
>

> They map 1 to 1 with the ObjectWeb ASM methods in MethodVisitorhttp://asm.ow2.org/asm33/javadoc/user/org/objectweb/asm/MethodVisitor...

> with the exception of the last two which get/set a java value into a
> Smalltalk object so it can be passes around / stored.
>
> There will be a tutorial on this very soon.
>
>
>

> On Fri, Aug 26, 2011 at 11:29 PM, vivo <[hidden email]> wrote:
> > Hi!
>
> > What are your thoughts on invoking Java methods with multiple
> > parameters?
>
> > Imagine an "image" object that has a Java method "overlay", which
> > allows to add another image
> > on top of the first at a certain position:
>
> > overlay(otherImage, x, y)
>
> > In Smalltalk this might be
>
> > overlayWithImage: atX: atY:
>
> > But when I look at the vast amount of existing libraries, how do I
> > invoke all the methods?
> > I could imagine:
>
> > 1) create a Java Source Parser that generates some kind of Smalltalk
> > Wrappers
> > If the source code is not available, it is not possible to get at
> > the names of the parameters,
> > and to use a naming heuristic. But still the "translation" of the
> > above Java method into
> > "smalltalkish" messages could not be done completely automatic.
> > If you use the generated code as a starting point to be finetuned
> > manually you need
> > But whenever a new version of that library is published you have a
> > problem.
> > You need to keep your changes as a sort of "patch" to be applied
> > again after
> > the wrappers have again been generated.
> > Instead of full Wrappers you could just generate a mapping from
> > Smalltalk names to
> > Java methods that have to be interpreted at runtime.
> > 2) invoke Java methods, with more than one parameter with an array of
> > objects
>
> > overlay: #(otherImage, x, y)
>
> > if there is more than one method with the same number of
> > parameters, it depends on some
> > type conversion rules at runtime to determine the correct method.