Spring Context Internals: Part 2 — Bean Sources

Spring Context Internals: Part 1 — Refresh

<preview>
> "Scala EE" or "Probably the fastest way to get hated by both functional programmers and enterprise devs"

**Java is old**. It's really, really old. In fact, most of today's students did not exist by the time it were released. Still, Java is the most popular enterprise language ever, and Java EE makes it even better providing centralized way of creating all the environment your application is intended to be run in. But it's still old. Java works well for kinda old-minded people like me: I'm okay with declarations like the following:

```java
public class Task implements Callable<String>, Serializable {
    @Override
    public String call() {
        String result = doSomething();
        return result;
    }
}
```

If you agree the snippet above is good, then... </preview> you're probably, well, "old". We're not always old in a physical manner (well, not all of us, at least), but we recall those times we were sitting next to our company's review desk complaining about "those kids who broke it all again". We know verbosity saves the day and implicit mixins are the root of all evil, but everything is moving forward and our industry does as well. In fact, Java EE has figured it out a long time ago: CDI answers dependency injection and events handling, JAX-RS moves focus out of monstrous JSPs, async Servlet 3.0 knocks into JDBC drivers developers' doors and so on. 

But can we go further? Could we just switch the paradigm and move ahead with asynchronous networking, immutable structures and all that stuff? Not exactly. Our industry has created literally **tons** of code and we cannot just drop it. Instead of drastic technological breakage, we could just adopt new ideas without breaking our existing workflows. That's what I have made while creating my home page, [jtalk.me](https://jtalk.me). I was wondering if it's possible to use Scala with my old-n-nice Java EE environment, and yes, it is. Below is a summary of my "Scala EE" development experience. This may be useful if you're going to do Scala smooth and nicely, like I did. 

### Let's get to work!

First of all, let's find out how exactly Scala is different from Java for the VM. Here's a simple Scala class we will use in our comparison. It contains everything one would normally use in Scala class: properties, custom constructors, weird methods signatures and so on:

```scala
class TestClass @Inject() (private var arg: String, b: String) extends Runnable 
                                               with Callable[String] 
                                               with Serializable
                                               with StrictLogging {

	private val privateImmutableField = "pif"
	private var privateMutableField = "pmf"

	@Inject
	var publicMutableField = b
	val publicImmutableField = "puif"

	def this() = this("a", "b")

	override def run(): Unit = logger.debug("run()")
	override def call = {
		logger.debug("call()")
		publicImmutableField + privateMutableField
	}
}

object TestClass {
	private val PCONSTANT_VAL = "pcv"
	val CONSTANT_VAL = "pucv"
	def apply(arg: String, b: String) = new TestClass(arg, b)
}
```

Now, let's make a trick: CFR decompiler comes in handy here. This is what comes out of it (I have replaced logging code with SLF4J-based one as it was too verbose):

```java
@Slf4j
@ScalaSignature(bytes="...")
public class TestClass implements Runnable, Callable<String>, Serializable {

	private String arg;

	private final String publicImmutableField;
	private final String privateImmutableField;

	@Inject
	private String publicMutableField;
	private String privateMutableField;

	public static TestClass apply(String string, String string2) {
		return TestClass$.MODULE$.apply(string, string2);
	}

	public static String CONSTANT_VAL() {
		return TestClass$.MODULE$.CONSTANT_VAL();
	}

	private String arg() { return this.arg; }
	private void arg_$eq(String x$1) { this.arg = x$1; }

	private String privateImmutableField() { 
		return this.privateImmutableField;
	}
	private String privateMutableField() { 
		return this.privateMutableField; 
	}

	private void privateMutableField_$eq(String x$1) { 
		this.privateMutableField = x$1; 
	}
	public String publicImmutableField() { 
		return this.publicImmutableField; 
	}

	public String publicMutableField() { 
		return this.publicMutableField; 
	}
	public void publicMutableField_$eq(String x$1) { 
		this.publicMutableField = x$1; 
	}
	
	@Override
	public void run() {
		log.debug("run()");
	}

	@Override
	public String call() {
		log.debug("call()");
		return this.publicImmutableField() 
			+ this.privateMutableField();
	}

	@Inject
	public TestClass(String arg, String b) {
		this.arg = arg;
		this.privateImmutableField = "pif";
		this.privateMutableField = "pmf";
		this.publicImmutableField = "puif";
		this.publicMutableField = b;
	}

	public TestClass() {
		this("a", "b");
	}
}
```

Interesting so far:

* All the fields are private despite their original visibility. Non-important as you will merely need public fields in your managed beans.
* All the public fields have public accessor methods. This is all right as direct fields access is not the way managed beans are intended to be used anyway.
* Constructors from object declaration has been reflected in our class as static methods. This is actually a recent Scala feature for better Scala-Java interoperability, but in our particular case it might be a problem, I'll explain it below.
* You can put an annotation to the default constructor. Still, it looks weird. We can live with that, I assume.
* Fields accessors are not JavaBeans-compatible. This is kinda fixable.
* Fields are kept and their annotations are kept as well. This is great, CDI will be pleased a lot.

