"Expensive perfumes come in small bottles" they say.
λ-programming is the new top feature of Java 8 the one that will mostly change the way Java programmers program. While other books on the topic go into describing the new API providing simple examples, Maurice's book follows a more pragmatic way, describing "Best practices for Using Lambda expressions and Streams". The book tackles difficult topics and doesn't provide simple examples to just demonstrate the API usage like other books do. The author tries to introduce the reader on the new way of thinking in a functional way by using his experience in solving complex problems. E.g. he writes an implementation of the UNIX grep command using lambdas and explains how to do it and what errors one has to tackle to achieve their target. He also devotes a whole chapter on streams' performance. He explains the difference between static, bound and unbound instance method references as well as how overloading works. And many more practical problems that someone might come up with while using lambdas and streams.
In more detail:
In Chapter 1 Maurice lays the pillars for the reasoning about these new Java 8 features that will analyse in the rest of his book:

from internal to external iteration

from collections to streams

from sequential to parallel

He goes into the details of explaining the reasoning behind the design solutions and selected syntax of the above topics convincing the reader of how naturally these changes were introduced into the language.Chapter 2 is devoted to lambda expressions. It compares lambdas to anonymous inner classes, he talks about variable capture (a.k.a. closures), and moves on to functional interfaces. The sub-chapters are as concise as they should be. He explains the difference between static, bound and unbound instance method references (do you know the difference?) and ends up with (function) type checking and the rules of overloading resolution (both with lambda expressions and method references).Chapter 3 provides an introduction to streams by comparing them to pipelines. He describes how to start a stream (pipeline), how to transform it (e.g. filtering, mapping, sorting, truncating etc.) and how to end it (e.g. reduce, collect, search etc.). He touches parallelism and debugging. He provides useful and pragmatic examples.Chapter 4 talks about how to end streams, i.e. about reductions and collections. He also goes into the pain of explaining how to write your own collector. Everything is explained with diagrams on how they work as well as with working examples.Chapter 5 talks about how to create streams, i.e. sources and spliterators. Here he introduces the worked example of a recursive grep command. Chapter 6 tackles stream performance. He uses jmh to microbenchmark sequential and parallel streams, sorting, distinct, spliterators, collectors etc. Parallel streams aren't always faster than sequential streams but they must satisfy some conditions to perform better.Chapter 7, finally, talks about how default methods allow the API to evolve keeping backwards compatibility at the same time.
Small and to the point, all in all a very useful book on the subject, one that you 'll revisit again and again while programming with the new lambdas and stream APIs in Java 8.
Maurice Naftalin is the author of another famous book "Java Generics and Collections" and maintains the lambda FAQ from which he has gained a long experience about the new API. His new book should be under the pillow of every Java developer.

The answer is no. It throws a ConcurrentModificationException. But why? We do have 'secured' our alerts list to be a synchronizedList.

...
...
...
...
...
...
...
...
...

The problem is that while one thread accesses the alerts list, another thread may modify the list. So how can we solve the ConcurrentModificationException?private final List<Alert> alerts = new CopyOnWriteArrayList<>());This creates a copy of your list on each modification of its elements. If you don't store many elements to your list you shouldn't worry about performance. Most developers will go away with this change and they are done. Our class is not fully thread safe though. The other lists used inside some of its methods are not thread safe. So either you also make them CopyOnWriteArrayLists or use the synchronized block as shown below.

Παρασκευή, 21 Ιουνίου 2013

While there are a number of frameworks for web development (JEE, Spring etc.) that provide Off-The-Shelf design guidelines to help developers structuring their code, standalone (desktop) applications lack one. It is unfortunate to see even very good developers having difficulties in designing their code and creating spaghetti code.

Software design should be simple. In this blog entry we present some simple guidelines to good design. The Model-View-Controller (MVC) software architecture will be used. Even though the examples are in Java, these guidelines can be easily applied to other Object-oriented programming languages.

Software officially starts from the requirements (most of the time). You should seek for a formal document that describes what you have to do, or put them down to paper (or in electronic form). Start by identifying the domain objects; these represent entities of the real world most of the time. E.g. if you have to develop an electronic library system, then your domain objects would be: Book, Librarian, User, etc. Try to identify the attributes (fields) of each domain object, e.g. for the Book(ISBN, title, authors, pages) etc. Assuming Java as your programming language, you should create 3 packages: model, view, controller. Inside model, create a domainobjects sub-package and inside there create the domain objects as Plain Old Java Objects (POJOs) or Value Objects (VOs). These should only contain the attributes and getters/setters. They are the base of your application, the objects that hold and transfer your data. They should contain no processing logic, like e.g.extractMessageFromNetworkObject() or parseWsdl(). Think that you should be able to directly persist them to a database. This way you can populate them from different sources (database, network, web services) without any change to them.

