[Java] Function Binding Redux (long post)

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
17 messages Options
Reply | Threaded
Open this post in threaded view
|

[Java] Function Binding Redux (long post)

John Moeller
Okay.  So I've been spending the last few weeks attempting to figure out
how one would use a "natural" syntax to make a function call in the Java
Langbinding, that is, if you have a Langbinding class "X" and a function
"f" defined as a member, how can you write code such as this:

   X x = new X(...);
   ...
   SomeClass sc = x.f(y, z, 42);

The short answer seems to be "not easily."  At the very least, at the
center of any solution needs to be some kind of function dispatcher on
the Java side that will take in the arguments, pass them to the
Langbinding module, and get the return.  Whether it's as simple as:

   public <ReturnValue> ReturnValue call(Object ... args) { ... }

or something involving more encapsulation, something akin to this needs
to dispatch the function call.

So here's the solutions so far:

1.  Use the function dispatcher directly.

This is ok, but not great, and it's certainly a step away from natural.
  It's at least not entirely procedural, because you can define a
wrapper object and make a call on it:

   import boost.langbinding.Instance;
   ...
   Instance x = new Instance("X", arg1, arg2, arg3);
   x.call("f", arg4, arg5);

2a. Generate a Java source file where the methods wrap the function
dispatcher.

Not entirely appealing, because it's a build-time solution, not a
runtime solution.  But it would enable the use of "natural" syntax very
easily.

2b. Generate the same, except directly in bytecode, and put the result
in a class file.

Same advantages as (2a), except without the compile time, but the
drawback that we'd have to maintain bytecode generation (probably not a
big deal, though).

3.  Do the same as (2b), but load the class at runtime with a special
class loader.  This is (from what I understand) the crux of Rene's idea,
and the most initially appealing.

I've been trying to think of ways to make this work, but there are some
major compromises:

   1.  Without wrangling class loaders at startup, it's impossible to use
       the class name in source code without it having been loaded first.
       This means that you have to load the class, then use it through
       its Class interface.  This means using reflection, which is an
       entirely procedural API.  It's pretty gross.  If the class can
       implement an interface though, (I'm referring to the Java kind of
       interface), then you could just cast it, because a class can
       implement an interface that's already been loaded by another class
       loader with no problem.

   2.  You could wrangle class loaders at startup, or some major
       milestone in your program's execution.  That is, you could come up
       with a "launcher" that set up the class loader chain, and invoke
       "main" from your main app class.  This would enable you to use
       your generated classes naturally, because the main class would be
       loaded with the special class loader in the loader chain, and all
       of its dependent classes (i.e., the rest of the program) would be
       loaded with the same loader chain.

       Unfortunately, this means that you can't have your app classes
       visible from the launcher's classpath.  You actually have to take
       steps to *prevent* the default loaders from finding your app
       classes.  This is inconvenient, and may simply be impossible for
       some users.  They may not have control over how their classes are
       started.

   3.  Hack the JVM startup so that it uses a different class loader.
       This still has the problem of accessibility, and probably the
       problem of portability, because not all JVMs may implement an app
       class loader override.

I thought of another alternative.  If we're willing to compromise on
natural syntax, we can go one better than compromise (1) above.  I got
this idea from looking at the Java scripting API.  In the scripting API,
you can pass an interface class to your script object, and have it
return an object defined in the script as an instance of the interface.

We could do something like this:

   Instance x = new Instance("X", ctorArg1, ctorArg2);
   Runnable r = x.asInterface(Runnable.class);

   new Thread(r).start();

or even:

   WrappedClass x = new WrappedClass("X");
   Runnable r = x.asInterface(Runnable.class, ctorArg1, ctorArg2);

   new Thread(r).start();

This would presumably throw an exception if there wasn't a function void
run() that could be dispatched to.

It seems that it should be possible to generate a class that implements
an interface on the fly (I think that implemented interfaces are just
markers in the class data anyway).

What do you think?

--

John Moeller
[hidden email]


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Boost-langbinding mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/boost-langbinding
Reply | Threaded
Open this post in threaded view
|

Re: [Java] Function Binding Redux (long post)

David Abrahams

