Top scala Questions

List of Tags

First note the inflammatory subject title is a quotation made about the manifesto of a UK political party in the early 1980s. This question is subjective but it is a genuine question, I've made it CW and I'd like some opinions on the matter.

Despite whatever my wife and coworkers keep telling me, I don't think I'm an idiot: I have a good degree in mathematics from the University of Oxford and I've been programming commercially for almost 12 years and in Scala for about a year (also commercially).

I have just started to look at the Scala collections library re-implementation which is coming in the imminent 2.8 release. Those familiar with the library from 2.7 will notice that the library, from a usage perspective, has changed little. For example...

> List("Paris", "London").map(_.length) 
res0: List[Int] List(5, 6)

...would work in either versions. The library is eminently useable: in fact it's fantastic. However, those previously unfamiliar with Scala and poking around to get a feel for the language now have to make sense of method signatures like:

def map[B, That](f: A => B)(implicit bf: CanBuildFrom[Repr, B, That]): That

For such simple functionality, this is a daunting signature and one which I find myself struggling to understand. Not that I think Scala was ever likely to be the next Java (or /C/C++/C#) - I don't believe its creators were aiming it at that market - but I think it is/was certainly feasible for Scala to become the next Ruby or Python (i.e. to gain a significant commercial user-base)

  • Is this going to put people off coming to Scala?
  • Is this going to give Scala a bad name in the commercial world as an academic plaything that only dedicated PhD students can understand? Are CTOs and heads of software going to get scared off?
  • Was the library re-design a sensible idea?
  • If you're using Scala commercially, are you worried about this? Are you planning to adopt 2.8 immediately or wait to see what happens?

Steve Yegge once attacked Scala (mistakenly in my opinion) for what he saw as its overcomplicated type-system. I worry that someone is going to have a field day spreading fud with this API (similarly to how Josh Bloch scared the JCP out of adding closures to Java).

Note - I should be clear that, whilst I believe that Josh Bloch was influential in the rejection of the BGGA closures proposal, I don't ascribe this to anything other than his honestly-held beliefs that the proposal represented a mistake.

Answered By: Martin Odersky ( 341)

I hope it's not a "suicide note", but I can see your point. You hit on what is at the same time both a strength and a problem of Scala: its extensibility. This lets us implement most major functionality in libraries. In some other languages, sequences with something like map or collect would be built in, and nobody has to see all the hoops the compiler has to go through to make them work smoothly. In Scala, it's all in a library, and therefore out in the open.

In fact the functionality of map that's supported by its complicated type is pretty advanced. Consider this:

scala> import collection.immutable.BitSet
import collection.immutable.BitSet

scala> val bits = BitSet(1, 2, 3)
bits: scala.collection.immutable.BitSet = BitSet(1, 2, 3)

scala> val shifted = bits map { _ + 1 }
shifted: scala.collection.immutable.BitSet = BitSet(2, 3, 4)

scala> val displayed = bits map { _.toString + "!" }
displayed: scala.collection.immutable.Set[java.lang.String] = Set(1!, 2!, 3!)

See how you always get the best possible type? If you map Ints to Ints you get again a BitSet, but if you map Ints to Strings, you get a general Set. Both the static type and the runtime representation of map's result depend on the result type of the function that's passed to it. And this works even if the set is empty, so the function is never applied! As far as I know there is no other collection framework with an equivalent functionality. Yet from a user perspective this is how things are supposed to work.

The problem we have is that all the clever technology that makes this happen leaks into the type signatures which become large and scary. But maybe a user should not be shown by default the full type signature of map? How about if she looked up map in BitSet she got:

map(f: Int => Int): BitSet     (click here for more general type)

The docs would not lie in that case, because from a user perspective indeed map has the type (Int => Int) => BitSet. But map also has a more general type which can be inspected by clicking on another link.

We have not yet implemented functionality like this in our tools. But I believe we need to do this, to avoid scaring people off and to give more useful info. With tools like that, hopefully smart frameworks and libraries will not become suicide notes.

James Fassett

Can someone please explain the major differences between Scala, Groovy and Clojure. I know each of these compiles to run on the JVM but I'd like a simple comparison between them.

Answered By: Daniel C. Sobral ( 412)

Groovy is a dynamically typed scripting language, whose syntax is very close to Java. It's good for fast prototyping, scripts, and learning dynamic languages without having to learn a new syntax (assuming you know Java).

Clojure is a dialect of Lisp with a few advanced features like Software Transactional Memory. If you like Lisp and would like to use something like it under the JVM, Clojure is for you. It's possibly the most functional language running on the JVM, and certainly the most famous one. Also, it has a stronger emphasis on immutability than other Lisp dialects, which takes it closer to the heart of functional language enthusiasts.

Scala is a fully object oriented language, more so than Java, with one of the most advanced type systems available on non-research languages, and certainly the most advanced type system on the JVM. It also combines many concepts and features of functional languages, without compromising the object orientation, but its compromise on functional language characteristics put off some enthusiasts of the latter.

While Groovy has good acceptance and a strong web framework in Grails, I personally think it is a language with limited utility, particularly as Jython and JRuby start making inroads on the JVM-land, compared to the others.

Clojure, even discounting some very interesting features, has a strong appeal just by being a Lisp dialect on JVM. It might limit its popularity, granted, but I expect it will have loyal community around it for a long time.

Scala can compete directly with Java, and give it a run for its money on almost all aspects. It can't compete in popularity at the moment, of course, and the lack of a strong corporate backing may hinder its acceptance on corporate environments. It's also a much more dynamic language than Java, in the sense of how the language evolves. From the perspective of the language, that's a good thing. From the perspective of users who plan on having thousands of lines of code written in it, not so.

As a final disclosure, I'm very familiar with Scala, and only acquainted with the other two.

I've to admit that I don't know much about functional programming. I read about it from here and there, and so came to know that in functional programming, a function returns the same output, for same input, no matter how many times the function is called. It's exactly like mathematical function which evaluates to same output for same value of input parameter which involves in the function expression.

For example, consider this:

f(x,y) = x*x + y; //it is a mathematical function

No matter how many times you use f(10,4), it's value will always be 104. As such, wherever you've written f(10,4), you can replace it with 104, without altering the value of the whole expression. This property is referred to as referential transparency of an expression.

As Wikipedia says (link),

Conversely, in functional code, the output value of a function depends only on the arguments that are input to the function, so calling a function f twice with the same value for an argument x will produce the same result f(x) both times.

So my question is: can a time function (which returns the current time) exist in functional programming?

  • If yes, then how can it exist? Does it not violate the principle of functional programming? It particularly violates referential transparency which is one of the property of functional programming (if I correctly understand it).

  • Or if no, then how can one know the current time in functional programming?

Answered By: Carsten König ( 190)

Yes and no.

Different FP languages solve them differently.

In Haskell (a very pure one) all this stuff has to happen in something called the IO Monad - see here. You can think of it as getting another input (and output) into your function (the world-state) or easier as a place where "impureness" like getting the changing time happens.

Other languages like F# just have some impureness built in and so you can have a function that returns different values for the same input - just like normal imperative languages.

As Jeffrey Burka mentioned in his comment: Here is the nice intro to the IO Monad straight from the HaskellWiki.

Craig P. Motlin

I like all three of the popular Java IDE's and all three have plug-ins for Scala. I'll probably try all three eventually, but since I'm totally new to the language I figured I'd ask which is the most full featured Scala IDE?

Answered By: Craig P. Motlin ( 165)

I've finally had the chance to use all three. As of June 2009, I find NetBeans to be the best. That's based purely on the editor though and I find Eclipse to be better in other ways. None of the three are very mature now, so I use Vim just as often.


As of March 2010, using snapshot builds of Scala 2.8, I find IntelliJ to be the best.


As of September 2010, using 2.8.0, I'm happy with IntelliJ, it's nearly satisfactory.


As of September 2011, using 2.9.0, I'm still using IntelliJ. I haven't tried Eclipse or Netbeans in the last year. Not much has changed.


As of January 2012, using 2.9.1, I'm still using IntelliJ. Scala IDE for Eclipse 2.0.0 is less buggy than previous versions, but the new features were already mostly already there in IntelliJ since September 2010. The refactoring support isn't great in any IDE, but IntelliJ is still slightly ahead.


I feel obligated to keep the updates coming. I decided to work through the "Functional Programming Principles in Scala" Coursera course using the Eclipse-based Scala IDE 2.1-M2 and I'm still sticking with IntelliJ. The Eclipse plugin has a few new refactorings, but it still messes up basic things like indenting if there's anything other than curly braces on the line. Plus I miss two crucial features that IntelliJ has had for a while; the ability to reformat or re-indent a whole file, and the auto-fix which adds or removes type annotations.

Shannon -jj Behrens

I'm stuck on whether I should focus on Play or Lift for doing web development in Scala.

Play looks very polished. The Scala-specific tutorial looks amazing. Furthermore, since I've been coding in MVC frameworks for a long time, it looks super familiar. However, it doesn't look like it can easily accomplish all the brilliant things that Lift can do. For instance, I can't find anywhere where it mentions Comet or Jetty Continuations. Furthermore, I kind of like the "View First" methodology in Lift because instead of using one controller, it lets me use a ton of snippets to piece together a page.

Lift looks brilliant, but leaves me with a lot of questions unanswered. Being highly stateful looks like it opens up a lot of possibilities, but I wonder how it'll turn out in practice. The book on Lift is a bit of a mess, and so is the wiki. The "Getting Started" page is badly formatted and is no match for Play's tutorial.

Does Play support Jetty Continuations?

Is it painful to get started with Lift doing normal web application development?

How does Lift's statefulness work out in practice? How do you cope with web servers going down in Lift? If I'm using Lift, and I push a new version of my code on a daily basis, does that mean I have to restart the application, and does that mean everyone's session gets wiped out?

Does Lift's statefulness actually make it easier to code?

What happens if someone messes around with the back button in Lift? What happens if a user is bouncing back and forth between several tabs?

Thanks, guys!

Answered By: Chris Hagan ( 115)

I've now used both on moderate sized projects (each fairly traditional Web 1 apps). Lift was the first, and definitely had the impressive flash-to-bang of having the rest of my team come back from lunch and be amazed that the full, pretty, site was already up (that's a default nav bar and little else when you look under the covers btw).

