Writing Java lib using Scala

[Oliver Ruebenacker]

     Hello,

  How is writing a library in Scala for use in a Java project? We are using Scala but may want to publish libraries to be used in pure Java projects.

  My understanding is that this is supposed to work, but there may be some complications:

  - Presumably this would add the Scala standard library as a dependency. Is it large? Does its presence have any restrictions or side effects?

  - If the API uses Scala collections, callers would have to handle Scala collections.

  - The API looks form the Java side sometimes different from what it looks from the Scala side, and sometimes this involves long weird identifiers with lots of dollar symbols.

  Any practical advice?

  Thanks!

     Take care
     Oliver
 

--
IT Project Lead at PanGenX (http://www.pangenx.com)
The purpose is always improvement

[Marius Danciu]

Probably the sane thing to do is to have a Java wrapper over the Scala library.

Marius

--
You received this message because you are subscribed to the Google Groups "scala-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-user+...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Bienlein]

Am Montag, 29. April 2013 14:43:32 UTC+2 schrieb Marius Danciu:

Probably the sane thing to do is to have a Java wrapper over the Scala library.

This is the way the Java API in ScalaSTM (see http://nbronson.github.io/scala-stm/) has been done. I use ScalaSTM from Java and it works well this way. Another approach is to create a Scala wrapper that puts some mold around the Scala code for which no counterpart exists in the Java world so that the wrapper itself can have an API that maps well to Java.

-- Bienlein

 

[Roland Kuhn]

Hi Oliver,

29 apr 2013 kl. 14:39 skrev Oliver Ruebenacker:

  How is writing a library in Scala for use in a Java project? We are using Scala but may want to publish libraries to be used in pure Java projects.

Akka is an example of this technique.

  My understanding is that this is supposed to work, but there may be some complications:

  - Presumably this would add the Scala standard library as a dependency. Is it large? Does its presence have any restrictions or side effects?

scala-library.jar is around 7MB and its presence is not a problem per se.

  - If the API uses Scala collections, callers would have to handle Scala collections.

We offer overloaded signatures or differently named methods which take or return java.lang.Iterable and friends.

  - The API looks form the Java side sometimes different from what it looks from the Scala side, and sometimes this involves long weird identifiers with lots of dollar symbols.

One technique for hiding those—if you want to simultaneously have a nice Scala API—is demonstrated by akka.actor.ActorRef / ScalaActorRef (https://github.com/akka/akka/blob/master/akka-actor/src/main/scala/akka/actor/ActorRef.scala).

  Any practical advice?

Do not use Any in existential types, prefer AnyRef; provide abstract classes together with traits containing behavior (i.e. “trait Foo” plus “abstract class AbstractFoo extends Foo”); watch out for companion objects, since traits cannot have them, only abstract classes can; do not use nested objects or if you do then provide also forwarder methods for obtaining references to them from Java. Ah, and provide static methods (i.e. methods on companion object) for generic operations so that Java’s type inference can reduce the pain in the fingers (e.g. https://github.com/akka/akka/blob/master/akka-actor/src/main/scala/akka/io/Pipelines.scala#L232).

Last but not least: be aware that “protected” does not have any effect on the emitted byte-code, in general all nice Scala access restrictions become “public” (including private[akka] and friends).

Summary: it is workable but requires some discipline and consideration.

Regards,

Roland

  Thanks!

     Take care
     Oliver
 

--
IT Project Lead at PanGenX (http://www.pangenx.com)
The purpose is always improvement

--
You received this message because you are subscribed to the Google Groups "scala-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-user+...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

Dr. Roland Kuhn
Akka Tech Lead
Typesafe – Empowering professional developers to build amazing apps.
twitter: @rolandkuhn

See you at Scala Days 2013 in NYC!
June 10th - June 12th
www.scaladays.org

[Seth Tisue]

On Mon, Apr 29, 2013 at 8:39 AM, Oliver Ruebenacker <cur...@gmail.com> wrote:

  - Presumably this would add the Scala standard library as a dependency. Is it large? Does its presence have any restrictions or side effects?

In 2.10 it's 6.8M. If it's a problem you might consider using ProGuard to make it smaller (potentially far smaller if you're not using much of it).

Restrictions, side effects: no. It's just a jar. (At least unless there's something really unusual about your environment, like you're trying to run on Android or some non-standard JVM, or maybe, I don't know, you're doing heavy bytecode manipulation or something.)

 

  Any practical advice?

What Roland said. But, a few additions:

It isn't strictly necessary, but if you really want to be conservative and safe, consider writing interfaces in Java and then implementing them in Scala, hiding the implementation classes and exposing only the interfaces. Writing the interface in Java means you can't accidentally do something Java can't grok.

Remember that from Java, type parameters must always refer to reference types, never to primitive types. So if you have a Iterator[Int] on the Scala side, it will appear as an Iterator<Object> on the Java side, where at runtime the Objects will be boxed Integers. (You might have hoped for the type visible from Java to be Iterator<Integer>, but was this was impossible to arrange while still maintaining full interoperability; see e.g. SI-4214.)

Consider using GenJavaDoc to provide your API's users with JavaDoc instead of ScalaDoc. (It's new; I haven't tried it.)

Read "Integrating Scala with Java", which is Chapter 10 of Josh Suereth's book Scala in Depth.

I call my Scala code from my legacy Java code all the time and have experienced only minor, easily worked around annoyances, like funny names (MODULE$, _$eq) and additional typecasts. I haven't personally attempted the more ambitious goal of providing an API that isn't merely *possible* to call from Java, but it is really slick and convenient and won't alienate Java people who know no Scala. Akka and Play seem to have succeeded at that, though.