on Fri Jul 20 2007, John Moeller <fishcorn-AT-gmail.com> wrote:

> Okay.  So I've been spending the last few weeks attempting to figure out
> how one would use a "natural" syntax to make a function call in the Java
> Langbinding, that is, if you have a Langbinding class "X" and a function
> "f" defined as a member, how can you write code such as this:
>
>    X x = new X(...);
>    ...
>    SomeClass sc = x.f(y, z, 42);

Is this Java or C++ code?

In the domain of language binding, if you want to be understood, you
have to be constantly vigilant for these ambiguities, especially when
the two languages have similar syntaxes.

I didn't read further in detail, so you might want to revisit the
whole post and look for other instances of this issue.

--
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com

The Astoria Seminar ==> http://www.astoriaseminar.com


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Boost-langbinding mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/boost-langbinding
Reply | Threaded
Open this post in threaded view
|

Re: [Java] Function Binding Redux (long post)

John Moeller
David Abrahams wrote:

> on Fri Jul 20 2007, John Moeller <fishcorn-AT-gmail.com> wrote:
>
>> Okay.  So I've been spending the last few weeks attempting to figure out
>> how one would use a "natural" syntax to make a function call in the Java
>> Langbinding, that is, if you have a Langbinding class "X" and a function
>> "f" defined as a member, how can you write code such as this:
>>
>>    X x = new X(...);
>>    ...
>>    SomeClass sc = x.f(y, z, 42);
>
> Is this Java or C++ code?
>
> In the domain of language binding, if you want to be understood, you
> have to be constantly vigilant for these ambiguities, especially when
> the two languages have similar syntaxes.
>
> I didn't read further in detail, so you might want to revisit the
> whole post and look for other instances of this issue.

Fair enough.  All of the code in the post is Java code.

--

John Moeller
[hidden email]


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Boost-langbinding mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/boost-langbinding
Reply | Threaded
Open this post in threaded view
|

Re: [Java] Function Binding Redux (long post)

David Abrahams
In reply to this post by John Moeller

on Fri Jul 20 2007, John Moeller <fishcorn-AT-gmail.com> wrote:

> 2a. Generate a Java source file where the methods wrap the function
> dispatcher.
>
> Not entirely appealing, because it's a build-time solution, not a
> runtime solution.  

Not necessarily.  If Java can compile and load source files
dynamically (it can, can't it?), I don't see any reason why you can't
generate this source file on demand at runtime.  I guess that's where
the "special class loader" you meantion below would come in.

> But it would enable the use of "natural" syntax very easily.
>
> 2b. Generate the same, except directly in bytecode, and put the result
> in a class file.
>
> Same advantages as (2a), except without the compile time, but the
> drawback that we'd have to maintain bytecode generation (probably not a
> big deal, though).

Agreed, probably not a big deal at all.  I'd be surprised if details
of the function-calling convention ever changed enough to require
maintenance.

> 3.  Do the same as (2b), but load the class at runtime with a
> special class loader.  This is (from what I understand) the crux of
> Rene's idea, and the most initially appealing.
>
> I've been trying to think of ways to make this work, but there are some
> major compromises:
>
>    1.  Without wrangling class loaders at startup,

I don't know what you mean, or anything about what's involved here.
That's not a criticism; I'm just letting you know I'm not even a Java
n00b, much less an Xpert.

>        it's impossible to use the class name in source code without
>        it having been loaded first.  This means that you have to
>        load the class, then use it through its Class interface.
>        This means using reflection, which is an entirely procedural
>        API.  It's pretty gross.  If the class can implement an
>        interface though, (I'm referring to the Java kind of
>        interface), then you could just cast it, because a class can
>        implement an interface that's already been loaded by another
>        class loader with no problem.

I don't see how the "implement an interface" thing helps you very
much.  You'd still need to generate Java code for the interface,
right?

>    2.  You could wrangle class loaders at startup, or some major
>        milestone in your program's execution.  That is, you could come up
>        with a "launcher" that set up the class loader chain, and invoke
>        "main" from your main app class.  This would enable you to use
>        your generated classes naturally, because the main class would be
>        loaded with the special class loader in the loader chain, and all
>        of its dependent classes (i.e., the rest of the program) would be
>        loaded with the same loader chain.

