JVM tweaks

-Xmx512m
-XX:MaxHeapSize=512m
-XX:MaxPermSize=512M
-XX:+CMSClassUnloadingEnabled

DCEVM - Dynamic Code Evolution VM

When a java developer works, she spends a lot of time reloading the server context.

The Dynamic Code Evolution Virtual Machine (DCE VM) is a modification of the Java HotSpot(TM) VM that allows unlimited redefinition of loaded classes at runtime. The current hotswapping mechanism of the HotSpot(TM) VM allows only changing method bodies. Our enhanced VM allows adding and removing fields and methods as well as changes to the super types of a class.

It is an open source project released under the GPL v2.0 license.


There's a handy plugin for Intellij, that just downloads DCEVM JRE and registers it inside IDE.
Installation is performed with these steps:

• Install a DCEVM in Intellij as follows: File -> Settings -> Plugins -> search for DCEVM -> Install.
• Restart the program and see in the Event Log something like that:
  "DCEVM is available for your environment: Would you like to download it?" 
• Downloading will be performed into something like that: c:\Users\anton\.IntelliJIdea13\config\plugins\DCEVM_JRE
• Now that we have a DCEVM JRE installed, let’s update the configuration.
• Edit Tomcat debug configurations by specifying new JRE. 
• Run/Debug Configurations -> Server tab -> Use alternative JRE: c:\Users\anton\.IntelliJIdea13\config\plugins\DCEVM_JRE
• Run/Debug Configurations -> Server tab -> "On frame deactivation" –> update classes and resources

Now run the project in debug option and try to changes some classes and wait until the code reloads.

Consider tweaking your JAVA_OPTS as described in this post

Just a good skeleton for a new Scala project

This project aims to simplify creating a project from scratch.It's simpler than g8 or typesafe activator because it doesn't require any additional tools, just clone, build and run. It provides a simple way to configure:

https://github.com/schastny/skeleton

Originally coded by: https://github.com/fractal

Implicit Parameters vs Default Parameter Values

There are, at least, two techniques in Scala to pass default value to a method

1) default parameter value

scala> def f(i: Int = 0) = i
f: (i: Int)Int

scala> f()
res0: Int = 0

scala> f(1)
res1: Int = 1

2) implicit parameter

scala> def g(implicit i: Int) = i
g: (implicit i: Int)Int

scala> implicit val default = 0
default: Int = 0

scala> g(1)
res5: Int = 1

scala> g
res7: Int = 0

In which case do you choose one or another ? With the power of implicit, default values are they a usefull feature ?

You should definitely prefer default parameter value.

1. You should never create or use implicit parameters of general types like Int or String. See citation below.
2. Default value is the simplest solution. In terms of language features complexity.
3. Implicit parameters are for some kind of "context" for your method. If there is no context, just default value you can confuse other developers.
4. Implicit value search will cost you some amount of compilation time.
5. Implicit parameters should be specified manually only in rare cases.

---------
Real world examples of implicit params: Akka actors ActorRef method

def !(message: Any)(implicit sender: ActorRef = Actor.noSender): Unit

Here we are automatically pass along the sender reference while sending a message to another Actor.
This code will, if invoked from within Actor 'A' automatically pass along the ActorRef of Actor 'A' as the sender of this message:

// From within an Actor
greeter ! Greet
        

Scala Traits

Scala traits are like Java interfaces with concrete methods, but they can actually do much more.

Traits can, for example, declare fields and maintain state.
In fact, you can do anything in a trait definition that you can do in a class definition, and the syntax looks exactly the same, with only two exceptions.

First, a trait cannot have any "class" parameters, i.e., parameters passed to the primary constructor of a class. In other words, although you could define a class like this:

  class Point(x: Int, y: Int)

The following attempt to define a trait would not compile:

  trait NoPoint(x: Int, y: Int) // Does not compile

The other difference between classes and traits is that whereas in classes, super calls are statically bound, in traits, they are dynamically bound. If you write "super.toString" in a class, you know exactly which method implementation will be invoked. When you write the same thing in a trait, however, the method implementation to invoke for the super call is undefined when you define the trait. Rather, the implementation to invoke will be determined anew each time the trait is mixed into a concrete class. This curious behavior of super is key to allowing traits to work as stackable modifications.
Traits are a way to inherit from multiple class-like constructs, but they differ in important ways from the multiple inheritance present in many languages. One difference is especially important: the interpretation of super. With multiple inheritance, the method called by a super call can be determined right where the call appears. With traits, the method called is determined by a linearization of the classes and traits that are mixed into a class. This is the difference that enables the stacking of modifications described in the previous section.

When you instantiate a class with new, Scala takes the class and all of its inherited classes and traits and puts them in a single, linear order. Then, whenever you call super inside one of those classes, the invoked method is the next one up the chain. If all of the methods but the last call super, the net result is stackable behavior.

