Well can you give more info about these ports? Sounds like you want to do interprocess communication of some kind with the JVM?
1. How exactly would you setup the JVM? Will you need to wrap every Java class you want to use with some kind of communication mechanism? What about callbacks?
2. Can you subclass a Java class?
3. What is the overhead of calling Java methods from Erlang?
4. Has anyone demonstrated a bridge to a non-trivial Java library using a language not running on the JVM?
I feel interprocess communication might be ok for some apps but not all apps.
1. Yes, you write a communication mechanism. You can either use an existing one (like Thrift) or use the Erlang binary protocol. Erlang expects you to be acting like an erlang message-based process, like an actor.
2. No. Erlang is not an OO langauge, although its concurrency model is the actor concurrency model, which sometimes feels like Smalltalk's object model.
3. The cost of communication. Having implemented a few systems that do this, I've found it to be fairly small, even using a slow glue layer like ruby. See https://github.com/KirinDave/fuzed/tree ... Powerset uses almost exactly this codebase to manage query analysis on its frontend before dispatching to our results retrieval layer. Thus far, it's been one of the most flexible and robust parts of our architecture.
I felt this way too, and it is the case in some very specific scenarios. But the truth of the matter is that Java itself is often the wrong tool in these cases, so it's somewhat of a red herring to say that.
1. How exactly would you setup the JVM? Will you need to wrap every Java class you want to use with some kind of communication mechanism? What about callbacks?
2. Can you subclass a Java class?
3. What is the overhead of calling Java methods from Erlang?
4. Has anyone demonstrated a bridge to a non-trivial Java library using a language not running on the JVM?
I feel interprocess communication might be ok for some apps but not all apps.