I'm way out of my depth now.

>        Unfortunately, this means that you can't have your app classes
>        visible from the launcher's classpath.  You actually have to take
>        steps to *prevent* the default loaders from finding your app
>        classes.  This is inconvenient, and may simply be impossible for
>        some users.  They may not have control over how their classes are
>        started.
>
>    3.  Hack the JVM startup so that it uses a different class loader.
>        This still has the problem of accessibility, and probably the
>        problem of portability, because not all JVMs may implement an app
>        class loader override.
>
> I thought of another alternative.  If we're willing to compromise on
> natural syntax,

I don't recommend that.

> we can go one better than compromise (1) above.  I got this idea
> from looking at the Java scripting API.  In the scripting API, you
> can pass an interface class to your script object, and have it
> return an object defined in the script as an instance of the
> interface.
>
> We could do something like this:
>
>    Instance x = new Instance("X", ctorArg1, ctorArg2);
>    Runnable r = x.asInterface(Runnable.class);
>
>    new Thread(r).start();
>
> or even:
>
>    WrappedClass x = new WrappedClass("X");
>    Runnable r = x.asInterface(Runnable.class, ctorArg1, ctorArg2);
>
>    new Thread(r).start();

Is this just a compromise on the construction syntax, or something
more/worse?

> This would presumably throw an exception if there wasn't a function void
> run() that could be dispatched to.
>
> It seems that it should be possible to generate a class that
> implements an interface on the fly (I think that implemented
> interfaces are just markers in the class data anyway).
>
> What do you think?

Too ignorant to have much of an opinion; I hope someone with an iota
of Java-fu will have some useful feedback for you.

--
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com

The Astoria Seminar ==> http://www.astoriaseminar.com


-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
_______________________________________________
Boost-langbinding mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/boost-langbinding
Reply | Threaded
Open this post in threaded view
|

Re: [Java] Function Binding Redux (long post)

John Moeller
David Abrahams wrote:

> on Fri Jul 20 2007, John Moeller <fishcorn-AT-gmail.com> wrote:
>
>> 2a. Generate a Java source file where the methods wrap the function
>> dispatcher.
>>
>> Not entirely appealing, because it's a build-time solution, not a
>> runtime solution.  
>
> Not necessarily.  If Java can compile and load source files
> dynamically (it can, can't it?), I don't see any reason why you can't
> generate this source file on demand at runtime.  I guess that's where
> the "special class loader" you meantion below would come in.

It can only load and link classes dynamically.  The source is compiled
to bytecode as a separate build step.

> [snip]
>
> I don't know what you mean, or anything about what's involved here.
> That's not a criticism; I'm just letting you know I'm not even a Java
> n00b, much less an Xpert.

That's fine, you're an expert in plenty else.  :)  Here was where I was
hoping that Rene or his business partner would weigh in (when they had
time, of course).

>>        ...
>>        API.  It's pretty gross.  If the class can implement an
>>        interface though, (I'm referring to the Java kind of
>>        interface), then you could just cast it, because a class can
>>        implement an interface that's already been loaded by another
>>        class loader with no problem.
>
> I don't see how the "implement an interface" thing helps you very
> much.  You'd still need to generate Java code for the interface,
> right?

Right, but not necessarily in the context of the classes that you are
using.  As I'm sure you know, a Java "interface" is essentially just a
pure virtual base class.  Because of that abstraction, you can
polymorphically use a class that you generate that implements the
interface.  It doesn't matter *how* you load the class or define it.

So you can use the interface to help protect yourself from the vagaries
of class loading, implementation, the Reflection API, etc.  That's
mostly what I was getting at.

>> ...
>> I thought of another alternative.  If we're willing to compromise on
>> natural syntax,
>
> I don't recommend that.