The precise order of the linearization is described in the language specification. It is a little bit complicated, but the main thing you need to know is that, in any linearization, a class is always linearized before all of its superclasses and mixed in traits. Thus, when you write a method that calls super, that method is definitely modifying the behavior of the superclasses and mixed in traits, not the other way around.

Linearization Rules

Scala's linearization rules are described starting on page 49 of the Scala Language Specification (SLS), Chapter 5, "Classes and Objects".

In order to allow reuse of compiled classes and to ensure well-defined behavior, the linearization must satisfy a few rules:

• The linearization of any class must include unmodified the linearization of any class (but not trait) it extends.
• The linearization of any class must include all classes and mixin traits in the linearization of any trait it extends, but the mixin traits need not be in the same order as they appear in the linearization of the traits being mixed in.
• No class or trait may appear more than once in the linearization.

 -------
The main properties of Scala's linearization are illustrated by the following example: Say you have a class Cat, which inherits from a superclass Animal and two traits Furry and FourLegged. FourLegged extends in turn another trait HasLegs:

  class Animal 
  trait Furry extends Animal
  trait HasLegs extends Animal
  trait FourLegged extends HasLegs
  class Cat extends Animal with Furry with FourLegged

Class Cat's inheritance hierarchy and linearization are shown in Figure 12.1. Inheritance is indicated using traditional UML notation:[3] arrows with white, triangular arrowheads indicate inheritance, with the arrowhead pointing to the supertype. The arrows with darkened, non-triangular arrowheads depict linearization. The darkened arrowheads point in the direction in which super calls will be resolved.

Figure 12.1 - Inheritance hierarchy and linearization of class Cat.

The linearization of Cat is computed from back to front as follows. The last part of the linearization of Cat is the linearization of its superclass, Animal. This linearization is copied over without any changes. (The linearization of each of these types is shown in Table 12.1 here.) Because Animal doesn't explicitly extend a superclass or mix in any supertraits, it by default extends AnyRef, which extends Any. Animal's linearization, therefore, looks like:

The second to last part is the linearization of the first mixin, trait Furry, but all classes that are already in the linearization of Animal are left out now, so that each class appears only once in Cat's linearization. The result is:

This is preceded by the linearization of FourLegged, where again any classes that have already been copied in the linearizations of the superclass or the first mixin are left out:

Finally, the first class in the linearization of Cat is Cat itself:

When any of these classes and traits invokes a method via super, the implementation invoked will be the first implementation to its right in the linearization.

12.7 To trait, or not to trait? [link]

Whenever you implement a reusable collection of behavior, you will have to decide whether you want to use a trait or an abstract class. There is no firm rule, but this section contains a few guidelines to consider.

1. If the behavior will not be reused, then make it a concrete class. It is not reusable behavior after all.
2. If it might be reused in multiple, unrelated classes, make it a trait. Only traits can be mixed into different parts of the class hierarchy.
3. If you want to inherit from it in Java code, use an abstract class. Since traits with code do not have a close Java analog, it tends to be awkward to inherit from a trait in a Java class. Inheriting from a Scala class, meanwhile, is exactly like inheriting from a Java class. As one exception, a Scala trait with only abstract members translates directly to a Java interface, so you should feel free to define such traits even if you expect Java code to inherit from it. See Chapter 29 for more information on working with Java and Scala together.
4. If you plan to distribute it in compiled form, and you expect outside groups to write classes inheriting from it, you might lean towards using an abstract class. The issue is that when a trait gains or loses a member, any classes that inherit from it must be recompiled, even if they have not changed. If outside clients will only call into the behavior, instead of inheriting from it, then using a trait is fine.
5. If efficiency is very important, lean towards using a class. Most Java runtimes make a virtual method invocation of a class member a faster operation than an interface method invocation. Traits get compiled to interfaces and therefore may pay a slight performance overhead. However, you should make this choice only if you know that the trait in question constitutes a performance bottleneck and have evidence that using a class instead actually solves the problem.
6. If you still do not know, after considering the above, then start by making it as a trait. You can always change it later, and in general using a trait keeps more options open.

More here: http://www.artima.com/pins1ed/traits.html

Scala Case Class

Case classes can be seen as plain and immutable data-holding objects that should exclusively depend on their constructor arguments.
This functional concept allows us to

• use a compact initialisation syntax (Node(1, Leaf(2), None)))
• decompose them using pattern matching
• have equality comparisons implicitly defined

In combination with inheritance, case classes are used to mimic algebraic datatypes.
If an object performs stateful computations on the inside or exhibits other kinds of complex behaviour, it should be an ordinary class.
-------

Technically, there is no difference between a class and a case class -- even if the compiler does optimize some stuff when using case classes. However, a case class is used to do away with boiler plate for a specific pattern, which is implementing algebraic data types.
A very simple example of such types are trees. A binary tree, for instance, can be implemented like this:

