I’m switching jobs in March, so I’ve decided to move my blog to my personal domain. Please point your browsers to http://gekkio.fi/blog for future content!
For now this blog will remain as an archive, but I will not add any new content and commenting has been disabled. The new blog contains all posts previously found here, although the URLs will naturally be different (sorry, Google & other bots!).
Jawwa ZK Gritter is an open source library that can be used to add Growl-like notifications to ZK apps. The library provides a simple-to-use server-side Java API that can be used to control notifications in the application. Installation instructions are available in the reference manual.
A sample app that demonstrates all the customization options is available at Github:
https://github.com/Gekkio/blog/tree/master/2012/10/zk-gritter
The library provides a class called Gritter, which contains multiple static methods. Notifications are added using the builder pattern, so you must first obtain a notification builder, build the notification by calling the appropriate methods, and finally complete the builder and show the notification.
Gritter.notification().withTitle("ZK Gritter demo").withText(LOREM_IPSUM).
show()
All notifications require both the title and text parameters, and you must remember to call show or the notification will not be actually shown to the user.
The library supports multiple parameters that can be used to customize the appearance and behaviour of the notifications. The API is fully documented with Javadoc.
By default all notifications fade out in 6 seconds, but this can be overridden by setting a custom timeout in milliseconds.
Gritter.notification().withTitle("ZK Gritter demo").withText(LOREM_IPSUM).
withTime(500).show();
You can also add sticky notifications that don’t fade out at all unless the user closes them or they are removed programmatically.
Gritter.notification().withTitle("ZK Gritter demo").withText(LOREM_IPSUM).
withSticky(true).show();
All visible notifications can be cleared manually. Calling removeAll removes both normal and sticky notifications.
Gritter.removeAll();
The sclass parameter can be used to set a custom CSS class.
<style>
.gritter-red .gritter-top {
background-image: url(gritter-red.png);
}
.gritter-red .gritter-item {
background-image: url(gritter-red.png);
}
.gritter-red .gritter-bottom {
background-image: url(gritter-red.png);
}
</style>
Gritter.notification().withTitle("ZK Gritter demo").withText(LOREM_IPSUM).
withSclass("gritter-red").show();
Notifications can also include an optional 48x48px image.
Java code:
Gritter.notification().withTitle("ZK Gritter demo").withText(LOREM_IPSUM).
withImage("/warning.png").show();
In part 1 I showed how server push and threads can be used to execute background tasks in a ZK application. However, the simple example had a major flaw that makes it a bad approach for real-world applications: it starts a new thread for each background task.
JDK5 introduced the ExecutorService class, which abstracts away the threading details, and gives us a nice interface which can be used to submit tasks for background processing.
In this blog post I will describe the most important parts of creating a ZK app, which contains a background task that takes a string, and returns it in uppercase. The complete sample project is available at Github:
https://github.com/Gekkio/blog/tree/master/2012/10/async-zk-part-2
First we need an ExecutorService that we can use in our ZK code. In most cases we want a shared singleton instance, which could be configured and managed by dependency injection (e.g. Spring). It is very important to make sure that the ExecutorService is created only once, and it’s shut down properly with the application.
In this sample project I will use a simple holder class, which manages the lifecycle of a single statically available ExecutorService instance. This holder must be configured as a listener in zk.xml.
package sample;
import java.util.concurrent.ExecutorService;
import java.util.concurrent.Executors;
import org.zkoss.zk.ui.WebApp;
import org.zkoss.zk.ui.util.WebAppCleanup;
import org.zkoss.zk.ui.util.WebAppInit;
public class SampleExecutorHolder implements WebAppInit, WebAppCleanup {
private static volatile ExecutorService executor;
public static ExecutorService getExecutor() {
return executor;
}
@Override
public void cleanup(WebApp wapp) throws Exception {
if (executor != null) {
executor.shutdown();
System.out.println("ExecutorService shut down");
}
}
@Override
public void init(WebApp wapp) throws Exception {
executor = Executors.newFixedThreadPool(Runtime.getRuntime().availableProcessors());
System.out.println("Initialized an ExecutorService");
}
}
Note that the thread pool is configured using a fixed size based on processors in the system. Proper thread pool sizing is very important, and depends on the type of tasks you intend to execute. The maximum number of threads is also the maximum amount of simultaneous concurrent tasks!
We’ll use ZK server push to communicate the task results back to the UI, so the results must be modeled as ZK events. It’s always a good idea to create custom subclasses of Event instead of adding the results in the data parameter, because a custom class is more typesafe and can supports multiple fields.
The first event class represents a status update that is sent while the task is still running. In this example it will contain the amount of characters in the input string.
package sample;
import org.zkoss.zk.ui.event.Event;
public class FirstStepEvent extends Event {
public final int amountOfCharacters;
public FirstStepEvent(int amountOfCharacters) {
super("onFirstStepCompleted", null);
this.amountOfCharacters = amountOfCharacters;
}
}
The second event class represents the fully completed task. In this example it contains the input string in upper case.
package sample;
import org.zkoss.zk.ui.event.Event;
public class SecondStepEvent extends Event {
public final String upperCaseResult;
public SecondStepEvent(String upperCaseResult) {
super("onSecondStepCompleted", null);
this.upperCaseResult = upperCaseResult;
}
}
The task class should have the following characteristics:
In this example the only input data is a string that will be used to compute the task results.
package sample;
import java.util.Locale;
import org.zkoss.zk.ui.Desktop;
import org.zkoss.zk.ui.DesktopUnavailableException;
import org.zkoss.zk.ui.Executions;
import org.zkoss.zk.ui.event.Event;
import org.zkoss.zk.ui.event.EventListener;
public class SampleTask implements Runnable {
private final String input;
private final Desktop desktop;
private final EventListener<Event> eventListener;
@SuppressWarnings({ "rawtypes", "unchecked" })
public SampleTask(String input, Desktop desktop, EventListener eventListener) {
this.input = input;
this.desktop = desktop;
this.eventListener = eventListener;
}
@Override
public void run() {
try {
// Step 1
Thread.sleep(10000);
Executions.schedule(desktop, eventListener, new FirstStepEvent(input.length()));
// Step 2
Thread.sleep(10000);
Executions.schedule(desktop, eventListener, new SecondStepEvent(input.toUpperCase(Locale.ENGLISH)));
} catch (DesktopUnavailableException e) {
System.err.println("Desktop is no longer available: " + desktop);
} catch (InterruptedException e) {
}
}
}
Note how all the constructor arguments are stored in private final fields, and how the input data is immutable (Strings are immutable in Java!). The task simulates long-running processing by using Thread.sleep, and submits a status event when the “processing” is half done.
Using the task in composers is very simple. You only need to enable server push, and submit a new task instance to the executor. This automatically starts the task once a free background thread is available.
desktop.enableServerPush(true); // Get the executor from somewhere executor = SampleExecutorHolder.getExecutor(); executor.execute(new SampleTask(input.getValue(), desktop, this));
In this sample the composer extends GenericForwardComposer, which implements EventListener, so it can itself handle the resulting task events. Both events are handled by methods that update the UI with status information.
public void onFirstStepCompleted(FirstStepEvent event) {
status.setValue("Task running: " + event.amountOfCharacters + " characters in input");
}
public void onSecondStepCompleted(SecondStepEvent event) {
status.setValue("Task finished: " + event.upperCaseResult);
}
It’s quite easy to add robust support for long-running tasks in a ZK application by using this technique. The resulting code in ZK composers is very simple, because the results are passed using the typical Event/EventListener paradigm that is very common within ZK apps.
The biggest dangers in this technique are thread-safety bugs, which can be very difficult to debug. It is absolutely crucial to fully understand the threads where every piece of code is executed, and ensure that all shared state is fully thread-safe. Using immutable input data, and immutable output events is usually enough to ensure safety as long as the background task itself doesn’t access other non-thread-safe resources. Some common mistakes are:
This is not a “pitfall” per se, but an implementation detail worth knowing. Let’s say I have a inner class with a field. Such a field is visible to the enclosing class, but which one of the following ways is the fastest way to access it? Note! I’m only looking here at the generated bytecode, and not considering any JIT optimizations, so this “performance analysis” is very naïve
public class Test {
public void testAlternatives() {
// Alternative 1
System.out.println(new Inner().field);
// Alternative 2
System.out.println(new Inner().getField());
// Alternative 3
System.out.println(new Inner2().field);
// Alternative 4
System.out.println(new Inner2().getField());
}
class Inner {
private int field;
public int getField() {
return field;
}
}
class Inner2 {
int field;
public int getField() {
return field;
}
}
}
An intuitive answer is that alternatives 1 and 3 are equally fast because the field is always visible to the enclosing class, and both use field access which is overall slightly faster than method access used in alternatives 2 and 4. However, there’s an implementation detail that causes this to be untrue. The JVM itself does not have a concept called “inner classes”. The whole concept is implemented by the Java compiler and in the bytecode level everything consists of normal classes.
The issue here is that if the inner class has a private field, and the compiler will eventually compile the inner class as a normal class. A private field in a normal class cannot be accessed by other classes, so the enclosing Test class cannot “see” the field without some tricks. Here’s the above code “desugared” to what the compiler actually compiles to bytecode:
public class Test {
public void testAlternatives() {
// Alternative 1
System.out.println(Test$Inner.access$000(new Test$Inner(this)));
// Alternative 2
System.out.println(new Test$Inner(this).getField());
// Alternative 3
System.out.println(new Test$Inner2(this).field);
// Alternative 4
System.out.println(new Test$Inner2(this).getField());
}
}
class Test$Inner {
final Test this$0;
private int field;
Test$Inner(Test test) {
this$0 = test;
}
public int getField() {
return field;
}
static int access$000(Test$Inner inner) {
return inner.field;
}
}
class Test$Inner2 {
final Test this$0;
int field;
Test$Inner2(Test test) {
this$0 = test;
}
public int getField() {
return field;
}
}
As you can see, a package-level static accessor method called access$000 is generated in order to grant access to the private field. Now it’s easier to see that alternative 3 will most likely be the fastest one, because it is the only one that uses direct field access. Using package access in fields is a micro-optimization, but this whole thing is definitely a detail that should be known by Java developers. In performance-critical parts of code it might actually matter, and the Android performance guide actually mentions this implementation detail.
This implementation detail may also cause slight confusion when field access is attempted on a null reference of the inner class. Consider the following code:
public class NullTest {
class Inner {
private int field;
}
public void test() {
Inner inner = null;
System.out.println(inner.field);
}
public static void main(String[] args) {
new NullTest().test();
}
}
The variable “inner” is null, so a NullPointerException is obviously thrown. However, what is not apparent from the original code is that the exception is thrown inside the compiler-generated static accessor method!
$ java NullTest Exception in thread "main" java.lang.NullPointerException at NullTest$Inner.access$000(NullTest.java:2) at NullTest.test(NullTest.java:8) at NullTest.main(NullTest.java:12)
The stack trace contains the intuitive exception source (line 8), but the real source will confuse developers who don’t know about compiler-generated accessor methods.
Asynchronous UI updates are very useful, because they typically improve the responsiveness, usability and the general feel of user interfaces. I’ll be focusing here on the ZK framework, but generally the same principles apply for desktop UIs too (Swing, SWT).
Sometimes you might have a database query, or an external web service call that takes a long time. Typically these jobs are synchronous, so basically there is a specific point in the code where the system will have to wait for a result and will block the thread that runs the code. If you end up running code like that in an UI thread, it will usually block the UI completely.
Sometimes you don’t know in advance the exact time when something in the UI should be updated. For example, you could have a visual meter that shows the amount of users in an application. When a new user enters the application, the UIs of the current users should be updated as soon as possible to reflect the new user count. You could use a timer-based mechanism to continuously check if the amount of users has changed, but if there’s too many simultaneous users, the continuous checking will cause a very heavy load even if there is nothing to actually update in the UIs.
Let’s first digest the title of this blog post: “Asyncronous UI updates and background processing”
In the long-running processing use case the most obvious way to reduce UI blocking is to move expensive processing from the UI threads to some background threads. It’s very important to be able to understand what kind of thread will run the code in different parts of your application. For example, in ZK applications, most code is executed by servlet threads which are basically servlet world equivalents to UI threads. In order to execute code in some background thread, we’ll need a thread pool. The easiest way is to use java.util.concurrent.ExecutorService that was introduced in JDK5. We can push Runnable objects to the ExecutorService, so we are basically asking the ExecutorService to run a specific block of code in some background thread.
It is absolutely crucial to understand that frameworks that use ThreadLocals will have problems with this approach because the ThreadLocals that are set in the servlet thread will not be visible in the background thread. An example is Spring Security which by default uses a ThreadLocal to store the security context (= user identity + other things).
What does an asynchronous UI update mean in this context? Basically the idea is that once we have some information that we’d like to present in the UI, we’ll inform the UI of the new data (= asynchronous) instead of directly updating the UI in the background thread (= synchronous). We cannot know in advance when the new information is available, so we cannot ask for the information from the client side (unless we use polling which is expensive).
With ZK we have basically two different approaches we can use to update the UI once a background thread has new information. The name “server push” comes from the fact that the server has some new data that has to be pushed to the client instead of the typical workflow (client asks the server for information). Firstly, you can do synchronous updates by grabbing exclusive access to a desktop by using Executions.activate/deactivate. Personally I discourage this because once you have exclusive access, UI threads will have to wait until you deactivate the desktop. That’s why I won’t cover this method at all in this blog post.
On the other hand, asynchronous updates are done by using Executions.schedule, which conforms to the Event/EventListener model of normal event processing. The idea is that we can push normal ZK Event objects to EventListeners, and the client side will be informed of these events. After that ZK does a normal AJAX request using Javascript and the Events will be processed by the EventListeners. This means that if we use asynchronous updates, all actual event processing will be done by servlet threads and all ThreadLocals are available as usual. This makes the programming model very simple, because you need to only have normal event listener methods without complex concurrent programming.
Here’s a small example:
public class TestComposer extends GenericForwardComposer {
private Textbox search;
public void onClick$startButton() {
if (desktop.isServerPushEnabled()) {
desktop.enableServerPush(true);
}
final String searchString = search.getValue();
final EventListener el = this; // All GenericForwardComposers are also EventListeners
// Don't do this in a real-world application. Use thread pools instead.
Thread backgroundThread = new Thread() {
public void run() {
// In this part of code the ThreadLocals ARE NOT available
// You must NOT touch any ZK related things (e.g. components, desktops)
// If you need some information from ZK, you need to get them before this code
// For example here I've read searchString from a textbox, so I can use the searchString variable without problems
String result = ... // Retrieve the result from somewhere
Executions.schedule(desktop, el, new Event("onNewData", null, result));
}
};
backgroundThread.start();
}
public void onNewData(Event event) {
// In this part of code the ThreadLocals ARE available
String result = (String) event.getData();
// Do something with result. You can touch any ZK stuff freely, just like when a normal event is posted.
}
}
In part 2 I show you how to use JDK5 ExecutorServices to run tasks without manually creating threads. If you truly want to understand ZK server push, you should also read the relevant ZK documentation.
Many people, including Stephen Colebourne, have complained about some of the methods in the Scala collections API. A common example is the ++ operator:
// There are many variants but this is what Stephen Colebourne used as an example def ++ [B >: A, That] (that: TraversableOnce[B])(implicit bf: CanBuildFrom[List[A], B, That]) : That
Here’s an example of its use:
val first = List(1, 2, 3) val second = List(4, 5, 6) println(first ++ second) // List(1, 2, 3, 4, 5, 6)
In this blog post I’ll try to show that the perceived complexity of the definition is a necessary thing arising from several design goals. I’ll try to show code examples in Java so that the overall syntax is familiar for most people. Basically I’m trying to say that by following the following three goals you end up with the same kind of definition that Scala has (except that it cannot be represented with Java without violating any of the goals). If you feel that your grasp of Java generics is lacking or just want the TLDR version, you can skip right away to the monstrosity.
First we have a naive ImmutableList implementation that just wraps a standard Java list:
// ImmutableList.java
public class ImmutableList<A> {
private final List<A> inner;
private ImmutableList(List<A> inner) {
this.inner = inner;
}
public static ImmutableList<A> of(A value1, A value2) {
List<A> inner = new ArrayList<A>();
inner.add(value1);
inner.add(value2);
return new ImmutableList<A>(inner);
}
}
We’ll also use some data types to demonstrate design goal 3:
public interface Animal {
String getSound();
}
public class Cat implements Animal {
public String getSound() {
return "meow";
}
}
public class Dog implements Animal {
public String getSound() {
return "woof";
}
}
// ImmutableList.java
public ImmutableList<A> concat(ImmutableList<A> other) {
List<A> newInner = new ArrayList<A>();
newInner.addAll(this.inner);
newInner.addAll(other.inner);
return new ImmutableList<A>(newInner);
}
Well that was easy, right?
Nope, the implementation doesn’t support variances (return element type can be super type of T, argument element type can be sub type of T).
ImmutableList<Cat> cats = ImmutableList.of(new Cat(), new Cat()); ImmutableList<Dog> dogs = ImmutableList.of(new Dog(), new Dog()); ImmutableList<Animal> animals = cats.concat(dogs); // Will NOT compile
As far as I know, it’s not possible to make the above code compile with Java unless you drop generics (= violate goal 2). It’s possible to play with wildcards if you make it a static method instead:
// ImmutableList.java
public static <S> ImmutableList<S> concat(ImmutableList<? extends S> first, ImmutableList<? extends S> second) {
List<S> newInner = new ArrayList<S>();
newInner.addAll(first.inner);
newInner.addAll(second.inner);
return new ImmutableList<S>(newInner);
}
But a static method is a completely different beast, so let’s just ignore this problem for a moment and forget the support for variances. We are violating goal 3, but let’s just go on.
Now let’s imagine we extend our immutable collection library with another type: ImmutableSet. We want to be able to concat sets too, so we create a concat method (still violating goal 3 regarding variances):
// ImmutableSet.java public ImmutableSet<A> concat(ImmutableSet<A> other);
Now, based on goal 3 we must abstract this concat method to an interface called ImmutableCollection:
// ImmutableCollection.java
public interface ImmutableCollection<A> {
ImmutableCollection<A> concat(ImmutableCollection<A> other);
}
Looks good, right?
Nope, the concat method now returns a generic collection, and the actual type is lost. It’s very reasonable to expect this to work:
ImmutableList<Dog> dogs = ImmutableList.of(new Dog(), new Dog()); ImmutableList<Dog> moreDogs = ImmutableList.of(new Dog(), new Dog()); ImmutableList<Dog> fourDogs = dogs.concat(moreDogs); // Won't compile because concat returns ImmutableCollection
The point here is that the returned object is an ImmutableList, but at compile time we cannot abstract the method in ImmutableCollection AND preserve the return type. We can of course cast the return value but we’ll violate goal 3.
We need a way to describe the implementation type in the interface:
// ImmutableCollection.java
<THAT extends ImmutableCollection<A>> THAT concat(ImmutableCollection<A> other);
// ImmutableList.java
public <THAT extends ImmutableCollection<A>> THAT concat(ImmutableCollection<A> other) {
// ...
return new ImmutableList<A>(newInner); // Won't compile!!
}
Now the interface compiles and the dog example works, but the implementation of concat will not compile anymore. The problem is that the implementation of concat must support all ImmutableCollections while the implementation is providing only a subtype (= ImmutableList).
We must somehow abstract away the construction of the new collection:
// ImmutableBuilder.java
public interface ImmutableBuilder<THAT> {
THAT build(Collection elements);
}
I’ve violated goal 2 and dropped generics from elements in advance because I know they won’t work. An ImmutableBuilder is just a factory that knows how to create objects of type THAT from a collection of elements. Now we’ll change the signatures of both the interface and the implementation:
// ImmutableCollection.java
<THAT> THAT concat(ImmutableCollection<A> other, ImmutableBuilder<THAT> builder);
// ImmutableList.java
public <THAT> THAT concat(ImmutableCollection<A> other, ImmutableBuilder<THAT> builder) {
List<A> inner = // ...
return builder.build(inner);
}
Everything compiles now, so now we only need an implementation of a builder:
// ImmutableList.java
public static <T> ImmutableBuilder<ImmutableList<T>> builder() {
return new ImmutableBuilder<ImmutableList<T>>() {
public ImmutableList<T> build(Collection elements) {
return new ImmutableList<T>(new ArrayList<T>(elements));
}
};
}
We now have everything in place for our immutable collection API. On our journey we have violated goals 2 and 3 (due to language limitations) and added complexity to our implementation. However, the complexity cannot be avoided without violating the design goals. Our API is also pretty clunky to use:
// ImmutableCollection.java <THAT> THAT concat(ImmutableCollection<A> other, ImmutableBuilder<THAT> builder);
ImmutableBuilder<ImmutableList<Dog>> listBuilder = ImmutableList.builder(); ImmutableList<Dog> dogs = ImmutableList.of(new Dog(), new Dog()); ImmutableList<Dog> moreDogs = ImmutableList.of(new Dog(), new Dog()); ImmutableList<Dog> fourDogs = dogs.concat(moreDogs, listBuilder);
We don’t support variances and we have to pass around a builder for most of the operations. Due to goal 1, most interesting operations on the collections will return new ones, and thus will need a builder instance!
Stephen Colebourne wrote about ++ in his blog post:
“In fact this is the equivalent to Java’s addAll() on a list”
Reading this made me completely lose my respect to the guy. This is absolutely wrong and misses completely the crucial difference: immutability (= goal 1). Java’s addAll() doesn’t return a new collection, so it does not need ImmutableBuilder and variances cause less problems because there is no return type. However, Java collections are generally not immutable and thus violate goal 1. It is a completely different thing if you want mutable collections, but then you would have completely different requirements and you are not talking about Scala’s ++ operator anymore. If you want OOP-compatible, immutable, type-safe collections, you will end up with something that Scala has. That is why I consider complexity arising from goal 1 to be necessary. It’s also worth nothing that you don’t always have to understand the exact details of a method signature, and in the collections API the CanBuildFrom stuff is pretty much same everywhere.
Java:
<THAT> THAT concat(ImmutableCollection<A> other, ImmutableBuilder<THAT> builder);
Scala:
def ++ [B >: A, That] (that: TraversableOnce[B])(implicit bf: CanBuildFrom[List[A], B, That]) : That
First thing you should note is that they are not actually equivalent. The Scala version does not violate any goal, but the Java version violates goals 2 and 3. Let’s look at all the type parameters we have here:
The next thing you should note is CanBuildFrom in the Scala version. CanBuildFrom[List[A], B, That] is a factory object that can create objects with type That, element type B from Lists of element type A. Sounds complex, but it’s not that difficult to understand. Our Java version is simpler (no A/B type parameters), but it violates our design goals. The presence of parameters B and That in the Scala version makes my previous dog/cat example possible and if you run that with Scala you will get a list of animals.
The CanBuildFrom parameter in the Scala version is implicit, meaning that it will automatically be added by the compiler to invocations based on the import scoping if possible. So 99% of the time you will not need to actually handle the parameter yourself. In the Java version you have to include the builder parameter all the time. I really have trouble understanding the fear of implicits. Many things that would be implicits in good Scala code are typically pushed to static variables or ThreadLocals in Java (this is of course not the case with the collections API).
Finally I must also mention that many people complain the use of operators instead of named methods. Personally I have no problem with this as long at it is not overused. The ++ operator is probably based on Haskell where list concat is done with that operator.
I’d also like to ask why don’t the complainers complain about other operators? The trivial answer is of course that most operators like +, – are based on mathematics and as such are “common knowledge”. But what about operators like modulo (% in some languages, mod in others)? What about the power operator (^, ^^ or **)? I don’t see many Python programmers crying about ** even though the syntax is not based on mathematics directly.
On the other hand, good syntax is always a matter of taste. I like the fact that for example scalaz has both named and operator versions of most important methods.
It doesn’t matter whether you use XML or Java config, a Spring scope is roughly like a Map<String, Object> structure. This means that you cannot have two objects with the same name. Why is this a bad thing? If you have a large application with lots of @Configuration classes or XML files, it’s very easy to accidentally use the same name twice.
The worst part of this is that using the same with several objects, they silently override each other until only one actually remains in the ApplicationContext. These objects can also be of different types and the declaration order is what really determines which object wins. The problem here is that if you want to make reusable modules based on Spring, you will basically be forced to use a prefix in the name or something else to ensure you won’t have a name clash.
A Guice scope is basically like a Map<Class<?>, Object> structure. This means that you cannot have two objects of the same type without using extra metadata (e.g. qualifiers). This design choice has different pros and cons, but overall I think it’s the saner one. If you create reusable modules, you mostly have to make sure that you don’t export any objects of common types (e.g. String). With type-based scopes you can always create a wrapped class for common types, while with name-based scopes you would always have to use unique names based on lucky guesses. Guice also has PrivateModules so you can use Guice for all injection, but only export some of the objects in the scope.
Here’s a naive example of a Spring application that breaks runtime because of silent bean overriding.
This class instantiates the application context, registers the configuration classes and tries to get a MyBean from the context.
package springbreak;
import org.springframework.context.annotation.AnnotationConfigApplicationContext;
public class Main {
public static void main(String[] args) {
AnnotationConfigApplicationContext ctx = new AnnotationConfigApplicationContext();
ctx.register(GoodConfig.class);
ctx.register(EvilConfig.class);
ctx.refresh();
ctx.start();
System.out.println(ctx.getBean(MyBean.class).getValue());
ctx.stop();
}
}
This is just an example type of bean that we expect to get from the application context.
package springbreak;
public interface MyBean {
String getValue();
}
This is a configuration class that exports a MyBean
package springbreak;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
@Configuration
public class GoodConfig {
private static class MyBeanImpl implements MyBean {
public String getValue() {
return "I'm a bean";
}
}
@Bean
public MyBean myBean() {
return new MyBeanImpl();
}
}
This configuration class exports a String with the name myBean. It’s not a very realistic example but shows the basic idea.
package springbreak;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
@Configuration
public class EvilConfig {
@Bean
public String myBean() {
return "I'm a string!";
}
}
Can you guess what happens when you run the example? Here’s the basic idea:
So, basically a MyBeanImpl is replaced by a String and there won’t be a bean that implements MyBean. The worst part is that if you reverse the @Configuration class registration order, the code will work because then a String will be replaced by a MyBeanImpl. Now, imagine you have 20 nicely encapsulated modules with potentially conflicting names…I’ve banged my head against the wall several times trying to debug problems in a situation like that.
Spring (as of version 3.0.6) offers no possibility to alter the naming of @Configuration class exported beans. If you want to create safely reusable modules, you will have to use some kind of fully qualified names in the methods that export beans (e.g goodConfigMyBean, evilConfigMyBean).
I like Spring (especially non-DI-container parts), but in new projects I will refuse to use a library that is so fundamentally broken. And yes, using the same name twice is a developer error, but any library that is prone to such errors can be considered worse than an alternative that attempts to minimize them.
I’ve finally managed to convert sbt-jrebel-plugin to SBT 0.9+. Check out the short release notes at implicit.ly.
I guess it’s time to start converting SBT 0.7 projects to 0.11…
As I mentioned in my previous post, ZK has a tendency to “just work”. The overall technical quality is impressive and on par with most Java web frameworks, but I believe there are some parts of ZK that are less impressive.
ZK is built with Java 1.4, which greatly limits the flexibility of their API and internal code quality
Personally I’m not a fan of annotation-heavy frameworks because annotations are an extralinquistic feature and usually you end up annotations with string-based values that have no type safety. However, I know that some people would be overjoyed to have an API based on them.
There are many places in the ZK API where proper enums would be much better than the hacks that are used at the moment. The worst offender is Messagebox. Just look at this signature:
public static int show(String message,
String title,
int buttons,
java.lang.String icon,
int focus)
Ugh..the magic integers remind me of SWT (which is a great library with an awful API). Let’s imagine an alternative version with enums and generics:
public static Messagebox.Button show(String message,
String title,
Set<Messagebox.Button> buttons,
Messagebox.Icon icon,
Messagebox.Button focus)
Much, much better and more typesafe. No more bitwise OR magic. I could code this in 10 minutes into ZK if it would use Java 1.5.
This is the worst part of being stuck on Java 1.4.
I’ll just list some of the places where I’d like to see generics:
Example in org.zkoss.zk.ui.util.Initiator:
void doInit(Page page, Map args);
vs
void doInit(Page page, Map<String, Object> args);
Example in org.zkoss.zk.ui.Component:
List getChildren();
vs
List<Component> getChildren();
Example in ListModel:
public interface ListModel {
...
Object getElementAt(int index);
...
}
vs
public interface ListModel<T> {
...
T getElementAt(int index);
...
}
All ListModel* classes should also be generic (most extend java.util.Collection).
public interface EventListener {
public void onEvent(Event event);
}
vs
public interface EventListener<T extends Event> {
public void onEvent(T event);
}
public class GenericAutowireComposer {
protected Component self;
...
}
vs
public class GenericAutowireComposer<T extends Component> {
protected T self;
...
}
Example in org.zkoss.zul.RowRenderer:
public interface RowRenderer {
void render(Row row, Object data);
}
vs
public interface RowRenderer<T> {
void render(Row row, T data);
}
The default PollingServerPush has latency and will absolutely kill your application server if there are many active users. CometServerPush is better, but it does not use non-blocking IO and will block servlet threads in your servlet container. Let’s put this into perspective:
Tomcat 7.0 default configuration sets connector max threads to 200. This means that if you have 200 comet-enabled desktops, Tomcat will stop responding to other requests because all the threads are in use by comet. If the implementation used Servlet 3.0 or container-specific async APIs instead, you could run Tomcat even with one thread. It would of course be slow but it would not stop working!
Also, CometServerPush requires ZK EE so regular users are stuck with PollingServerPush. I’d say that’s a pretty big limitation considering how server push is marketed. However, it’s not surprising: proper non-blocking comet is hard to implement and requires non-blocking components in all parts of the pathway from the browser to the servlet code.
I don’t like zscript. It might have been a good feature many years ago, but I believe that today it should not be used at all. Why, oh why would someone want to replace typesafe compiled Java code with non-typechecked zscript mixed with ZUL templates?
So, if you put “Java code” (=BeanShell code) in zscript, you might want to rethink that.
Many useful features rely on reflection, which limits what things the compiler can check for you. This is very typical thing in many Java libraries/frameworks, so it’s not really a ZK-specific thing. As a Scala user I can see how the limitations of Java have guided most frameworks to the path of reflection/annotations. Reflection cannot always be avoided but I think it’s a bad sign if most of the useful features rely on reflection. Here are some features in ZK that use reflection:
I’ve been asked several times to present some of my opinions about ZK. So, based of my experience of 4 years as a ZK user, here’s some thoughts:
Most of the stuff that ZK offers works very well, and the functionality is usually very intuitive to use if you have developed any desktop Java applications before. In 2007 I did a comparison of RIA technologies that included Echo2, ZK, GWT, OpenLaszlo and Flex. Echo2 and OpenLaszlo felt incomplete and buggy and didn’t seem to have proper Maven artifacts anywhere. GWT seemed more of a technical experiment than a good platform to build on. Flex was dropped because some important Maven artifacts were missing and Flash was an unrealistic requirement for the application. On the other hand, ZK felt the most “natural” and I was able to quickly get productive with it. During my 4 year long journey with ZK, I’ve gotten plenty of those “wow” moments when I’ve learned more and more of ZK and improved my architectural understanding of the framework.
Nowadays I’ve got a pretty good understanding of what in ZK works, what doesn’t, and what has problems and what doesn’t. But still, after gaining all this good and bad insight, I consider ZK to be a very impressive product out of the box. The downside of this is of course the fact that the framework hides a lot of things from newcomers in order to be easy to use, and some of these things will bite you later on, especially if your application has lots of users.
ZK is very flexible and has plenty of integrations. Do you want use declarative markup to build component trees? Use ZUL files. Do you want to stick to plain Java? Use richlets. You can also integrate JSP, JSF, Spring, and use plenty of languages in zscript. The core framework is also pretty flexible and you can override a lot of stuff if you run into problems.
The downside is that there are very many ways of doing things correctly, and even more ways of screwing up. Flexibility itself is not a negative point, but I think that the ZK documentation doesn’t guide users enough towards the best practices of ZK. What are the best practices anyway? Many tutorials use zscript, but the docs also recommend to avoid it due to performance reasons.
I think that the ZK forum is one of the best places to learn about ZK. It’s pretty active and the threads vary from beginner level to deep technical stuff. I read the forums myself almost every day and sometimes help people with their problems. There’s one thing that troubles me a bit: the English language in the forums isn’t usually very good and people often ask too broad questions. I know, it’s not fair to criticize the writings of non-native English speakers, especially when I’m not a native speaker myself. Regardless, I think that such a barrier exists. For example, take 5 random threads from the ZK forum and Spring Web forum. The threads in the Spring forums are typically more detailed and focused instead of “I’m a newbie and I need to create application x with tons of features, please tell me how to do everything”-type threads you see in the ZK forums and people clearly spend some time formulating good and detailed questions. You’ll see that you have to spend a bit more time in the ZK forum in order to understand the threads. It’s not anybody’s fault or anything, nor a bad thing, this is just an observation. Unfortunately for me it means that some of my limited time I have for the ZK community is spent just trying to understand what people are saying. Usually I answer a thread only when I know the answer right away, or if the thread concerns some deep technical stuff.
In the past the ZK documentation was scattered, out of date and some of the more important stuff was completely missing. In the recent years the docs have improved a lot, and there’s now separate comprehensive references for ZK configuration, client-side ZK, and styling. I think the documentation is today very good, and most basic questions can be easily answered by reading the docs.
Up next: Thoughts about the ZK Web Framework: Technical stuff