Sunday, 28 October 2012

Having this opportunity to get myself prepared for coming presentation on AGH university (first lecture on 6.11.2012, event) I have prepared a small article about Event sourcing, Command Query Responsibility Segregation and LMAX architecture (Disruptor pattern). This is the summary of many articles and presentations I could find on the web. Enjoy reading :)

Full version of the article you can find here...

Wednesday, 19 September 2012

Good Java Memory Model presentation

Want to know something more about new Java Memory Model (JSR 133) and you are soooo lazy to read?

Just watch this...

What new HTML5 Web Workers Can and Can’t Do...

Workers don’t have access to the DOM of the “parent” page. They can’t access any of
the following:

• The window object
• The document object
• The parent object
• They can’t use JavaScript libraries that depend on these objects to work, like jQuery.

Web Workers can access only a limited set of JavaScript’s features because of their
multi-threaded nature. Here is the set of features they can use:

• The navigator object
• The location object (read-only)
• The XMLHttpRequest function
• The atob() and btoa() functions for converting Base 64 ASCII to and from binary
• setTimeout() / clearTimeout() and setInterval() / clearInterval()
• dump()
• The application cache
• External scripts using the importScripts() method
• Spawning other Web Workers4

New Java 7 Classloader locking

Java 7 has improved the use of class loaders by modifying the locking mechanism to avoid
deadlocks. In multi-threaded custom class loaders prior to Java 7, certain custom class
loaders were prone to deadlocks, when they used a cyclic delegation model.

Consider the following scenario. Thread1 tries to use a ClassLoader1 (locking ClassLoader1)
to load class1. It then delegates the loading of class2 to ClassLoader2. At the same time,
Thread2 uses ClassLoader2 (locking ClassLoader2) to load class3, and then delegates the
loading of class4 to ClassLoader1. Since both class loaders are locked and both the threads
need both loaders, a deadlock situation occurs.

The desired behavior of a concurrent class loader is to load different classes from the same
instance of the class loader concurrently. This requires locking at a finer level of granularity,
such as locking a class loader by the name of the class being loaded.

Synchronization should not be done at the class loader level. Instead, a lock should be made
on a class level, where the class loader allows only a single instance of the class to be loaded
at a time by that class loader.

Some class loaders are capable of loading classes concurrently. This type of class loader is
called parallel capable class loaders. They are required to register themselves during their
initialization process using the registerAsParallelCapable method.

Tuesday, 18 September 2012

Old Java Memory Model

The Java memory model describes how threads in the Java programming language interact through memory. Together with the description of single-threaded execution of code, the memory model provides the semantics of the Java programming language...

See the full article here ...

Build your own JBoss AS 5.1.2

Do you want to build your own distribution of JBoss application server 5.1.x using SVN repository???

If yes...this article will be very helpfull!!!

Get it here ...

Project Lombok: Put an End to Java Ceremony

Thing I am gonna' show is open-source library code-name Lombok.

Lombok is really two things: a compile-time code generator and a development-time code generator.
Basically, Lombok integrates directly into the Eclipse compilation cycle (by manipulating the abstract syntax tree of your code as you type) and generates code immediately based on annotations. The generated code is visible to all other classes instantly.

See the full article here ...