Forth in Java

[ruv]

Could you suggest a Forth implementation that can be embedded in a Java application?
So actually it is not obligated that it's in Java, it can be in any language that compiles in JVM.

Also, it shall have some FFI to Java methods, and be able to catch exceptions in Java methods.

[SirWumpus]

What about a C implementation with JNI wrappers?

[ruv]

so only some subset is needed.

No, Java threading is just an accidental example from 8th.

What does the fusion of Forth and Java bring that can't be done just in Java alone?

I think, it's a question of convenience, not possibility.

The fusion of Forth and Java can be implemented in two variants:

1. Forth is integrated into a Java application (Java calls Forth). It can bring to the application (I suppose):

   • an interactive terminal (REPL) with introspection/debugging facilities,
   • testing, configuring, scripting (without recompilation of the application).

2. Access to Java from a Forth system (Forth calls Java). This brings capabilities to:

   • test/introspect/debug Java components (classes),
     • partially, what JShell now provides.
   • use libraries/components from the huge Java ecosystem in a Forth program,
   • create light wrappers/scripts over a Java component just in Forth (without creating a Java application for that),
     • as an example, once I needed a simple wrapper over Apache™ FOP component.
     • (I consider Forth far simpler than Java)

[ruv]

Your original ask for something like:

S" hello terra" System.out.println 
123.45 System.out.println

I guess, it should not work in the second case. Forth does not know whether it's a string length or just a number. So, only a string should be passed to this method.

By the way, if there is only one method of a given name, it can be resolved without providing signature, at least via enumeration of all the methods. Example: ReflectionMachine.java (in Forth-2020-Asteroids-Demo)

one supplies the signature at least might help select which variant, but that has issues too I think as signatures get long.

S" hello terra" S" (Ljava.lang.String)V" System.out.println 

If it's needed to specify a signature in some case, it's a good thing to be able to specify it as an immediate argument, e.g.:

System.out.println((Ljava.lang.String)V)

— for better performance of compiled code (and simpler implementation of that).

Concerning long signatures — if they used several times, it can be wrapped into a simple definitions as:

: println ( sd.text -- ) System.out.println((Ljava.lang.String)V) ;

[SirWumpus]

By the way, if there is only one method of a given name, it can be resolved without providing signature.

From what I've read and used so far of the JNI this past weekend, get/set fields, and method calls, even if there is only one by that name still require a signature. Its a two step process: first lookup a jfieldID or jmethodID based on the class, then use that ID to interact with the field or method of an object.

I've not looked at 8th at all, but I suppose to handle overloading, one would prepare some helper words;

: sysout-println ( caddr u -- )
  S" (Ljava.lang.String)V" S" System.out.println" jcall
;
: sysout-double-println ( float -- )
  S" (D)V" S" System.out.println" jcall
;
: some-java-obj ( xn ... xi n this -- x )
  >R set-jarray >R S" ([I)J" S" some.java.Woot.method" jcall
;

The above is just ideas off the top of my head.

Just noticed your edit about wrappers; had similar idea in mind. Maybe not as nice as originally envisioned, but certainly workable -- put all the wrappers in files and include them, similar to Java import java.lang.System.*. I'll futz with it some more.

[ruv]

From what I've read and used so far of the JNI this past weekend, get/set fields, and method calls, even if there is only one by that name still require a signature.

Yes. But then what can prevent us to use the Reflection API to enumerate all the methods of a class?

Namely, we can use CallObjectMethod to call java.lang.Object.getClass, java.lang.Class.getMethods, java.lang.reflect.Method.getGenericParameterTypes, etc, and use FromReflectedMethod to get the jmethodID for a method.

See also an example on Stackoverflow.

[SirWumpus]

@ruv So I've finally implemented an initial set of words for Forth to Java support in Post4, which are pretty much JNI wrappers. I still haven't seen how reflection could help just yet.

The documentation is light for the moment (as it might change), but there are some examples of how these might be used, eg. java.lang.System.p4 and java.lang.Thread.p4.

I did look at the three "8th" words for Android Java support (which seems limited) and suspect they hide (punt) a lot of the object reference management, no field get/set, box/unbox strings or arrays, and more.

[MitchBradley]

My CForth could once run on a Java-based phone. It worked by transliterating C to Java with some preprocessor trickery. To make that work, I had to change all the pointer arithmetic to array references. The java code is still there, but has not been maintained in years so I would be really surprised if it still works without some tweaking.

