{"id":520,"date":"2011-08-08T15:20:00","date_gmt":"2011-08-08T15:20:00","guid":{"rendered":"http:\/\/www.javacodegeeks.com\/2012\/10\/what-features-of-java-have-been-dropped-in-scala.html"},"modified":"2013-12-18T08:39:22","modified_gmt":"2013-12-18T06:39:22","slug":"what-features-of-java-have-been-dropped","status":"publish","type":"post","link":"https:\/\/www.javacodegeeks.com\/2011\/08\/what-features-of-java-have-been-dropped.html","title":{"rendered":"What features of Java have been dropped in Scala?"},"content":{"rendered":"
Despite more complex and less intuitive syntax compared to Java, Scala actually drops several features of Java, sometimes for good, other times providing replacements on the standard library level. As you will see soon, Scala isn’t a superset of Java (like Groovy) and actually removes a lot of noise. Below is a catalogue of the missing features<\/i>.
\n 
\n 
\n 
\n 
\n 
\n <\/p>\n

break and continue in loops<\/strong><\/p>\n

<\/strong>Every time I see code like this:<\/p>\n

while(cond1) {\r\n    work();\r\n    if(cond2)\r\n        continue;\r\n    rest();\r\n}\r\n<\/pre>\n
I feel as if it has been written by a guy who truly misses the times when goto wasn’t yet considered harmful. Hands up who finds this version more readable:  <\/p>\n
while(cond1) {\r\n    work();\r\n    if(!cond2)\r\n        rest();\r\n}\r\n<\/pre>\n
Getting rid of break requires a little more though, but generally extracting a loop to a separate method\/function (or at least putting it at the end of existing method) and using return instead will do the trick. By the why Scala allows you to define functions inside other functions, so you won’t pollute your global class namespace with plenty of small methods used only once \u2013 problem that sometimes arises when religiously<\/a> extracting methods in Java.<\/p>\n
break and continue<\/i> \u2013 we thank you in the name of our fathers and grandfathers for your contribution to imperative programming. But we no longer need you and we won’t miss you.<\/p>\n
Arrays<\/strong><\/p>\n
It’s amazing how many bad habits have we learnt by all these years and how we got used to idioms that are inconsistent and simply painful. You have covariant arrays in Java with square brackets syntax, length<\/i> final property and ability to store primitive types. You also have Java collections framework with List<t> abstraction \u2013 that is not covariant, uses get() and size() methods and can’t store primitives. The list of differences does not end here, however isn’t every array just a special case of List? Why do we have a special syntax for arrays in the language while collections are implemented in on top of the language? And isn’t a bit irritating to convert them from one to another all the time? <\/p>\n
String[] array = new String[10];\r\nList<string> list = Arrays.asList(array);\r\nString[] array2 = list.toArray(new String[list.size()]);\r\n<\/pre>\n
Converting from collection to array is my favourite Java idiom… Why not just have same syntax, same methods, same abstraction, polymorphic behaviour \u2013 and only different implementation names?<\/p>\n
val array = Array(\"ab\", \"c\", \"def\")\r\nprintln(array(1))\r\narray filter (_.size > 1)\r\n\r\nval list = List(\"ab\", \"c\", \"def\")\r\nprintln(list(1))\r\nprintln(list filter (_.size > 1))\r\n<\/pre>\n
And don’t worry, behind the scenes Scala compiler will use the same efficient array bytecode as if you were using plain arrays in Java. No magic abstractions and several layers of wrapping.<\/p>\n
Primitives<\/strong><\/p>\n
Another weird Java inconsistency \u2013 why do we have a choice between primitive int and wrapping Integer? If the variable is of Integer type does this mean it is optional (null), or is it just that you can’t use primitives in collections (but can in arrays, as pointed out above)? Is this unboxing safe (also known as: how on earth this can throw NullPointerException?<\/i>) Can I compare these to integers using == operator? And can I simply call toString() to get string representation of this number?<\/p>\n
In Scala you no longer have a choice, every primitive type is an object, while most of the time still being a primitive in memory and in bytecode. How is that possible? Have a look at the following popular example: <\/p>\n
val x = 37     \/\/x and y are objects of type Int\r\nval y = 5\r\nval z = x + y  \/\/x.+(y) - yes, Int class has a \"+\" method\r\nassert(z.toString == \"42\")\r\n<\/pre>\n
x, y and z are instances of type Int. They are all objects, even adding two integers is semantically a method + called on x with y argument. If you think it has to perform terribly \u2013 once again behind the scenes it is compiled into ordinary primitive addition. But now you can easily use primitives in collections, pass them when any type is required (Object in Java, Any in Scala) or simply create a text representation without awkward Integer.toString(7) idiom. Sooo many bad habits.<\/p>\n
Checked exceptions<\/strong><\/p>\n
Another feature that I can hardly miss. Not much to be said here. Neither any mainstream language except Java have them, nor any mainstream JVM language (except Java). This topic is still relatively controversial, however if you’ve ever tried to deal with ubiquitous SQLException or IOException, you know how much boilerplate it introduces without good reason. Anyway, look at the next examples…<\/p>\n
Interfaces<\/strong><\/p>\n
<\/strong>This one is good! Scala doesn’t have interfaces. Instead it introduces traits \u2013 something in between abstract classes (some trait methods might have implementation) and interfaces (one can mix in more than one trait). So essentially traits enables you to implement multiple inheritance while avoiding dreadful diamond problem<\/a>. How it is done requires an article on its own (in short: last trait wins), but I would rather show you an example how helpful traits are to reduce duplication.<\/p>\n
Suppose you are writing an interface to abstract binary protocol. Most implementations take raw byte array, so in Java you would simply say: <\/p>\n
public interface Marshaller {\r\n    long send(byte[] content);\r\n}\r\n<\/pre>\n
This is great from the implementation perspective \u2013 just implement a single method and the abstraction is ready. However users of the interface are complaining that it is cumbersome and not very convenient. They would like to send strings, binary and text streams, serialized objects and so on. They can either create a facade around this interface (and every user will create his\/hers very own with a distinct set of bugs) or force the author of the API to extend it: <\/p>\n
public interface Marshaller {\r\n\r\n    long send(byte[] content);\r\n\r\n    long send(InputStream stream);\r\n\r\n    long send(Reader reader);\r\n\r\n    long send(String s);\r\n\r\n    long send(Serializable obj);\r\n\r\n}\r\n<\/pre>\n
Now the API is a breeze, however every implementation has to implement five methods instead of one. Also note that since most abstracted protocols are based on byte arrays, all the methods can be implemented in terms of the first one. And only the first one contains the actual marshalling code. This in turns causes every implementation to have the exact same four methods \u2013 duplication didn’t go away \u2013 it has just been moved. Actually this problem is known as a thin vs. rich interface and it has been described in great Programming in Scala<\/a> book. What I was typically doing was to give service providers an abstract class with typical implementations of all the methods except the root one, which was used by all other methods: 
 
<\/div> <\/div><\/p>\n
import org.apache.commons.io.IOUtils;\r\n\r\npublic abstract class MarshallerSupport implements Marshaller {\r\n\r\n    @Override\r\n    public abstract long send(byte[] content);\r\n\r\n    @Override\r\n    public long send(InputStream stream) {\r\n        try {\r\n            return send(IOUtils.toByteArray(stream));\r\n        } catch (IOException e) {\r\n            throw new RuntimeException(e);  \/\/choose something more specific in real life\r\n        }\r\n    }\r\n\r\n    @Override\r\n    public long send(Reader reader) {\r\n        try {\r\n            return send(IOUtils.toByteArray(reader));\r\n        } catch (IOException e) {\r\n            throw new RuntimeException(e);\r\n        }\r\n    }\r\n\r\n    @Override\r\n    public long send(String s) {\r\n        try {\r\n            return send(s.getBytes(\"UTF8\"));\r\n        } catch (UnsupportedEncodingException e) {\r\n            throw new RuntimeException(e);\r\n        }\r\n    }\r\n\r\n    @Override\r\n    public long send(Serializable obj) {\r\n        try {\r\n            final ByteArrayOutputStream bytes = new ByteArrayOutputStream();\r\n            new ObjectOutputStream(bytes).writeObject(obj);\r\n            return send(bytes.toByteArray());\r\n        } catch (IOException e) {\r\n            throw new RuntimeException(e);\r\n        }\r\n    }\r\n\r\n}\r\n<\/pre>\n
Now everyone is happy \u2013 instead of copying all the overloaded methods over and over, just subclass the MarshallerSupport<\/i> and implement what you need. But what if your interface implementation also has to subclass some other class? You are out of luck then. In Scala however you change the interface to trait, opening the possibility to mix in (think something between extending and implementing) several other traits. By the way do you remember what I said about checked exceptions? <\/p>\n
trait MarshallerSupport extends Marshaller {\r\n\r\n    def send(content: Array[Byte]): Long\r\n\r\n    def send(stream: InputStream): Long = send(IOUtils.toByteArray(stream))\r\n\r\n    def send(reader: Reader): Long = send(IOUtils.toByteArray(reader))\r\n\r\n    def send(s: String): Long = send(s.getBytes(\"UTF8\"))\r\n\r\n    def send(obj: Serializable): Long = {\r\n        val bytes = new ByteArrayOutputStream\r\n        new ObjectOutputStream(bytes).writeObject(obj)\r\n        send(bytes.toByteArray)\r\n    }\r\n}\r\n<\/pre>\n
Switch statement<\/strong><\/p>\n
There is no switch statement in Scala. Calling pattern matching<\/a> a better switch would be a blasphemy. Not only because pattern matching in Scala is an expression returning a value and also not because you can switch over literally any value if you want. Not even because there is no fall-through, break and default. It’s because Scala’s pattern matching enables you to match whole object structures and lists, even with wildcards. Consider this expression simplification method, originally taken from already mentioned Programming in Scala<\/a> book: <\/p>\n
abstract class Expr\r\ncase class Var(name: String) extends Expr\r\ncase class Number(num: Double) extends Expr\r\ncase class UnOp(operator: String, arg: Expr) extends Expr\r\ncase class BinOp(operator: String, left: Expr, right: Expr) extends Expr\r\n\r\n\/\/...\r\n\r\ndef simplify(expr: Expr): Expr = expr match {\r\n    case UnOp(\"-\", UnOp(\"-\", e)) => e  \/\/double negation\r\n    case BinOp(\"+\", e, Number(0)) => e \/\/adding zero\r\n    case BinOp(\"*\", e, Number(1)) => e \/\/multiplying by one\r\n    case _ => expr\r\n}\r\n<\/pre>\n
Look carefully how clever this code is! If our expression is unary \u201c-\u201d operation and the argument is a second unary \u201c-\u201d operation with any expression e as an argument (think: -(-e)), then simply return e. If you find this pattern matching example hard to read, check out the roughly equivalent Java code. However please remember: size doesn’t matter (one could probably do the same with Perl one-liner) \u2013 it’s about readability and maintainability: <\/p>\n
public Expr simplify(Expr expr) {\r\n    if (expr instanceof UnOp) {\r\n        UnOp unOp = (UnOp) expr;\r\n        if (unOp.getOperator().equals(\"-\")) {\r\n            if (unOp.getArg() instanceof UnOp) {\r\n                UnOp arg = (UnOp) unOp.getArg();\r\n                if (arg.getOperator().equals(\"-\"))\r\n                    return arg.getArg();\r\n            }\r\n        }\r\n    }\r\n    if (expr instanceof BinOp) {\r\n        BinOp binOp = (BinOp) expr;\r\n        if (binOp.getRight() instanceof Number) {\r\n            Number arg = (Number) binOp.getRight();\r\n            if (binOp.getOperator().equals(\"+\") && arg.getNum() == 0 ||\r\n                    binOp.getOperator().equals(\"*\") && arg.getNum() == 1)\r\n                return binOp.getLeft();\r\n        }\r\n    }\r\n    return expr;\r\n}\r\n<\/pre>\n
instanceof\/casting <\/strong><\/p>\n
As with many other features, Scala does not have a built-in syntax for instanceof<\/i> and downcasting. Instead the language provides you methods on actual objects: <\/p>\n
val b: Boolean = expr.isInstanceOf[UnOp]\r\nval unOp: UnOp = expr.asInstanceOf[UnOp]\r\n<\/pre>\n
In Scala a lot of features normally considered as part of the language are actually implemented in the language itself or at least they don’t require a special syntax. I like this idea, in fact I find Ruby’s way of creating objects (Foo.new \u2013 method instead of new operator) very attractive and even unusual lack of if conditionals in Smalltalk requires some attention<\/a>.<\/p>\n
Enums<\/strong><\/p>\n
Scala doesn’t have built-in support for enums. Enumerations in Java are known to have several fancy features which other languages envy like type safety and ability to add methods to each enum. There are at least two ways to emulate enums in Scala: <\/p>\n
object Status extends Enumeration {\r\n   type Status = Value\r\n\r\n   val Pending = Value(\"Pending...\")\r\n   val Accepted = Value(\"Accepted :-)\")\r\n   val Rejected = Value(\"Rejected :-(\")\r\n}\r\n\r\nassume(Status.Pending.toString == \"Pending...\")\r\nassume(Status.withName(\"Rejected :-(\") == Status.Rejected)\r\n<\/pre>\n
Or if you don’t care about textual enum representation: <\/p>\n
object Status extends Enumeration {\r\n   type Status = Value\r\n\r\n   val Pending, Accepted, Rejected = Value\r\n}\r\n<\/pre>\n
However the second and the most comprehensive way to emulate enums is to use case classes. Side note: name is actually an abstract method defined in base class. When you declare a method without defining the method body it is implicitly assumed to be abstract \u2013 no need to mark the obvious with extra keywords: <\/p>\n
sealed abstract class Status(val code: Int) {\r\n def name: String\r\n}\r\n\r\ncase object Pending extends Status(0) {\r\n override def name = \"?\"\r\n}\r\n\r\ncase object Accepted extends Status(1) {\r\n override def name = \"+\"\r\n}\r\n\r\ncase object Rejected extends Status(-1) {\r\n override def name = \"-\"\r\n}\r\n\r\n\/\/...\r\n\r\nval s: Status = Accepted\r\n\r\nassume(s.name == \"+\")\r\nassume(s.code == 1)\r\n\r\ns match {\r\n    case Pending =>\r\n    case Accepted =>\r\n    case Rejected =>  \/\/comment this line, you'll see compiler warning\r\n}\r\n<\/pre>\n
This approach, although has nothing to do with enums per se, has many advantages. The biggest one is that the compiler will warn you when performing non exhaustive pattern matching \u2013 think: switch over an enum in Java without explicitly referencing each and every value or default block.<\/p>\n
Static methods\/fields<\/strong><\/p>\n
Scala doesn’t have a notion of static fields and methods. Instead it has a feature named objects as opposed to classes. When you define a class using object<\/i> keyword, Scala runtime will eagerly create one instance of this class and make it available under class name. This is essentially a singleton<\/i> pattern built into the language but the most important is the mindset shift introduced by this approach. Instead of a bunch of static functions artificially gathered together inside a class (which is only a de facto<\/i> namespace in this case) you have a singleton with true<\/i> methods: <\/p>\n
sealed abstract class Status\r\ncase object Pending extends Status\r\ncase object Accepted extends Status\r\ncase object Rejected extends Status\r\n\r\ncase class Application(status: Status, name: String)\r\n\r\nobject Util {\r\n\r\n    def groupByStatus(applications: Seq[Application]) = applications groupBy {_.status}\r\n\r\n}\r\n<\/pre>\n
Here is how the syntax works (and nice ScalaTest<\/a> DSL example): <\/p>\n
@RunWith(classOf[JUnitRunner])\r\nclass UtilTest extends FunSuite with ShouldMatchers {\r\n\r\n   type ? = this.type\r\n\r\n   test(\"should group applications by status\") {\r\n      val applications = List(\r\n         Application(Pending, \"Lorem\"),\r\n         Application(Accepted, \"ipsum\"),\r\n         Application(Accepted, \"dolor\")\r\n      )\r\n\r\n      val appsPerStatus = Util.groupByStatus(applications)\r\n\r\n      appsPerStatus should have size (2)\r\n      appsPerStatus(Pending) should (\r\n            have size (1) and\r\n            contain (Application(Pending, \"Lorem\"))\r\n      )\r\n      appsPerStatus(Accepted) should (\r\n            have size (2) and\r\n            contain (Application(Accepted, \"ipsum\")) and\r\n            contain (Application(Accepted, \"dolor\"))\r\n      )\r\n   }\r\n}\r\n<\/pre>\n
volatile\/transient\/native and serialVersionUID are gone<\/strong><\/p>\n
The language designers decided to convert the first three keywords into annotations. Both approaches have pros and cons, hard to find the clear winner. However turning serialVersionUID<\/i> into a class level annotation is a pretty good choice. I know this field existed long before annotations were introduced to the Java language, so we shouldn’t blame it. But I always hated when in statically typed languages some names\/fields have special meaning not reflected anywhere except the language specification itself (magic numbers?<\/i>) Unfortunately there are examples of this unpleasant behaviour in Scala as well, namely special treatment of apply() method and methods ending with colon. Too bad.<\/p>\n
Pre\/post-increment<\/strong><\/p>\n
You cannot do i++<\/i> and ++i<\/i> in Scala. Period. You need a bit more verbose i += 1<\/i> \u2013 and to make matters worse this expression return Unit<\/i> (think: void<\/i>). How can we deal with this noticeable feature missing? Turns out that very often this type of constructs are imperative style legacy and they can easily be avoided by using more functional and pure constructs. Take the following problem as an example:<\/p>\n
You have two same sized arrays: one with names and a second one with ages. Now you want to display each name with a corresponding age \u2013 somehow iterating over both arrays in parallel. In Java this is surprisingly tough to implement cleanly: <\/p>\n
String[] names = new String[]{\"Alice\", \"Bobby\", \"Eve\", \"Jane\"};\r\nInteger[] ages = new Integer[]{27, 31, 29, 25};\r\n\r\nint curAgeIdx = 0;\r\nfor (String name : names) {\r\n    System.out.println(name + \": \" + ages[curAgeIdx]);\r\n    ++curAgeIdx;\r\n}\r\n\r\n\/\/or:\r\n\r\nfor(int idx = 0; idx < names.length; ++idx)\r\n    System.out.println(names[idx] + \": \" + ages[idx]);\r\n}\r\n<\/pre>\n
In Scala maybe it is shorter, but very mysterious at first: <\/p>\n
var names = Array(\"Alice\", \"Bobby\", \"Eve\", \"Jane\")\r\nvar ages = Array(27, 31, 29, 25)\r\n\r\nnames zip ages foreach {p => println(p._1 + \": \" + p._2)}\r\n<\/pre>\n
zip<\/i>? I encourage you play a bit with this example. If you don’t feel like starting up the whole IDE, try it with Scala REPL: <\/p>\n
$ scala\r\nscala> Array(\"one\", \"two\", \"three\") zip Array(1, 2, 31)   \r\nres1: Array[(java.lang.String, Int)] = Array((one,1), (two,2), (three,31))\r\n<\/pre>\n
Look carefully, do you see the result array containing pairs of corresponding elements from the first and the second arrays \u201czipped<\/i>\u201d together? One simple experiment and now suddenly it should be clear and much more readable than ordinary imperative solution.<\/p>\n
Scala inventors looked very thoroughly on Java language and they didn’t just add syntactic sugar (like function literals or implicit conversions). They discovered plenty of inconsistencies and annoyances in Java, getting rid of them and providing more concise and deliberate replacements. Despite higher level constructs like primitive and array objects, under the hood the same fast and straightforward bytecode is generated. <\/p>\n
References : <\/strong>What features of Java have been dropped in Scala?<\/a> from our JCG<\/a> partner Tomek Nurkiewicz<\/a><\/i> at NoBlogDefFound<\/a><\/p>\n
Happy Coding! Do not forget to share!<\/p>\n
Related Articles:<\/strong><\/p>\n