sealed abstract class Tree
case class Node(left: Tree, right: Tree) extends Tree
case class Leaf[A](value: A) extends Tree
case object EmptyLeaf extends Tree

That enable us to do the following:

// DSL-like assignment:
val treeA = Node(EmptyLeaf, Leaf(5))
val treeB = Node(Node(Leaf(2), Leaf(3)), Leaf(5))

// On Scala 2.8, modification through cloning:
val treeC = treeA.copy(left = treeB.left)

// Pretty printing:
println("Tree A: "+treeA)
println("Tree B: "+treeB)
println("Tree C: "+treeC)

// Comparison:
println("Tree A == Tree B: %s" format (treeA == treeB).toString)
println("Tree B == Tree C: %s" format (treeB == treeC).toString)

// Pattern matching:
treeA match {
  case Node(EmptyLeaf, right) => println("Can be reduced to "+right)
  case Node(left, EmptyLeaf) => println("Can be reduced to "+left)
  case _ => println(treeA+" cannot be reduced")
}

// Pattern matches can be safely done, because the compiler warns about
// non-exaustive matches:
def checkTree(t: Tree) = t match {
  case Node(EmptyLeaf, Node(left, right)) =>
  // case Node(EmptyLeaf, Leaf(el)) =>
  case Node(Node(left, right), EmptyLeaf) =>
  case Node(Leaf(el), EmptyLeaf) =>
  case Node(Node(l1, r1), Node(l2, r2)) =>
  case Node(Leaf(e1), Leaf(e2)) =>
  case Node(Node(left, right), Leaf(el)) =>
  case Node(Leaf(el), Node(left, right)) =>
  // case Node(EmptyLeaf, EmptyLeaf) =>
  case Leaf(el) =>
  case EmptyLeaf =>
}

Note that trees construct and deconstruct (through pattern match) with the same syntax, which is also exactly how they are printed (minus spaces).
And they can also be used with hash maps or sets, since they have a valid, stable hashCode.
---------

• Case classes can be pattern matched
• Case classes automatically define hashcode and equals
• Case classes automatically define getter methods for the constructor arguments.

Those are the only differences to regular classes.

Regexp Lookahead & Lookbehind

Source: http://denis-zhdanov.blogspot.com/2009/10/regexp-lookahead-and-lookbehind.html
Source: http://www.regular-expressions.info/lookaround.html

Lookahead

Generally speaking 'lookahead' allows to check if subsequent input characters match particular regexp. For example, let's consider word 'murmur' as our input and capitalize all 'r' symbols that are not followed by 'm' symbol (i.e. we expect to get 'murmuR' as the output). Here is a naive approach:

    System.out.println("murmur".replaceAll("r[^m]", "R"));

However, it doesn't perform any change, i.e. 'murmur' is printed. The reason is that 'r[^m]' means that the pattern is 'r' symbol followed by the symbol over than 'm'. There is no symbol after the last 'r' symbol, so, the pattern is not matched.

Here lookahead comes to the rescue - it allows to check if subsequent symbol(s) match to the provided regexp without making matched subsequent character(s) part of the match. It may be 'positive' or 'negative', i.e. allows to define if we're interested in match or unmatch. Here is the example:

// 'Negative' lookahead, 'r' is not followed by 'm'. >> prints 'murmuR'
System.out.println("murmur".replaceAll("r(?!m)", "R")); 

// 'Positive' lookahead, 'r' is followed by 'm'. >> prints 'muRmur'
System.out.println("murmur".replaceAll("r(?=m)", "R")); 

// It's possible to use regexp as 'lookahead' pattern >> prints 'murMur'
System.out.println("murmur".replaceAll("m(?!u[^u]+u)", "M")); // 

Lookbehind

'Lookbehind' behaves very similar to 'lookahead' but works backwards. Another difference is that it's possible to define only finite repetition regexp as 'lookbehind' pattern:

// 'Negative' lookbehind, 'c' is not preceded by 'b' >> prints 'abcadCaeeC' 
System.out.println("abcadcaeec".replaceAll("(?<!b)c", "C"));

// 'Positive' lookbehind, 'c' is preceded by 'b' >> prints 'abCadcaeec'
System.out.println("abcadcaeec".replaceAll("(?<=b)c", "C")); // 

// It's possible to use finite repetition regexp as 'lookbehind' pattern >> doesn't match because there is no 'c' preceded by two 'e'
System.out.println("abcadcaec".replaceAll("(?<=e{2})c", "C")); 

// It's not possible to use regexp that doesn't imply obvious max length as 'lookbehind' pattern >> PatternSyntaxException is thrown here
System.out.println("abcadcaec".replaceAll("(?<=a[^a]+ae?)c", "C"));