Ok, this is where I wanted your (Dave's) input.  That is, I wanted to
know how far I could push the usage model.  Say I had a Langbinding
class definition (C++):

   class_<X>("X") [
     def("isFoo", &X::isFoo),
     def("getBar", &X::getBar)
   ];

In Python, it's straightforward to *use* it naturally, i.e. (and you'll
have to forgive me, I don't speak Python):

   X x;
   if (x.isFoo())
     return x.getBar("stuff");

Whereas in Java, it would require some gymnastics and/or extra
installation (both on the client's part) to get such a thing to compile.
  The alternative is to use a wrapper API or Reflection.

>> [snip]
>>    WrappedClass x = new WrappedClass("X");
>>    Runnable r = x.asInterface(Runnable.class, ctorArg1, ctorArg2);
>>
>>    new Thread(r).start();
>
> Is this just a compromise on the construction syntax, or something
> more/worse?

If you had an interface FooBarable defined as:

   public interface FooBarable {
     public boolean isFoo();
     public Object getBar(String request);
   }

[Note:  I'm assuming here that FooBarable is an interface *not*
generated by Langbinding; that the client creates this interface or uses
another provided by a library because it matches a subset of the method
interface of X, which the client must be familiar with to use X in the
first place.  I'm beginning to suspect that I didn't communicate this
clearly.]

In Java code, you could "inform" the Java backend of Langbinding that X
really did implement FooBarable, and get an X as an instance of the
class.  This would prompt the internals of the Java backend to crank out
a bytecode representation of X that implemented FooBarable:

   Class XClass = WrappedClass.asInterface(FooBarable, "X");
   FooBarable fb = WrappedClass.construct(XClass, ca1, ca2);
   if (fb.isFoo())
     return fb.getBar("stuff");

So, getting to your question, it would be a compromise of the
construction syntax, but probably no more.  Additionally, Java
programmers are generally used to "interface programming."

As for iterator/collection support, I was thinking of offering an
interface that just hotwired the iterators into a Java Collection.  That
way, it could be used with a "foreach" loop in Java.  This could be done
without the aforementioned user gymnastics, as Collection is an
interface provided by the Java API.

However, not all of the binding "goodies" available in Python or Lua are
available in Java.  As an example, overriding field/property access as
you do in Boost.Python would be impossible in a Java binding.  You'd
have to settle for getters/setters.  I was going to bring this issue up
in a different post, though.

--

John Moeller
[hidden email]


-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
_______________________________________________
Boost-langbinding mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/boost-langbinding
Reply | Threaded
Open this post in threaded view
|

Re: [Java] Function Binding Redux (long post)

Rene Rivera-2
John Moeller wrote:

> David Abrahams wrote:
>> on Fri Jul 20 2007, John Moeller <fishcorn-AT-gmail.com> wrote:
>>
>>> 2a. Generate a Java source file where the methods wrap the function
>>> dispatcher.
>>>
>>> Not entirely appealing, because it's a build-time solution, not a
>>> runtime solution.  
>> Not necessarily.  If Java can compile and load source files
>> dynamically (it can, can't it?), I don't see any reason why you can't
>> generate this source file on demand at runtime.  I guess that's where
>> the "special class loader" you meantion below would come in.
>
> It can only load and link classes dynamically.  The source is compiled
> to bytecode as a separate build step.

Although that depends on the Java runtime one is running in. The JDK
runtime comes with the compiler in it so it's possible to "eval" source
code. There are probably numerous limitations though.



--
-- Grafik - Don't Assume Anything
-- Redshift Software, Inc. - http://redshift-software.com
-- rrivera/acm.org - grafik/redshift-software.com
-- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
_______________________________________________
Boost-langbinding mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/boost-langbinding
Reply | Threaded
Open this post in threaded view
|

Re: [Java] Function Binding Redux (long post)

Rene Rivera-2
In reply to this post by John Moeller
John Moeller wrote:

> 2b. Generate the same, except directly in bytecode, and put the result
> in a class file.
>
> Same advantages as (2a), except without the compile time, but the
> drawback that we'd have to maintain bytecode generation (probably not a
> big deal, though).

There are bytecode generation libraries out there that would make this
even less of a big deal.

> 3.  Do the same as (2b), but load the class at runtime with a special
> class loader.  This is (from what I understand) the crux of Rene's idea,
> and the most initially appealing.

Yes, that's what I meant. But using a class loader is only an idea. More
briefly I would want to create the Java "code" and have it bound to the
native code when the library is loaded. It would work something like:

When the library is loaded (System.loadLibrary) during the JNI_OnLoad
<http://tinyurl.com/2dmsh8>:

   * It creates bytecode for the classes in the binding and loads it
into the JVM with DefineClass <http://tinyurl.com/2bjzmz>.
   * It binds the Java native methods to the C++ functions with
RegisterNatives <http://tinyurl.com/2bjzmz>.

That allows for the distribution of only the shared library (although it
might be possible to work something equivalent for the embedded use
case). All users need to do is call System.loadLibrary. What I don't
know is how the Java compiler could be made to work without actual
*.class files.

> I've been trying to think of ways to make this work, but there are some
> major compromises:

Hm, I think your three points aren't relevant to what I just mentioned
above so I'm refraining from comment until proven otherwise ;-)



--
-- Grafik - Don't Assume Anything
-- Redshift Software, Inc. - http://redshift-software.com
-- rrivera/acm.org - grafik/redshift-software.com
-- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
_______________________________________________
Boost-langbinding mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/boost-langbinding
Reply | Threaded
Open this post in threaded view
|

Re: [Java] Function Binding Redux (long post)

Rene Rivera-2
Rene Rivera wrote:
> What I don't
> know is how the Java compiler could be made to work without actual
> *.class files.

Thinking a bit more about this... It should be easy to create a test for
this. Just:

* Create a Java source file which declares a native class.
* Compile that to the *.class equivalent.
* Write a library that implements the basic algo I mentioned, but is
hardwired to:
     * Load in the contents of the *.class file.
     * Bind a method from the Java class to an arbitrary C++ function.
* Create a second Java class that subclasses, or otherwise uses, the
library class and that does the System.loadLibrary before defining the
class.
* Try and compile the new class.


--
-- Grafik - Don't Assume Anything
-- Redshift Software, Inc. - http://redshift-software.com
-- rrivera/acm.org - grafik/redshift-software.com
-- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
_______________________________________________
Boost-langbinding mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/boost-langbinding
Reply | Threaded
Open this post in threaded view
|

Re: [Java] Function Binding Redux (long post)

John Moeller
In reply to this post by Rene Rivera-2
Rene Rivera wrote:

> John Moeller wrote:
>
>> 2b. Generate the same, except directly in bytecode, and put the result
>> in a class file.
>>
>> Same advantages as (2a), except without the compile time, but the
>> drawback that we'd have to maintain bytecode generation (probably not a
>> big deal, though).
>
> There are bytecode generation libraries out there that would make this
> even less of a big deal.

Right, like BCEL and such.  I wanted to feel out your thoughts on such a
dependency.  Regardless, I think we all agree now that creating bytecode
is one of the least of our hurdles here.

>> 3.  Do the same as (2b), but load the class at runtime with a special
>> class loader.  This is (from what I understand) the crux of Rene's idea,
>> and the most initially appealing.
>
> Yes, that's what I meant. But using a class loader is only an idea. More
> briefly I would want to create the Java "code" and have it bound to the
> native code when the library is loaded. It would work something like:

That's essentially the process that I'm referring to.

By the way, just to avoid confusion, let me define "natural usage" as:
in source, referring to a class by name and calling its methods or
accessing its fields with regular language syntax, as opposed to using a
discovery API or other indirect semantics to call methods or access fields.

> When the library is loaded (System.loadLibrary) during the JNI_OnLoad
> <http://tinyurl.com/2dmsh8>:
>
>    * It creates bytecode for the classes in the binding and loads it
> into the JVM with DefineClass <http://tinyurl.com/2bjzmz>.

This isn't really all that different from explicitly loading a class in
Java code, and results in the same problems with natural usage.

That is, you must get a generated class defined before the classes that
use it are loaded.  This basically means that if you want to be
*assured* that no NoClassDefFoundError will be thrown, you must get the
generated class defined *before* the main app class is even loaded.
That means a launcher of some sort.

Loading a generated class in the entry class' static initializer won't
even work, because a JVM is allowed to load any dependent classes for
the class that it is currently loading, before it runs any code in that
class.  That means (potentially) that it could attempt to load the
entire retinue of program classes before it runs the static initializer
of the entry point class.

>    * It binds the Java native methods to the C++ functions with
> RegisterNatives <http://tinyurl.com/2bjzmz>.
>
> That allows for the distribution of only the shared library (although it
> might be possible to work something equivalent for the embedded use
> case). All users need to do is call System.loadLibrary.

Sure.  I'd like to see any glue code be slim anyway.  However, I'd like
to point out that if there is any bytecode that can be factored out, it
may make more sense to have it in Java classes, but I don't know at this
point.

I don't see that distributing a jar file along with the library would be
all that onerous, but we could aim to avoid it, if you feel it would
better suit clients.  Another possibility is to let the client package
the utility classes within their own jar files.

> What I don't
> know is how the Java compiler could be made to work without actual
> *.class files.

You can't (at least not with the Sun Java compiler).  You would need
stub classes in lieu of the generated classes.  Which makes the
interface idea more appealing, at least to me.

>> I've been trying to think of ways to make this work, but there are some
>> major compromises:
>
> Hm, I think your three points aren't relevant to what I just mentioned
> above so I'm refraining from comment until proven otherwise ;-)

Ok, I'll try to defend their relevance:

1.  I tried an experiment whereby I explicitly loaded class A in the
static initializer of class B, and used class A naturally in class B's
main method.  The main method threw a NoClassDefFoundError, presumably
because it tried to load class A to ensure that any bytecode in class B
could be run.

The alternative is to use the class through the Reflection API.  That
is, define the class, find its main method, and invoke it, which is all
pretty gross, and you have to catch a lot of kinds of exceptions to do it.

As I tried to explain above, you won't avoid that with an explicit call
to System.LoadLibrary, unless you call it from a launcher class that
also explicitly loads the main class.

Don't get me wrong; I would, in all honesty, love to be wrong on this
one.  It would make things a lot easier.  But I suspect that we won't
get the easy way out.

2.  I'll concede this point partially, because you're talking about
using the native DefineClass, which lets you set the loader to the app
class loader, so you can rid yourself of classpath restrictions that
way.  You would still need a launcher class to get around point (1), though.

3.  Not relevant to what you talked about, but that only makes me happy.
  I'd like to avoid hacks where we can.

Anyway, that's why I suggested the interface approach.  It's not foreign
to Java programmers, and it would ease a lot of these problems.

--

John Moeller
[hidden email]


-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
_______________________________________________
Boost-langbinding mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/boost-langbinding
Reply | Threaded
Open this post in threaded view
|

Re: [Java] Function Binding Redux (long post)

John Moeller
In reply to this post by Rene Rivera-2
Rene Rivera wrote:

> Rene Rivera wrote:
>> What I don't
>> know is how the Java compiler could be made to work without actual
>> *.class files.
>
> Thinking a bit more about this... It should be easy to create a test for
> this. Just:
>
> * Create a Java source file which declares a native class.
> * Compile that to the *.class equivalent.
> * Write a library that implements the basic algo I mentioned, but is
> hardwired to:
>      * Load in the contents of the *.class file.
>      * Bind a method from the Java class to an arbitrary C++ function.
> * Create a second Java class that subclasses, or otherwise uses, the
> library class and that does the System.loadLibrary before defining the
> class.
> * Try and compile the new class.

I think I see where you're going, but it won't work.  At the point where
you "subclass or otherwise use" and then compile, the compiler will
error out.  If the compiler can't find the dependent class, the target
class will fail to compile.  I tried this.

Additionally, as I explain in more detail in my other response, you
can't, in class D, try to load class C explicitly and then use it
implicitly.  In the process of loading class D, the JVM can try to load
class C and any other class that D depends on, before it even runs one
speck of code from class D.  Unless, that is, you use class C
explicitly, through Reflection.  Which is a gross way to use a class.

--

John Moeller
[hidden email]


-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
_______________________________________________
Boost-langbinding mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/boost-langbinding
Reply | Threaded
Open this post in threaded view
|

Re: [Java] Function Binding Redux (long post)

Rene Rivera-2
John Moeller wrote:
> I think I see where you're going, but it won't work.  At the point where
> you "subclass or otherwise use" and then compile, the compiler will
> error out.  If the compiler can't find the dependent class, the target
> class will fail to compile.  I tried this.

Yea, I see that now that I've spent today trying out the test I
mentioned. But it turns out it's worse...

> Additionally, as I explain in more detail in my other response, you
> can't, in class D, try to load class C explicitly and then use it
> implicitly.  In the process of loading class D, the JVM can try to load
> class C and any other class that D depends on, before it even runs one
> speck of code from class D.

So on the suggestion from JW (John Welch), I tried an experiment. He
suggested a rather devious possible solution; Create an empty stub
*.java and corresponding *.class that loads the native class:

====java
package boost;

public class A
{
     static {
         java.lang.System.out.println("stub/boost/A/static_init...");
         java.lang.System.loadLibrary("boost_A.dll");
     }
}
====

And as part of the loadLibrary() redefine the same class to the
native+JNI version (see attached test code). Hence when one uses the A
class, it can be loaded, but one is freed from having to declare all the
redundant Java members. But, and it's a big one, it seems the Java
compiler *does not load* a class in order to use it during compilation.
Rather it seems to read the .class file directly. Which seems to me a
rather serious case of false advertising from Sun.

> Unless, that is, you use class C
> explicitly, through Reflection.  Which is a gross way to use a class.

Yes, that's fairly gross. Given your experiments, and mine, this only
leaves your suggestion of interfaces or of a launcher that puts in a
custom class loader.


--
-- Grafik - Don't Assume Anything
-- Redshift Software, Inc. - http://redshift-software.com
-- rrivera/acm.org - grafik/redshift-software.com
-- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
_______________________________________________
Boost-langbinding mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/boost-langbinding
Reply | Threaded
Open this post in threaded view
|

Re: [Java] Function Binding Redux (long post)

John Moeller
Rene Rivera wrote:

> So on the suggestion from JW (John Welch), I tried an experiment. He
> suggested a rather devious possible solution; Create an empty stub
> *.java and corresponding *.class that loads the native class:
>
> ====java
> package boost;
>
> public class A
> {
>      static {
>          java.lang.System.out.println("stub/boost/A/static_init...");
>          java.lang.System.loadLibrary("boost_A.dll");
>      }
> }
> ====
>
> And as part of the loadLibrary() redefine the same class to the
> native+JNI version (see attached test code).

Is the part between "====" what you are referring to?  I didn't get any
attachments with your message.

> Hence when one uses the A
> class, it can be loaded, but one is freed from having to declare all the
> redundant Java members.

This would be cool.  Although, there's something scratching at the back
of my head about this one.  Something about defining a class twice, or
not being able to undefine a class, or something else.

> But, and it's a big one, it seems the Java
> compiler *does not load* a class in order to use it during compilation.
> Rather it seems to read the .class file directly. Which seems to me a
> rather serious case of false advertising from Sun.

Blech.  Yeah, that would be the case, wouldn't it?  There must be some
sensible way to stub a class; there are J2EE developers who do it all
the time when they use AOP toolkits that use link-time weaving.

>> Unless, that is, you use class C
>> explicitly, through Reflection.  Which is a gross way to use a class.
>
> Yes, that's fairly gross. Given your experiments, and mine, this only
> leaves your suggestion of interfaces or of a launcher that puts in a
> custom class loader.

Darn.  I was really hoping that you and JW would prove me wrong.  :(

Personally, I'm in favor of the interface approach; I think that despite
the somewhat awkwardness in object construction, it offers more
flexibility.  There's always the possibility of offering both
approaches, though.

I'll get started on some basic glue code; I still need to study up on
bytecode a little.  I could probably throw something together in Java
that uses BCEL, though, until we can migrate some of it to native code.

--

John Moeller
[hidden email]


-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
_______________________________________________
Boost-langbinding mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/boost-langbinding
Reply | Threaded
Open this post in threaded view
|

Re: [Java] Function Binding Redux (long post)

Rene Rivera-2
John Moeller wrote:

> Rene Rivera wrote:
>> So on the suggestion from JW (John Welch), I tried an experiment. He
>> suggested a rather devious possible solution; Create an empty stub
>> *.java and corresponding *.class that loads the native class:
>>
>> ====java
>> package boost;
>>
>> public class A
>> {
>>      static {
>>          java.lang.System.out.println("stub/boost/A/static_init...");
>>          java.lang.System.loadLibrary("boost_A.dll");
>>      }
>> }
>> ====
>>
>> And as part of the loadLibrary() redefine the same class to the
>> native+JNI version (see attached test code).
>
> Is the part between "====" what you are referring to?  I didn't get any
> attachments with your message.

Grr... Not only did I forget the attachment. When I put it in the SF
mailman program cheerfully informs me they are blocking attachments.



--
-- Grafik - Don't Assume Anything
-- Redshift Software, Inc. - http://redshift-software.com
-- rrivera/acm.org - grafik/redshift-software.com
-- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
_______________________________________________
Boost-langbinding mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/boost-langbinding
Reply | Threaded
Open this post in threaded view
|

Re: [Java] Function Binding Redux (long post)

Rene Rivera-2
Rene Rivera wrote:
> Grr... Not only did I forget the attachment. When I put it in the SF
> mailman program cheerfully informs me they are blocking attachments.

I checked it into SVN, under
sandbox/langbinding/libs/langbinding/test/java_jni_test.


--
-- Grafik - Don't Assume Anything
-- Redshift Software, Inc. - http://redshift-software.com
-- rrivera/acm.org - grafik/redshift-software.com
-- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
_______________________________________________
Boost-langbinding mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/boost-langbinding
Reply | Threaded
Open this post in threaded view
|

Re: [Java] Function Binding Redux (long post)

David Abrahams
In reply to this post by Rene Rivera-2

on Wed Jul 25 2007, Rene Rivera <grafikrobot-AT-gmail.com> wrote:

> Grr... Not only did I forget the attachment. When I put it in the SF
> mailman program cheerfully informs me they are blocking attachments.

That's odd; we have content filtering turned *off* on this list.

--
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com

The Astoria Seminar ==> http://www.astoriaseminar.com


-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
_______________________________________________
Boost-langbinding mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/boost-langbinding
Reply | Threaded
Open this post in threaded view
|

Re: [Java] Function Binding Redux (long post)

Rene Rivera-2
David Abrahams wrote:
> on Wed Jul 25 2007, Rene Rivera <grafikrobot-AT-gmail.com> wrote:
>
>> Grr... Not only did I forget the attachment. When I put it in the SF
>> mailman program cheerfully informs me they are blocking attachments.
>
> That's odd; we have content filtering turned *off* on this list.

I don't think it's an issue with the list settings. But a global SF
policy. Here's the explanation from SF as included by my mail server:

[<02>] The reason of the delivery failure was:

550-"For the time being, we are blocking all mail with the .zip extension.
550-If this this is a problem, please open a Support Request on the SF.net
550 webite."


--
-- Grafik - Don't Assume Anything
-- Redshift Software, Inc. - http://redshift-software.com
-- rrivera/acm.org - grafik/redshift-software.com
-- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
_______________________________________________
Boost-langbinding mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/boost-langbinding
Reply | Threaded
Open this post in threaded view
|

Re: [Java] Function Binding Redux (long post)

David Abrahams

on Thu Jul 26 2007, Rene Rivera <grafikrobot-AT-gmail.com> wrote:

> David Abrahams wrote:
>> on Wed Jul 25 2007, Rene Rivera <grafikrobot-AT-gmail.com> wrote:
>>
>>> Grr... Not only did I forget the attachment. When I put it in the SF
>>> mailman program cheerfully informs me they are blocking attachments.
>>
>> That's odd; we have content filtering turned *off* on this list.
>
> I don't think it's an issue with the list settings. But a global SF
> policy. Here's the explanation from SF as included by my mail server:
>
> [<02>] The reason of the delivery failure was:
>
> 550-"For the time being, we are blocking all mail with the .zip extension.
> 550-If this this is a problem, please open a Support Request on the SF.net
> 550 webite."

Oh.  Then you could just use a .tar.gz, or simply mangle the
extension.

--
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com

The Astoria Seminar ==> http://www.astoriaseminar.com


-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
_______________________________________________
Boost-langbinding mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/boost-langbinding