<InfoMessage header={About object's methods propagation on class level}>
CDI and EJB containers have complications with static methods. As those cannot be proxied and may be misleading, they are not expected to be supported by containers. So, we should really avoid using Scala objects in Java EE environment. 
</InfoMessage>

JavaBeans requires us to write properties with those get/set methods. Scala uses it's own properties convention, but old-style properties may still be required, for example, in JPA entities. Scala has an easy and convenient way of creating such properties with `@BeanProperty` annotation:

```scala
@BeanProperty
var id: String
```

This is literally equal to:

```java
private String id;

public String getId() {
    return id;
}

public void setId(String id) {
    this.id = id;
}

// All the Scala-style properties magic here 
```

Now, once we're all-packed and well-prepared, we can just go and write an enterprise application in Scala, right? Well, not really. There are several pitfalls we must take care of before.

### JPA Metamodel generation

I like this fresh-new Criteria API. It's really type-safe and verbose and I use it whenever I can. But what this API would be without a proper metamodel? We need to generate it, and then we need to use it. 

<InfoMessage>
You really can skip metamodel (and this whole paragraph) by just applying string names to Root's/Join's getters, but why would you choose to use Criteria API at the first place if you skip all the sweet parts?
</InfoMessage>

The problem with metamodel generation is that it's build upon Java's compile-time annotations processing, which is not really supported by Scala very well. In fact, Scala supports them and scalac will process all the necessary stuff with hibernate-modelgen in project's dependencies, but Scala-to-Java cooperation works poorly there. Scala will not generate metamodel for Java entities used by Scala classes. So, you'll need to either keep all your entities in Java and compile Java first, or keep all your entities in Scala and compile your Java last. I have found no way to break this, unfortunately.

### JSF-specific support

JSF is a weird technology: while being kinda modern and handy, it has it's own pitfalls kept from the very beginning. One of those pitfalls is a weird `<ui:repeat>` limitations: it ignores all the `Iterable<>` stuff only working with lists and arrays. So, Scala's `List`s will not work in any sense. Weird and tricky:

```scala
// Nota bene: this import is really required
import scala.collection.JavaConversions._

@Named
@ViewScoped
@ManagedBean
def ArticleBean {
    private var comments: List[Comment] = _
    def getComments() = new java.util.ArrayList(comments)
}
```

However, all the other JSF parts work well including action methods, view events and all that stuff. This is quite expected from those decompiled samples we've seen above.

### CDI events support

Except for tricky declarations, everything works as expected:

```scala
@ManagedBean
@ApplicationScoped
class EventProcessor {
    def onEvent(@Observes(during = AFTER_SUCCESS) e: MyEvent): Unit = {
        someAction()
    }
}
```

<InfoMessage>
This "during" thing is exciting. If you've missed it, you should really try it. From now on all the event processors without transactional lifecycle support are just garbage from my point of view.
</InfoMessage>

### Container-provided boundaries

Scala is all about laziness. Lazy initializers, lazy streams, lazy arguments and all those functors you use so easily. But there's a catch. There's always a catch, isn't it? So, how will all that lazy staff work in EJB envoronment? ```Hint: not so well```. 

Consider inspecting the following code:

```scala
@Stateless
@LocalBean
class ArticleService {

    @PersistenceContext
    private var em: EntityManager = _

    @TransactionAttribute(REQUIRES_NEW)
    def loadComments(articleIds: List[String]): Stream[Comment] = articleIds.toStream
        .map(em.find(classOf[Article], _))
        .filter(_ != null)
        .flatMap(_.getComments)
        .filter(_ != null)
}
```

Looks nice, isn't it? But what if I tell you about ```javax.transaction.TransactionRequiredException```? Our EntityManager will really walk out of scope very kindly and all the construct will fail unexpectedly once this stream gets used. Scala is not designed for managed environments and requires extreme care as well as good container knowledge. 

<InfoMessage>
You can also loose something out of your secured method this way, but who cares about this method-level security anyway?
</InfoMessage>

### Stateful beans pitfall

Why do we need stateful session beans? For an extended persistence context, of course. And how do we declare such a context? With `type` field of our `@PersistenceContext` annotation, of course. And `type` is a keyword in Scala...

<InfoMessage>
Well, I can imagine a human being who is interested in slow and non-recyclable POJO stateful bean really is, but why shall we talk about such an unusual demands at the first place?
</InfoMessage>

However, there's always a workaround, isn't it? And here it comes:

```scala
@Stateful
@LocalBean
class ArticleEditor {

    @PersistenceContext(`type` = EXTENDED, synchronization = UNSYNCHRONIZED)
    private var em: EntityManager = _

    @TransactionAttribute(MANDATORY)
    def save() = em.joinTransaction()
}
```

### val is not final!

While our life was so bright and shiny, here comes the dark part: Scala has no ```public static final``` thing at all. All your attempts on creating this will, in fact, result in a static method's bytecode instead of a nice field. This could be all right most of the time, but there's a tiny part of Java where method presence will ruin everything. This part is called "annotation argument". 

Wouldn't it be nice to write like:

```scala
object Constants {
    val FIELD_SIZE = 100
}

@Entity
class SomeEntity {
    @BeanProperty
    @Column(length = Constants.FIELD_SIZE)
    private var field: String = _
}
```

Well, in fact, this wouldn't work. No chance, end of the road, drop off. Scala will generate `public static int FIELD_SIZE() { return 100; }` thing here and your annotation will yell at you demanding it's argument to be accessible at compile time. Then what about that:

```java
public class Constants {
    private static final int FIELD_SIZE = 100;
}
```

**This will not work either.** The reason is that `scalac` will not parse your Java class declared as an import. Instead, it will just couple them in a regular way complaining you about this field's non-constant nature anyway. That's why I kept all my model entities in Java nevertheless. 

### Bonus chapter

Since you have read that far, here's a simple bonus. Scala has a strange feature: one can declare both field and constructor argument in the same place like:

```scala
class SomeClass(private var myField) {
    def doSomethingWithThisField() = ...
}
```

But how do I declare an annotation on either field or constructor argument? Looks like Scala designers have not thought of it in time, so we have a huge workaround here:

```scala
import scala.annotation.meta.field
import scala.annotation.meta.param

class SomeClass(@(Observes @param)(during = IN_PROGRESS) 
        @(Inject @field) var f: String) {
    def doSomethingWithThisField() = ...
}
```

<InfoMessage>
Yes, I know observers are pretty useless being placed at constructor's arguments. I were just unable to find a handy annotation with arguments to reflect how weird this workaround is.
</InfoMessage>

This will produce nice bytecode decompiling like:

```java
public class SomeClass {
    
    @Inject
    public String f;

    public SomeClass(@Observes(during = AFTER_SUCCESS) String f) {
        this.f = f;
    }

    public void doSomethingWithThisField() {
        ...
    }
}
```

<InfoMessage>
Public fields in managed beans are bad. And single-letter variables are bad either in most cases. But our case matches the exception: this code does not fit into my blog's page otherwise.
</InfoMessage>

**As a conclusion**: Scala is, well, *usable* in Java EE environment. If you're ready for some trade-offs, you can easily use it getting some nice features like extended collections transformers, nice functional programming features, type inference and so on. However, you should really understand not only what you are writing, but also how would it work in runtime. If you are looking for a whole new universe but still not ready for a huge step into, you may give this "Scala EE" a try.

Scala EE

<preview>
> We have an annotation for this!

When once annotations has been introduced, they used to be just a metadata storage for the _real code_ developers would write. Java EE Contexts and Dependency Injection mechanism it not well-known yet, but allows quite easy and exciting annotation-driven injections of POJOs in managed beans. No more constructor based injections, no ladder-styled signatures and dependency hell, CDI will handle everything in a simple declarative manner. 

</preview>

For example, assume we want to inject two clock components: UTC clock and local timezone clock. In plain Java it will look like:

```java
@Stateful
class Component {
    private Clock utc;
    private Clock local;

    public void setUtc(Clock utc) {
        this.utc = utc;
    }

    public void setLocal(Clock local) {
        this.local = local;
    }
}

component.setUtc(Clock.systemUTC());
component.setLocal(Clock.systemDefaultZone());
```

Java CDI allows us to extract dependency declaration on per-project basis and inject those clocks based on annotation contexts. First of all, we declare contextual annotations for UTC and local timezones:

```java
@Qualifier
@Retention(RetentionPolicy.RUNTIME)
@Target({
        ElementType.FIELD, 
        ElementType.METHOD, 
        ElementType.TYPE, 
        ElementType.PARAMETER
})
public @interface UTC {
}

@Qualifier
@Retention(RetentionPolicy.RUNTIME)
@Target({
        ElementType.FIELD, 
        ElementType.METHOD, 
        ElementType.TYPE, 
        ElementType.PARAMETER
})
public @interface LocalTime {
}
```

@Qualifier annotation tells CDI that @UTC and @LocalTime are contextual annotations capable of injected interfaces implementations separation.

Then we declare injections provider capable of supplying Clock implementation based on context qualifier:

```java
@Singleton
public class Producers {

    @Produces
    @UTC
    public static final Clock UTC_CLOCK = Clock.systemUTC();

    @Produces
    @LocalTime
    public static final Clock LOCAL_CLOCK = Clock.systemDefaultZone();
}
```

From now on, CDI will get Producers.UTC_CLOCK and Producers.LOCAL_CLOCK on every injection marked with @UTC or @LocalTime qualifier respectively, allowing us to focus on application logic, not dependency injection infrastructure. For example, let's rewrite our Component to use CDI mechanisms:
 
```java
@Stateful
class Component {

    @Inject
    @UTC
    Clock utc;
    
    @Inject
    @LocalTime
    Clock local;
}
```

Once Component bean instance is created, both utc and local fields will be filled with Producers.UTC_CLOCK and Producers.LOCAL_CLOCK respectively. No other actions required, CDI will make all the magic to make this work.


CDI magic for beginners

<preview>
During the JTorrentier project development I was in need of a fast TCP/UDP sockets interface for Enterprise JavaBeans. I had firstly discovered a [JCA-sockets](https://code.google.com/p/jca-sockets/) project, but it's kind of weird: one utilizes synchronous IO by blocking one of WorkManager threads and it seems that its author has weird understanding of Java Connector Architecture. 

[SocketConnector](/projects/socket-connector) is created from scratch by using only JCA specifications as a guidance. It runs Netty 4.x and performs asynchronous TCP IO with clear and reliable client interface (through JCA resource adapter standard mechanisms: ConnectionFactory for outbound IO and message-driven beans for inbound one). It also guarantees connections closing on client application undeploying which lowers maintenance costs and simplifies client code. As a JCA-compliant resource adapter this project may also be used as a reference Java connector implementation
</preview>

SocketConnector is licensed under GNU General Public License v3 and available in Github [repository](https://github.com/Jtalk/jca-socket-connector).

SocketConnector for JCA is released!

<preview>
> Even the best of us sometimes must write in C#

Last month I was working on the [File Watcher](https://bitbucket.org/__jtalk/filewatcher) application. It's a <abbr title="Windows Presentation Foundation">WPF</abbr>-based file system changes watching software written in C#. The main goal was to make cataloguing easier by providing filter-based file system changes watcher with copy/move reactions. This is also a forerunner of the JTorrentier BitTorrent client I'm going to release later this year.
</preview>

File Watcher application released

<preview>
My colleague asked me if it there a printf-like function in C/C++ which would provide him a way of printing array of various values according to some format line. No function has been found so far, but aren't we DEVELOPERS ourselves?

There's a System V 64-bit ABI compatible function which takes a format string, list of arguments, and passes them into the libc sprintf function. 

<InfoMessage header={Not safe for work}>
  The code below is dangerous and should NEVER be used not only in production environment but also not 50 miles closer to any of social infrastructure objects.
</InfoMessage>
</preview>

Weird 64-bit ABI made be a headache: where have those old cdecl times gone when we could put everything on stack and let nature do the rest?

```x86asm
.text
.globl lsprintf
.type lsprintf, @function
lsprintf:
# Arguments parsing
# rdi Stores output string address
# rsi Stores format string address
mov %rdx, %rax # list pointer
mov %rcx, %r10 # number of arguments
 
push %rbx
push %r12
mov %rcx, %rbx # Callee-saved register, we need this 
               # to clear stack in accordance with cdecl convension
 
# Let the party start!
cmp $0, %r10
je do_call
 
cmp $1, %r10
jl do_call
mov 0(%rax), %rdx
add $8, %rax
 
cmp $2, %r10
jl do_call
mov 0(%rax), %rcx
add $8, %rax
 
cmp $3, %r10
jl do_call
mov 0(%rax), %r8
add $8, %rax
 
cmp $4, %r10
jl do_call
mov 0(%rax), %r9
add $8, %rax
 
cmp $5, %r10
jl do_call
 
sub $4, %r10 # Do not count arguments saved in registers
mov %rcx, %r11 # We need this rcx register
mov %r10, %rcx
mov %rax, %r12 # We will multiply!
mov $8, %rax
push %rdx
mul %rcx # rax contains number of bytes to the end of arguments list
pop %rdx
add %rax, %r12
sub $8, %r12
mov %r12, %rax
 
start_loop:
push 0(%rax)
sub $8, %rax
loop start_loop
 
mov %r11, %rcx
 
do_call:
mov $0, %rax # Number of floating point arguments passed
call sprintf
 
cmp $5, %rbx
jl f_end
 
sub $4, %rbx
mov %rax, %r9
mov %rbx, %rax
mov $8, %rdx
push %rdx
mul %rdx # 64-bit values
pop %rdx
add %rax, %rsp
mov %r9, %rax
 
f_end:
pop %r12
pop %rbx
ret
```
				

It's assembler time!

Senior full stack wizard, open source developer & debugger Jedi