[ruv]

The most difficult part (which is absent as I can see), is an FFI. It should use the Java reflection to resolve an actual method (from a name) and its parameters, and properly pass (or marshal) them from the data stack to the method, and pass the result back to the data stack.

[MitchBradley]

The base CForth has a reasonable facility for calling C functions. You have to specify the parameters, and it depends on the fact that C essentially passes everything on the call stack as a glorified int. Doing an automated FFI for Java would be possible, I suppose, but it probably would be a lot of work, as you surmise.

My old company FirmWorks did a Java implementation of Open Firmware for Sun at one point, but I can't find the code.

[ruv]

I just think that this work (FFI for Java) was already done a number of times, and there is no need to do it again -)

[jwoehr]

You might be able to fiddle with my ancient FIJI ForthIsh Java Interpreter <https://sourceforge.net/projects/fiji/> which is an object oriented Forth in Java that can call into Java.

[ruv]

@jwoehr, many thanks! I even see an updated fork: https://github.com/bluekelp/fiji-core (2018)
At the first glance it looks like what I asked.

[andrewtholt]

Others have probably mention previous forth in java implementations, it can't hurt Somewhat old now but it may be of interest: https://fiji.sourceforge.net/ I vaguely remember calling methods in java classes from forth like words. It might be worth a look HTH, Andrew

…

On Sun, 19 Feb 2023 at 18:20, Anthony Howe ***@***.***> wrote: Today I got basic JNI support implemented in post4 <https://github.com/SirWumpus/post4> (not yet pushed to GitHub) where Java can evaluate a string or file, enter the REPL, and receive exceptions. Its pretty one way just now and needs some polish. However thinking on the reverse, being able to call Java methods from Forth, raises a few issues to think about: - Object construction and passing this back to Java. - Object life cycle. Forth needs to ensure objects it creates, via Java constructors, and only it knows about are not GC'ed behind its back. How to release an object (reference) when done. - Overloaded constructors and methods. In most cases the method with the greatest "arity` (think Erlang) is probably the ideal one to invoke, but it assumes those with lesser arity are convenience methods. - Java package and method names are some times stupidly long, which might affect input buffer size. - I/O redirection, let Java feed input, capture output. - For file and string evaluation, are results from the data and/or float stacks expected to be passed back to Java? How deep? — Reply to this email directly, view it on GitHub <#132 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAYVWSO5PBVHM2WNYEDHZ43WYJP6VANCNFSM6AAAAAAUFQY3NA> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[jwoehr]

3. Write Forth-like language in Java that can call Java. https://sourceforge.net/projects/fiji/

…

On Wed, Feb 22, 2023 at 9:37 AM ruv ***@***.***> wrote: The fusion of Forth and Java can be implemented in two variants: 1. Forth is integrated into a Java application (Java calls Forth). It can bring to the application (I suppose): - an interactive terminal (REPL) with introspection/debugging facilities, - testing, configuring, scripting (without recompilation of the application). 2. Access to Java from a Forth system (Forth calls Java). This brings capabilities to: - test/introspect/debug Java components (classes), - partially, what JShell <https://docs.oracle.com/javase/10/jshell/introduction-jshell.htm> now provides. - use libraries/components from the huge Java ecosystem in a Forth program, - create light wrappers/scripts over a Java component just in Forth (without creating a Java application for that), - as an example, once I needed a simple wrapper over Apache™ FOP <https://xmlgraphics.apache.org/fop/> component. — Reply to this email directly, view it on GitHub <#132 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABDEBBDQIDIIA5FIRI3S5ZDWYY6FXANCNFSM6AAAAAAUFQY3NA> . You are receiving this because you were mentioned.Message ID: ***@***.***>

-- *JACK WOEHR, IBM Champion 2021-2023 <https://www.credly.com/users/jack-woehr/badges>* *SENIOR IBM i ENGINEER* 303.847.8442 ***@***.*** stay connected <https://www.linkedin.com/company/absolute-performance-inc./> <https://www.absolute-performance.com/> www.absolute-performance.com NON-DISCLOSURE NOTICE: This communication including any and all attachments is for the intended recipient(s) only and may contain confidential and privileged information. If you are not the intended recipient of this communication, any disclosure, copying further distribution or use of this communication is prohibited. If you received this communication in error, please contact the sender and delete/destroy all copies of this communication immediately.