是否缺少第三方库阻止您使用Scala？

Question

I started learning Scala the other day. As for the language itself, I think it's fantastic, no problems there at all. To aid in my learning process I set myself a task, to download, parse and index text from HTML pages.

In doing the above I found myself constantly digging into existing Java libraries. I found that I had to use Java libraries to:

1) Open a connection - java.net.URL

2) Parse the HTML (TagSoup - because a normal XML parser will not handle most badly formed HTML)

3) Index the text (Lucene)

Given that I had to rely on Java libraries to do a quite a lot of the heavy lifting I was left wondering if it was worth me using Scala to begin with, other than as a learning exercise. This was partly due to the fact that some extra mental effort was required to map between the two, for example, it's not intuitively obvious what the Scala type of a byte[] is, as everything is an object in Scala. It's this additional mental processing that can make the process seem a little clunky.

Does anyone else think fewer 3rd party libraries (compared to Java) is a barrier to using Scala in commercial projects?

if you can call existing Java libraries does it even matter, or does having to span two different languages in a codebase make it harder?

Answer 1

I don't quite see your concern. A Java library is typically a .jar file (compressed set of .class files). What would you expect a Scala library to be? Well, it would be a compressed set of .class files. Both languages are compiled to Java byte-code! So, to answer your questions:

Does anyone else think fewer 3rd party libraries (compared to Java) is a barrier to using Scala in commercial projects?

No, not really.

if you can call existing Java libraries does it even matter, or does having to span two different languages in a codebase make it harder?

If you're looking at the java-library as a compiled .jar file, you wouldn't have to span two different languages.

---

Edit: Sure, Scala has a very rich type system which compiled class-files can't make full use of. On the contrary, the vast number of useful librarys available in Java byte-code format probably makes Scala more attractive than other new (read modern) languages.

Answer 2

I recommend this article (and pattern):

Pimp my Library

Whenever a Java library has an interface that is just a little bit cumbersome in Scala, this is a great way to make it more convenient and your code more elegant. Here's a very simple example. I want to use the Scala XML pretty printer all the time in my code to return nicely formatted XML. This is the normal way to do that:

class Service {
val pp = new scala.xml.PrettyPrinter(80,2)
def content = 
  pp.format(<foo><bar>{something()}</bar></foo>)
}

however since I do this all the time I add this to my package

import scala.xml.Elem

object PrettyXml {
  val pp = new scala.xml.PrettyPrinter(80,2)
}

trait PrettyXml {
  case class Formatted(xml:Elem) { 
    def pretty = PrettyXml.pp.format(xml) 
  }
  implicit def toFormatted(xml:Elem) = Formatted(xml)
}

and now I can replace my original code with

class Service extends PrettyXML {
  val pp = new scala.xml.PrettyPrinter(80,2)
  def content = 
    <foo><bar>{something()}</bar></foo> pretty
}

If I didn't want to make it a trait I could probably put PrettyXML in a package object.

Answer 3

This is actually not as stupid and misguided a question as it seems. Some truths about libraries in Scala:

1. Without the vast infrastructure of Java libraries, there would be very little practical reason for most people to use Scala. Scala is a lovely language with some amazing features, but if you had to reinvent the wheel every time you needed to accomplish anything large, no one would bother.
2. Accessing native Java libraries from Scala is slightly more enjoyable than accessing Java libraries from Java, but only slightly. The problem here is that native Java libraries are considerably lower-level than either libraries written natively in Scala or good Scala wrappers of Java libraries. Native Java libraries tend to be littered with single-method interfaces (that should have been functions), lightly documented nullable arguments or returns (that should have been Option), unnecessary parallel class constructions or "helpers" (that should have been traits), hand-rolled not-quite-standard iterators, try-block-demanding resource management (due to lack of closures) and type signatures (particular with pre Java-1.5 libraries) that are laughably crude. It's unsurprising that Scala programmers see Java libraries as "necessary to get the job done" rather than something you actually look forward to manipulating.
3. Via either wrapping or pimping, it's actually pretty easy to take a Java native library and make it almost as joyful to use as a Scala native library. I expect simply gorgeous Scala adapters for most of the major enterprise libraries to become available in the near term.