After that, though, we very quickly had to dive into the source to try to work db access out. There's an ORM shipped with Lift which I found to be so inaccessible that I eventually gave up on it. And the source is very idiomatic scala, which is either good or bad depending where on the curve you're currently sitting. There were several pieces of code that just had us scratching our heads and saying "But this is all just voodoo. Where did the CODE happen?"

I'll try to edit this soon with specific examples, but it might be quite off topic and I'm worried it would add fuel to the fire of scala being too hard for normal people (it isn't at all, but Pollack's code probably is. Too hard for me anyway).

Play, on the other hand, didn't have a huge scaffolding productivity peak upfront. But the error reporting and the xml literal integration meant that it only took a few hours to catch up to the initial gifted productivity that Lift gave.

By the way, "xml literal integration", just in case someone runs off to google it, just means this:

<div id="templatingContainer">

  def action={
    val xmlVariable = <span>literal</span> % new xml.UnprefixedAttribute("class","something",xml.Null)

Now obviously I've left some of the scaffolding out - codeBehind.scala should really have a surrounding object extending Controller, etc. On the other hand I HAVE left in my biggest pet peeve (Edit: This may no longer be true with Scala 2.8) with Scala in either context (minimized by strict enforcement of separate tiers) - that you can't write this literal:

<div class="something">content</div>

Because class is a keyword. By all means write the implicit conversation, but it's still a pain point for me.

The major differentiating factors for me are:

  • Error reporting. Play wins this hands down. It's simply the best error reporting I've ever seen.
  • Brilliant hot code reloading (although your libs won't be picked up until restart - slight pain point until you realise what's going on - can be tricky when you're also struggling with syntax). Play won here too.
  • Javascript - with Play you really don't have any options but to do traditional postbacks. Lift has utterly beautiful functional tricks going on that let you inline an entire logic cycle, abstracting out the fact that there's an HTTP request cycle in the middle.

I find Play to be sufficiently documented. Specifically, they've rewritten their (quite comprehensive) tutorial to be up to date with the Scala module and the 1.1 release which is a welcome relief.

On the other hand if I were to try to put a realtime app onto the web (and we get fairly frequent requests to drop our stylus based WPF app into a browser so one of these days it's coming) I would definitely go straight to Lift; it's super powerful with a few points of clunkiness. (Also, it might make a lot more sense now that we've all scalaed a bit more).

But if you're after MVC (dare I say PHP++) go with Play.

They're both beautiful, and absolutely differently purposed.

Thanks in advance to everyone who comes and improves on this answer. I think this is an important question to hash out in public, because I'd love to see Scala itself more widely adopted.


In the spirit of

what are some common mistakes made by Scala developers, and how can we avoid them?

Also, as the biggest group of new Scala developers come from Java, what specific pitfalls they have to be aware of?

For example, one often cited problem Java programmers moving to Scala make is use a procedural approach when a functional one would be more suitable in Scala. What other mistakes e.g. in API design newcomers should try to avoid.

Answered By: oxbow_lakes ( 82)

Keeping with return null idiom instead of using the Option trait to indicate that a method call may not return a value:

val p = productService.find(RIC, "MSFT.O")
if (p == null)
  //do something 
  //do something else

Should be replaced by:

productService.find(RIC, "MSFT.O") match {
  case None => //do something
  case Some(p) => //do something else

ie. the ProductService.find method should have the signature:

def find(cType: CodeType, code: String) : Option[Product]  

edit : NOTE one thing I've noticed is the unnecessary resolution (via code-forking) which is a common hangover from Java. For example, rather than the above I might do this instead:

productService.find(RIC, "MSFT.O").toRight(None).fold(doSomething, doSomethingElse)

Or one of the many functional alternatives!

Krzysiek Goj

What are the hidden features of Scala that every Scala developer should be aware of?

One hidden feature per answer, please.

Answered By: Willis Blackburn ( 85)

Okay, I had to add one more. Every Regex object in Scala has an extractor (see answer from oxbox_lakes above) that gives you access to the match groups. So you can do something like:

// Regex to split a date in the format Y/M/D.
val regex = "(\\d+)/(\\d+)/(\\d+)".r
val regex(year, month, day) = "2010/1/13"

The second line looks confusing if you're not used to using pattern matching and extractors. Whenever you define a val or var, what comes after the keyword is not simply an identifier but rather a pattern. That's why this works:

val (a, b, c) = (1, 3.14159, "Hello, world")

The right hand expression creates a Tuple3[Int, Double, String] which can match the pattern (a, b, c).

Most of the time your patterns use extractors that are members of singleton objects. For example, if you write a pattern like


then you're implicitly calling the extractor Some.unapply.

But you can also use class instances in patterns, and that is what's happening here. The val regex is an instance of Regex, and when you use it in a pattern, you're implicitly calling regex.unapplySeq (unapply versus unapplySeq is beyond the scope of this answer), which extracts the match groups into a Seq[String], the elements of which are assigned in order to the variables year, month, and day.


I would like to use Scala to persist data to a relational database, so what I am looking for are examples of CRUD operations using Scala.

I would like to code on a lower level of abstraction than an ORM like Hibernate/Toplink (read:JDBC), but between us, I would like to see examples of all types.

Answered By: Daniel C. Sobral ( 202)

EDIT: There's now a pretty good wiki about Scala libraries and frameworks here.

I know of five usable non-ORM database libraries for Scala. There's also one ORM which I mention below because it doesn't hide SQL, which might just make it a good fit.

Slick (previsously named Scalaquery)

The first one is Slick. It is the most mature one, and it tries to make queries use the same for-comprehension as Scala collections do. As an example of syntax style (which might be slightly out of date):

import java.lang.Integer
import com.novocode.squery._
import com.novocode.squery.Implicit._
import com.novocode.squery.session._
import com.novocode.squery.session.SessionFactory._

// Define table:
object Users extends Table[(Integer, String, String)]("users") {
  def id = intColumn("id", O.AutoInc, O.NotNull)
  def first = stringColumn("first")
  def last = stringColumn("last")
  def * = id ~ first ~ last

// Basic usage
val sf = new DriverManagerSessionFactory("org.h2.Driver", "jdbc:h2:mem:test1")
sf withSession {
  // Prepare a simple query
  val q1 = for(u <- Users) yield u

  // Print SQL statement to be executed:
  println(q1.selectStatement)  // displays SELECT,t1.first,t1.last FROM users t1

  // Print query result:
  for(t <- q1) println("User tuple: "+t)

  // Query statements can also be used with updates:
  val q = for(u <- Users if is 42) yield u.first ~ u.last
  q.update("foo", "bar")

As the project was renamed recently some resources are still under scalaquery name (website, groups). Slick will soon be included in Typesafe stack which can be seen as a proof of its maturity.


The second one is Querulous, which is a open source project from Twitter. This one gives you direct access to SQL, while dealing with a bunch of jdbc annoyances. Here's a simple example:

import com.twitter.querulous.evaluator.QueryEvaluator
val queryEvaluator = QueryEvaluator("host", "username", "password")
val users ="SELECT * FROM users WHERE id IN (?) OR name = ?", List(1,2,3), "Jacques") { row =>
  new User(row.getInt("id"), row.getString("name"))
queryEvaluator.execute("INSERT INTO users VALUES (?, ?)", 1, "Jacques")
queryEvaluator.transaction { transaction =>"SELECT ... FOR UPDATE", ...)
  transaction.execute("INSERT INTO users VALUES (?, ?)", 1, "Jacques")
  transaction.execute("INSERT INTO users VALUES (?, ?)", 2, "Luc")


The third one is Squeryl. Style-wise, it sits midway between ScalaQuery -- which hides SQL behind Scala comprehensions as much as possible -- and Querulous -- which uses SQL strings directly.

Squeryl provides a SQL-like DSL, which gives you type safety and give you a strong likelyhood that the statements won't fail at run-time if they compile at all. Again, a simple example:

// Defining tables and a schema:
import org.squeryl.PrimitiveTypeMode._

class Author(var id: Long, 
             var firstName: String, 
             var lastName: String)

class Book(var id: Long, 
           var title: String,
           @Column("AUTHOR_ID") // the default 'exact match' policy can be overriden
           var authorId: Long,
           var coAuthorId: Option[Long]) {
  def this() = this(0,"",0,Some(0L))

object Library extends Schema {
  //When the table name doesn't match the class name, it is specified here :
  val authors = table[Author]("AUTHORS")
  val books = table[Book]

// Basic usage
val session = Session.create( 
  java.sql.DriverManager.getConnection("jdbc:postgresql://localhost:5432/squeryl", "squeryl", "squeryl"), 
  new PostgreSqlAdapter 

//Squeryl database interaction must be done with a using block :  
import Library._
using(session) { 
  books.insert(new Author(1, "Michel","Folco"))            
  val a = from(authors)(a=> where(a.lastName === "Folco") select(a)) 

O/R Broker

The fourth is O/R Broker, which, despite the name, is not an ORM. Classes can be designed in any way desired. No interfaces/traits to implement, no conventions to uphold, no annotations needed.

case class Song(id: Option[Long], title: String, seconds: Short)
case class Album(id: Option[Long], title: String, year: Short, songs: IndexedSeq[Song])
case class Artist(id: Option[Long], name: String, albums: Set[Album])

Extractors are declarative, written in Scala. Can be reused in other queries that fit the expectation of the extractor.

object SongExtractor extends JoinExtractor[Song] {
  val key = Set("SONG_ID")

  def extract(row: Row, join: Join) = {
    new Song(

object AlbumExtractor extends JoinExtractor[Album] {
  val key = Set("ALBUM_ID")

  def extract(row: Row, join: Join) = {
    new Album(
          join.extractSeq(SongExtractor, Map("TITLE"->"SONG_TITLE"))

object ArtistExtractor extends JoinExtractor[Artist] {
  val key = Set("ARTIST_ID")

  def extract(row: Row, join: Join) = {
    new Artist(

One could then use that like this:

val ds: javax.sql.DataSource = ...
val builder = new SQLFileBuilder(ds, new"sql/"))
val broker =

// Print all artists with their albums (if any)
val artists = broker.readOnly() { session =>
  session.selectAll[Artist]('selectArtist) // ' I wish they could fix the Scala Symbol formatting
for (ar <- artists) {
      if (ar.albums.isEmpty)
        println("\t<No albums>")
      else for (al <- ar.albums) {
        println("\t" + al.title)
        for (s <- al.songs) {
          println("\t\t" + (al.songs.indexOf(s)+1) + ". " + s.title)


Anorm comes from Play Framework, and I don't know if it can be used stand alone or not. Basically, it ditches mappings and DSL completely, giving you direct access to SQL. A simple query may look like this:

// Create an SQL query
val selectCountries = SQL("Select * from Country")

// Transform the resulting Stream[Row] as a List[(String,String)]
val countries = selectCountries().map(row => 
    row[String]("code") -> row[String]("name")

It also supports pattern matching for row extraction:

val countries = SQL("Select name,population from Country")().collect {
    case Row("France", _) => France()
    case Row(name:String, pop:Int) if(pop > 1000000) => BigCountry(name)
    case Row(name:String, _) => SmallCountry(name)      

Binding variables in queries uses this syntax:

        select * from Country c 
        join CountryLanguage l on l.CountryCode = c.Code 
        where c.code = {countryCode};
).on("countryCode" -> "FRA")

And it also has support for use of parse combinators to translate queries or even table schemas into data structures. You can either define the parser yourself, or use some default conventions (like a case class mapping field names to column names) and let it do the work for you.

Circumflex ORM

Finally, there's Circumflex ORM. I'm copying here a few examples from their site:

class Category extends Record[Category] {
  val id = field(
  val name = field(
  val books = oneToMany(Book.category)    // allows navigating between associations transparently

object Category extends Table[Category] with LongIdPK[Category] {
  val name = stringColumn("name")         // creates a column
      .notNull                            // creates NOT NULL constraint
      .unique                             // creates UNIQUE constraint
      .validateNotEmpty                   // adds NotEmpty validation
      .validatePattern("^[a-zA-Z]{1,8}$") // adds Pattern validation

class Book extends Record[Book] {
  val id = field(
  val title = field(Book.title)
  val category = manyToOne(Book.category)

object Book extends Table[Book] with LongIdPK[Book] {
  val title = stringColumn("title")
  val category = longColumn("category_id")
      .references(Category)     // creates an association with Category
      .onDeleteSetNull          // specifies a foreign-key action

new DDLExport(Category, Book).create   // creates database schema

// find category by id
val c = Category.get(2l)
// find all books
val allBooks = Book.all
// find books for category
val cBooks = c.get.books
// find books by title
Book.criteria.add("title" like "a%").list

      .from(Category as "c" join (Book as "b"), Category as "c1")
      .where("" like "a%")

select(count(""), "").from(Category as "c" join (Book as "b")).list

If I missed any existing project, just drop a comment and I'll add them to this answer. Don't bother with blogs, papers, wikis or the like, though.


I have heard lots of raving about Akka framework (Java/Scala service platform), but so far have not seen many actual examples of use cases it would be good for. So I would be interested in hearing about things developers have used it succesfully.

Only one limitation: please do not include case of writing a chat server. :-) (why? since this has been overused as an example for lots of similar things)

EDIT: Since there are many good answers, my choice of accepted answer is bit arbitrary; I thought highest voted one seems like a reasonable choice. Thank you everyone for good answers!

Answered By: Raymond Roestenburg ( 82)

I have used it so far in two real projects very successfully. both are in the near real-time traffic information field (traffic as in cars on highways), distributed over several nodes, integrating messages between several parties, reliable backend systems. I'm not at liberty to give specifics on clients yet, when I do get the OK maybe it can be added as a reference.

Akka has really pulled through on those projects, even though we started when it was on version 0.7. (we are using scala by the way)

One of the big advantages is the ease at which you can compose a system out of actors and messages with almost no boilerplating, it scales extremely well without all the complexities of hand-rolled threading and you get asynchronous message passing between objects almost for free.

It is very good in modeling any type of asynchronous message handling. I would prefer to write any type of (web) services system in this style than any other style. (Have you ever tried to write an asynchronous web service (server side) with JAX-WS? that's a lot of plumbing). So I would say any system that does not want to hang on one of its components because everything is implicitly called using synchronous methods, and that one component is locking on something. It is very stable and the let-it-crash + supervisor solution to failure really works well. Everything is easy to setup programmatically and not hard to unit test.

Then there are the excellent add-on modules. The Camel module really plugs in well into Akka and enables such easy development of asynchronous services with configurable endpoints.

I'm very happy with the framework and it is becoming a defacto standard for the connected systems that we build.


I have followed the tutorial at Scala and Android with Scala 2.7.3 final. The resulting Android App works but even the most basic application takes several minutes (!) to compile and needs 900 kb compressed, which is a show stopper for mobile applications. Additionally, the IDE runs out of memory every now and then. I assume dex is not made for big libraries like the scala-library.

So my question is: Has anyone actually done this and is there any cure for this?

Answered By: Wade Mealing ( 79)

I've written some basic Android applications in Scala, nothing too epic. Not being a Java programmer I was suggested to use a "treeshake", I was explained by a friend that this strips out all the unnecessary libraries from the jar files.

I have not documented it, but I found that someone else already has:

Proguard is not the only solution, you might find something that suits your work flow or is more suited for your environment.