Then you should be able to populate the domain objects with data. This is the job of a controller. It could be a controller that parses a text file, or retrieves data from a database or a SOAP message etc. Ideally, it should be a utility class with static methods and no state. It should return a VO (domain object), e.g. public static Book getBookBy(String isbn); retrieves a Book record from the database and creates and returns a BookVO out of it.

To display the book data to the UI (an HTML form, a JavaFX client etc.), the view class should call the above controller to retrieve the Book object or another controller which will prepare the data according to the wishes of the view. This controller should ideally return the required data; the view should only deal with the presentation of the data, not their processing.

Some more guidelines that enforce encapsulation and low coupling.

Avoid dependencies to attributes as much as possible; e.g. assume a method that calculates the key of Book to be used by the e-Library application as the id (could be ISBN too but too slow). This could be a private method of the Bookclass (since it is private it doesn't matter much and doesn't violate the POJO discipline). This method calculates the key based on information from ISBN, the title, the authors and the category (e.g. science, history etc.). Instead of creating a method calculateKey() that depends on the attributes isbn, title, category, authors, the method signature should be calculateKey(String isbn, String title, Category category, List authors) and you should pass the attributes as parameters to the method, where it is being called inside the Book class. If you need to refactor this method to another class, you only need to modify the callers to the method and you are done!

Try to reduce dependencies among classes. Think twice before you create a new dependency to another class and take a minute to think of the consequences. Think what could be changed in the future and what the impact will be. You should be able to easily refactor your code. Keep it simple.

Try to use design patterns but don't overdo it. Design patterns provide a clean design that most of the time can be proved a good choice for future changes of requirements. You choose which design pattern might be appropriate for your problem by its intent.

Comment your code; use javadoc and ideally a Software Architecture/Design Document. Unecessary documented code is much better than no comments at all. There you describe your intent, things for other developers to pay attention to, source (e.g. URL) of your algorithm, TODOs, the design pattern you use (or use annotations) etc. Your code is self-explanatory only to you. Not everybody thinks your way.

Δευτέρα, 3 Ιουνίου 2013

Assume you are a "lucky" guy that your Java application interfaces with a C/C++ application (e.g. a kind of server) which sends you some kind of TCP/UDP network messages you need to parse. An example such C/C++ structure is shown below:

If your C/C++ application runs on an INTEL (x86) based machine architecture, then you receive the bits as little endian (see INTEL_STYLE above), otherwise as big endian (e.g. SPARC machines). Note that the JVM is big endian, too. In the following we assume a big-endian architecture.
In this blog entry we are going to see how you can parse such a message in your receiving Java application.

What will you need?

a calculator that handles binaries, hexadecimals and decimals (Windows, Linux and MacOSX already provide such calculators. However, they don't handle decimal point numbers, so this online converter will prove useful, too).

The following table shows how the C/C++ data types correspond to Javolution Struct.

Our Message class corresponds to the C msg struct. It extends javolution.io.Struct which is an implementation of the java.nio.ByteBuffer. This crash course about Java ByteBuffer provides useful background information.

The C/C++ struct starts with a UCHAR which corresponds to Unsigned8, i.e. one byte. The numbers after the colons (:) denote how many bits inside the byte represent each field of the UCHAR. Thus, octal:3 means that 3 bits represent the octal field. This in Javolution is represented by Unsigned8(3).

UINT is represented by Unsigned32 in javolution, which is 4 bytes long.
The string char[5] is represented by UTF8String(5). float by Float32.

The first byte0x90 corresponds to the binary value 1001 0000. The first bit (1) represents bool:1, the next three (001) the octal:3, and the last four (0000) spare:4.

Be careful of the alignment! 1 byte + 3 bytes (of alignment) and the next field (uint) starts at the 5th byte and not at the 2nd as you might have expected.

The next 4 bytes correspond to the uint. The next 5 ASCII characters correspond to the string "HALLO". Again, another alignment, and then the float field. The last 4 bytes represent the Gender enum which contains the value 1, i.e. Gender.FEMALE.

Packed

However, your data might be packed, i.e. no alignment/padding is happening. To do this, you override the isPacked() method of javolution.io.Struct:public class Message extends javolution.io.Struct { ...@Override public boolean isPacked() { return true; } ...}Now your test case data should contain no padding in order to pass:

discover the unique Cretan hospitality and taste the most delicious Cretan cuisine

make friends

And as the best things on this world, it is FREE!

This year again we had some top speakers like Java Champions Heinz Kabutz, Kirk Pepperdine and Jeff Genender as well as names like Michael Hunger, Marc Hoffman, Dmitry Vyazelenko, Rabea Gransberger, just to mention a few.
Next year the conference will take place at the same place from 19th to 22nd of August 2013, so don't wait, book your tickets asap.

Back in 2011 when I worried about the outcome of the 1st UnConference, Heinz told me: "Don't worry! It will be the best conference in the world"! He was right.