[erlang-questions] Use of Records in the Java API

Alexander Lamb <>
Wed Jun 11 10:23:28 CEST 2008


Hello,

My Erlang modules are mainly a server to Java Web applications (for  
the time being).

This means that I am making a big use of the Erlang Java API which  
works fine.
Since my Erlang modules use Mnesia to store data coming from the Java  
side (and vice versa), I need to implement functions with many  
parameters for example to insert new data in a Mnesia table.
I also need to convert tuples into actual Java objects when reading  
data.

This would be simpler if the Java API had an OtpErlangRecord. It would  
make it possible to subclass it and could even be the prefered way of  
bridging the Erlang world with the Java world. It would also avoid  
breaking code each time a new attribute is needed for a Mnesia table  
(making it today necessary to add a parameter to the complete chain of  
function calls).

I didn't find any mention of OtpErlangRecord in the documentation. I  
suspect it is because the Java API was written before records were  
introduced in Erlang.

In a more general sense, is there any plan to enhance the  
functionalities of the Java API  to handle more gracefully the  
mismatch between the loosely typed functional world of Erlang and the  
object oriented world of Java?

I could very well imagine a Java class to handle marshalling and  
unmarshalling of terms at a high level using records. You would add a  
type description to the attributes and on the Java side you would  
immediately receive objects (subclasses of OtpErlangRecord for  
example). It could look somewhat like tools such as Cayenne or  
Hibernate in the SQL world.

Just some thoughts. And since in two weeks Dennis Byrne is making a  
presentation at Erlang Exchange on that subject, maybe if Dennis is  
reading this post, he could consider preparing a few words in that  
direction for his London speech:-)
That comment actually also applies if the client is in ActionScript  
for a Flash/Flex application or even JavaScript.

Alex



More information about the erlang-questions mailing list