tag:blogger.com,1999:blog-112001642024-03-07T21:41:03.967-05:00Nirav's ContemplationsThoughts on Programming, Software and Open Source.Nirav Thakerhttp://www.blogger.com/profile/07204297663478577248noreply@blogger.comBlogger86125tag:blogger.com,1999:blog-11200164.post-82966315580111731312015-02-10T22:44:00.000-05:002015-02-10T22:44:45.538-05:00A simple rate limiter using Java's DelayQueueIt is rare for me to develop at this level of use case but recently we had to manage a bit of work-load with limited resources that lead to a simplified and light-weight rate limiter using Java's concurrent additions.<br />
<br />
<a href="https://github.com/google/guava/blob/master/guava/src/com/google/common/util/concurrent/RateLimiter.java" target="_blank">Guava's rate limiter</a> is pretty good but I didn't want to include a (fat) dependency on guava just for one class so I wrote a variant based on Java's <a href="http://docs.oracle.com/javase/8/docs/api/java/util/concurrent/DelayQueue.html" target="_blank">DelayQueue</a>:<br />
<br />
<pre>class DelayedEntry implements Delayed {
long expireAt;
TimeUnit unit;
DelayedEntry(long delay, TimeUnit tu) {
unit = tu;
setDelay(delay);
}
void setDelay(long delay) {
this.expireAt = System.nanoTime() + unit.toNanos(delay);
}
int compareTo(Delayed other) {
throw new IllegalStateException("Expected single element queue");
}
long getDelay(TimeUnit u) {
return u.convert(expireAt - System.nanoTime(), NANOSECONDS);
}
}
class RateLimiter {
DelayQueue<DelayedEntry> queue;
DelayedEntry token;
TimeUnit rateUnit;
AtomicInteger rate;
RateLimiter(int rateLimit) {
queue = new DelayQueue<>();
rateUnit = NANOSECONDS;
rate = new AtomicInteger(rateLimit);
token = new DelayedEntry(0, NANOSECONDS);
}
boolean acquire(int permits) throws InterruptedException {
long targetDelay = rateUnit.toNanos(permits) / max(1, rate.get());
DelayedEntry nextToken = token;
while (!queue.isEmpty()) {
nextToken = queue.take();
}
assert nextToken != null;
nextToken.setDelay(targetDelay);
return queue.offer(token);
}
}</pre>This implementation isn't exactly a mathematically precise rate limiter that can shape traffic bursts in uniform distributions for volatile rate limits. However, for use-cases involving predictable timings, this works pretty well with minimal and bounded resource usage.<br />
<br />
One thing that shouldn't go un-noticed is that we can easily use such utility implementations to instrument collection interfaces such as Iterable and Iterator to decorate existing code base, here's an example:<br />
<pre> public <T> Iterator<T> decorate(final Iterator<T> delegate) {
return new Iterator<T>() {
public boolean hasNext() {
return delegate.hasNext();
}
public T next() {
acquire();
return delegate.next();
}
public void remove() {
delegate.remove();
}
};
}
</pre><br />
I would love to hear reader's opinions about this approach.Nirav Thakerhttp://www.blogger.com/profile/07204297663478577248noreply@blogger.com0tag:blogger.com,1999:blog-11200164.post-10149826500494285362014-04-29T21:48:00.002-04:002014-04-29T21:50:26.968-04:00JDK 8, Lucene and SSD based Xeon ServersRecently, I've been working on an app that involves near real-time ingestion and indexing of full twitter fire-hose on cutting-edge physical hardware. This mostly involves Lucene and home grown secret sauce analytical algorithms in pure Java.<br />
<br />
As an enthusiastic Java developer, I decided to switch run-time of this app to newly released JDK 8, because why not?<br />
<br />
This worked great with Linux on multitudes of hardware (32-bit AMD/K2 based CPU on my laptop, raspberry-pi/ARM, 64-bit Intel-I7 Desktop/Intel, 2 generations old 64-bit 2U-Xeon/Intel based server - all with spinning rust), but when I deployed the same app to our latest Xeon servers with SSD based storage I started seeing problems. The first problem I observed was on index optimization phase with insignificant index size for SSD storage (~12G). In optimization phase, the machine becomes irresponsive with ~70% system utilization with no more than 2% io-utilization. The second problem was with zero hits (i.e. no search results) on near real time Index reader, this was unique to SSD based server because when I copy the same index on other machine it would work just fine.<br />
<br />
Despite many JDK8 bugs reported by Lucene committers, it looks like there are still some hidden JIT compiler bugs lurking in corner cases when your indices are very large even with the latest <a href="http://www.oracle.com/technetwork/java/javase/downloads/jdk8-downloads-2133151.html">JDK 8</a>.<br />
<br />
The workaround that has worked (great) for me so far is to switch back to latest <a href="http://www.oracle.com/technetwork/java/javase/downloads/jdk7-downloads-1880260.html">JDK 7</a>.<br />
<br />
When your app is deployed on SSD based storage infrastructure, the bottleneck of a search app shifts from IO to CPU and you start to see these type of issues. Even after a couple of days of googling, I haven't found anyone on internet seeing this problem, so I'll conclude that this may be specific to my use-case but hopefully someone will find switching back to JDK7 useful.Nirav Thakerhttp://www.blogger.com/profile/07204297663478577248noreply@blogger.com0tag:blogger.com,1999:blog-11200164.post-51048481715116820662014-04-14T21:15:00.000-04:002014-04-14T21:15:13.725-04:00MySQL Insert performance and random primary key valuesIt's been almost a year since I've been putting up with MySQL and its bizarre performance characteristics and lack of choices on index data structures. If it wasn't for the volume and velocity of data we're storing in it, I would have proposed to ditch it by now.<br />
<br />
We use MySQL purely as a stable high performance key-value store so many might not share the frustrations. I've been bitten by poor performance of InnoDB tables with semi-random values in primary key more than once now and hopefully this post will help someone who is in similar situation.<br />
<br />
MySQL with InnoDB <b>struggles</b> with random primary key values, probably because it only supports BTree indices on it and page split cost on a BTree can be very IO intensive, I've only experienced this with numerical columns but it may be the true for other data types as well.<br />
<br />
The only solution that has worked satisfactorily for me so far is to add an AUTO INCREMENT primary key and index the other column as unique. This is a complete waste of storage space but has offered the best insert performance so far. AUTO INCREMENT with upsert (ON DUPLICATE UPDATE) is probably the only reliable and performant way of using MySQL as super fast ingestion engine.Nirav Thakerhttp://www.blogger.com/profile/07204297663478577248noreply@blogger.com0tag:blogger.com,1999:blog-11200164.post-31830678500875552902013-12-16T20:44:00.002-05:002013-12-16T20:44:09.206-05:00Interesting use-case for SynchronousQueueWhile working on a very unusual system, where: 1) <a href="http://en.wikipedia.org/wiki/Producer%E2%80%93consumer_problem">producers</a> can be significantly faster than consumers at times (by more than a factor of two) and 2) producers have low latency processing overhead for real time data, I was contemplating on a data structure that is efficient, performant and can model this situation elegantly. After researching probable candidates, I came across <a href="http://docs.oracle.com/javase/7/docs/api/java/util/concurrent/Exchanger.html">Exchanger</a>/<a href="http://docs.oracle.com/javase/7/docs/api/java/util/concurrent/SynchronousQueue.html">SynchronousQueue</a> from Java's <a href="http://docs.oracle.com/javase/6/docs/api/java/util/concurrent/package-summary.html">util.concurrent</a> class library.<br />
<br />
If I was looking at <a href="http://docs.oracle.com/javase/7/docs/api/java/util/concurrent/SynchronousQueue.html">SynchronousQueue</a> without the above context, I would have wondered why would anyone need a queue <a href="http://zeromq.org/">that's not really a queue</a> but more like a pointer swap between appropriate threads. But the use-case I'm dealing with ("event bursts") are probably the perfect use case for preventing the consumers from overwhelming rates by modeling the problem more as a "hand-off" than a typical case of buffered queuing. The central idea behind this data-structure is to adapt queue idioms without using a queue in a very efficient manner with an added<b> feature that message production is rate limited by consumer's speed of processing them</b>. Behind the scenes, it uses <a href="http://www.cs.rochester.edu/u/scott/synchronization/pseudocode/duals.html">dual-stack/queue algorithm</a> (depending on ordering fairness preference) to transfer a reference between threads.<br />
<br />
SynchronousQueue is more of a thread queue than a data queue, it maintains a stack/queue of waiter threads (i.e. "consumers") and not the queue of data itself. You can probably achieve the same functionality by using <a href="http://docs.oracle.com/javase/7/docs/api/java/util/concurrent/BlockingQueue.html">BlockingQueue</a> of size 1 or using an explicit object lock and explicit wait/notify on a datum reference like an example below:<br />
<br />
<pre>//Example code, probably riddled with concurrency bugs </pre>
<pre>//(I've only tested it on my laptop :)) </pre>
<pre>public class MyNaiveSyncQueue {
private final Object LOCK = new Object();
private volatile Object data; //volatile is needed for non compressed OOPS
public void put(Object o) throws InterruptedException{
synchronized (LOCK) {
if(data != null){
LOCK.wait();
}
data = o;
LOCK.notify();
}
}
public Object take() throws InterruptedException{
synchronized (LOCK) {
if(data == null){
LOCK.wait();
}
Object o = data;
data = null;
LOCK.notify();
return o;
}
}
}
</pre>
<br />
There are several problems with the solution above:<br />
<ul>
<li>Violent locking and memory fence overhead: for individual queue operations, this will scale terribly with number of producers/consumers, especially on server class <a href="http://en.wikipedia.org/wiki/Symmetric_multiprocessing">SMP</a> hardware.</li>
<li>Constant context switching: each successful queue operation involves syscall(s) for context switching which might involve kernel scheduler and everything that comes with it (cache flush/register reload et. al.).</li>
<li>Overhead for fair processing: JVM manages object monitor wait queues in a fixed FIFO order, there's certain overhead in seeking the first enqueued thread to schedule as a consumer. This may or may not be the behavior the programmer cares about.</li>
</ul>
SynchronousQueue takes care of all of these limitations by providing options for trade-off in terms of scheduler ordering fairness as well as eliminating expensive locking with hardware level <a href="http://en.wikipedia.org/wiki/Compare-and-swap">CAS</a> (whenever available). It also does a fair bit of <a href="http://en.wikipedia.org/wiki/Spinlock">spin-locking</a> before a kernel level timed-wait kicks-in, this ensures that context-switches don't become the hot-spots in message processing.<br />
<br />
So far this has been working great for the system I'm dealing with which processes about a <b>couple of hundred messages per millisecond</b> at peak bursts but I realize that it might not be appropriate (or even worth it) for non-realtime/non-bursty producers.<br />
<br />
<br />Nirav Thakerhttp://www.blogger.com/profile/07204297663478577248noreply@blogger.com0tag:blogger.com,1999:blog-11200164.post-91565181654688988142012-05-15T22:32:00.000-04:002012-05-17T21:53:39.510-04:00Achieving Decoupling: Dependency Injection v/s Event driven design(Update: A more exhaustive sequel post is in progress on this topic so don't be disappointed by lack of details and stay tuned) <br />
<br />
<a href="http://en.wikipedia.org/wiki/Coupling_%28computer_programming%29" target="_blank">Coupling</a> is considered to be a bad sign in a software design, having seen enough of it in practice I agree with this belief. The need for decoupling has resulted in a cottage industry of <a href="http://martinfowler.com/bliki/InversionOfControl.html" target="_blank">IoC</a> containers in Java ecosystem, where it still remains popular, so this is not a philosophical topic.<br />
<br />
When I was learning <a href="http://en.wikipedia.org/wiki/Object-oriented_programming" target="_blank">object oriented software design</a> as a student, the gist I received was encapsulation and message passing between objects with state. In theory this sounded great, objects with behavior and encapsulated state seemed unbeatable (given that I only knew <a href="http://en.wikipedia.org/wiki/BASIC" target="_blank">BASIC</a> and <a href="http://en.wikipedia.org/wiki/C_%28programming_language%29" target="_blank">C</a>). In real life, however, I have found that it is hard to keep objects simple while keeping their dependency fulcrum in control. This may not correlate in real OO programming languages like <a href="http://en.wikipedia.org/wiki/Smalltalk" target="_blank">Smalltalk</a> but I can't speak for that.<br />
<br />
Given that I've only worked on a relatively medium to larger enterprise applications (ranging from 10<a href="http://en.wikipedia.org/wiki/Source_lines_of_code" target="_blank">KLOC</a> to 1<a href="http://en.wikipedia.org/wiki/Source_lines_of_code" target="_blank">MLOC</a>+) this might sound a bit biased: <b>most enterprise applications are not object oriented</b>. This is counter intuitive given that OO approach is considered to excel at modelling large systems by breaking it down in to more manageable pieces, but I digress.<br />
<br />
Coming back to the main issue, how can we control coupling?<br />
<br />
<b><a href="http://martinfowler.com/articles/injection.html" target="_blank">Dependency Injection</a></b><br />
The most popular option so far is to exploit dependency injection to invert the dependencies. The touted benefits of it are: testability, flexibility and abstracted, and hence, switchable implementations.<br />
For example:
<br />
<pre>interface IHttp{ InputStream open(URL url); }
class <a href="http://www.mozilla.org/en-US/firefox/new/" target="_blank">FireFox</a> implements IHttp{
InputStream open(HtttpURL url){ doOpen(url).andLeakSomeMemoryAsDesigned(); }
}
class <a href="https://www.google.com/chrome" target="_blank">Chrome</a> implements IHttp{
InputStream open(HttpURL url){ feedUserInfoTo(googleAI).thenOpenUrl(url).makeItFast(); }
}
class InternetExplorer implements IHttp{
//Since no one uses it apart from downloading other browser,
// being efficient, user friendly or useful is just a misplaced goal.
InputStream open(HttpUrl url){
waitIndefinitelyOrForeverFor(url).attemptToLoadWhenever(url).possiblyReadOrJustGiveUp();
}
}
class <a href="http://maven.apache.org/" target="_blank">Maven</a>HttpClient implements IHttp{
InputStream open(HttpUrl url) {
downloadKnownInternetFiveThousandTimesEveryHour().completelyIgnoringWtfHttp()
.then()
.inflictDarkSufferingOnUserAndBeReluctantlyOpinianatedAboutHowYouScrewUpBuilds().asAlways();
}
}
class MyHappyEnterpriseApp{
IHttp http;
setBrowser(IHttp browser){this.http = http} //Injected dependency
void myBusinessLogic(){ http.open("http://blog.nirav.name").doSomething() }
}
</pre>
So by coding to interface and relying on a dependency injection "<a href="http://www.springsource.org/" target="_blank">container</a>" we get all the prescribed benefits. This is the de-facto standard to achieve decoupling in current enterprise application architecture in Java ecosystem.<br />
<br />
<b><a href="http://en.wikipedia.org/wiki/Event-driven_programming" target="_blank">Event Driver Design</a></b><br />
The second obvious alternative (may be not so obvious to many) is to fall back to good old <a href="http://en.wikipedia.org/wiki/Message_passing" target="_blank">message passing</a> which can be synchronous or async. Isn't OO approach all about message passing and keeping state <a href="http://en.wikipedia.org/wiki/Encapsulation_%28object-oriented_programming%29" target="_blank">encapsulated</a> while <a href="http://en.wikipedia.org/wiki/Reactor_pattern" target="_blank">reacting</a> to meaningful messages? Turns out, it doesn't jive well enough with statically typed languages such as Java.<br />
<br />
Instead of lethally injecting objects with dependencies (abstract or concrete) why not just send a message which will be observed by objects who are really interested in responding? The benefits here are inclusive of the ones offered by dependency injection but are more evolutionary.<br />
<br />
For example, The similar implementation of the above design can be represented as events:<br />
<pre>interface IEvent{}
interface HTTPEvents{
interface OpenUrl extends IEvent{
InputStream open(HtttpURL url);
}
}
class FireFox implements HTTPEvents.OpenUrl{
InputStream open(HtttpURL url){ doOpen(url).andLeakSomeMemoryAsDesigned(); }
}
class Eventing{
Dictionary<eventtype, ievents=""> events; //initialize implementations
T <t extends="" ievent=""> sync(<t> evt){
return events.lookupImpl(evt.getType()).send(evt);
}
}
class MyHappyEnterpriseApp{
void myBusinessLogic(){ doSomething(Eventing.sync(HTTPEvents.OpenUrl, "http://blog.nirav.name")); }
}
</t></t></eventtype,></pre>
While simplistic, this implementation should provide general idea that dependency injection is not the only true way to achieve decoupling.<br />
<br />
Even the most complex systems are designed around the idea of message passing (Linux kernel, Win API and so on) where it successfully achieves decoupling from user land API (<a href="http://en.wikipedia.org/wiki/POSIX" target="_blank">POSIX</a>) from physical implementations (e.g. CPU <a href="http://www.linuxjournal.com/article/3985" target="_blank">interrupt faults and traps</a>). This elucidates a strong merit that message passing can be applied to a general purpose applications (which are comparatively less complex). It is not a novel approach to system design but it appears that reinventing the wheel is in the fashion as far as enterprise application development goes. <a href="http://en.wikipedia.org/wiki/Java_Message_Service" target="_blank">JMS</a> has been a solid spec geared more or less towards similar principles but it is viewed only as a queueing mechanism to offload the async task.<br />
<br />
I guess not every one sees coupling from the same angle and starts to build yet another money making framework to achieve the same goal. I hope that agent driven libraries like <a href="http://akka.io/" target="_blank">Akka</a> and <a href="http://www.erlang.org/" target="_blank">Erlang</a> style message passing gets some more attention from enterprise app community to see how benefits beyond coupling (performance, fault tolerance and scalability) are achieved with message passing.Nirav Thakerhttp://www.blogger.com/profile/07204297663478577248noreply@blogger.com0tag:blogger.com,1999:blog-11200164.post-1652276669332486972012-03-05T23:17:00.000-05:002012-03-05T23:17:13.855-05:00On Static v/s Dynamic typingI've been pondering about trivialities again, I am observing how most programmers have strong vested interest in defending <a href="http://en.wikipedia.org/wiki/Type_system#Static_and_dynamic_type_checking_in_practice" target="_blank">static v/s dynamic</a> typing as if they are mutually exclusive.<br />
<br />
There're those who think static typing is the ultimate engineering solution to build reliable software and dynamic typing is some kind of a sick joke to put their lazyness to test. Then there are those who think types are for primitive minds and variable declaration is an insulting feature.<br />
<br />
At this point in time, I can relate to both groups as I've had strong opinion on this subject. Having opinion on typing is OK, I think. (having no opinion on this topic basically means google didn't work for you and you should head back). <br />
<br />
Most programmers go through, what I call, a typing evolution cycle. I started with dynamically typed language (name removed because of possible copyright violation). It was really great to stuff everything in to a variant (actually I never even bothered to declare variables!) and not worrying about compilation or runtime errors, it mostly <i><u>ran</u></i>. Then I was introduced to C (and later C++) and I remember how I hated it because I was now forced to declare variables and had to think about what I wanted computer to do upfront. It was alien to me that compiler will point out my mistakes instead of doing my bidding. During that time I was a supporter of <b>dynamic typing </b>because I was naive.<br />
<br />
As the time went by I got more used to static typing with interesting IDE features such as IntelliSense of Visual Studio. Writing correct program was much easier now and it always <i><u>worked</u></i> (mostly correctly). Then came the Java programming, everything was object (except primitives). Large projects and Eclipse JDT made me appreciate value of static typing. When I start writing test I don't think about type errors because they are taken care of, I could easily refactor code without nightmares that something could be broken. Scala's type inference and simpler type system actually boosted my faith in static typing even further. At this point in time I supported <b>static typing </b>because I was naive.<br />
<br />
This was my experience, may be it is reverse for others (starting from static typing and going back and forth).<br />
My views have changed on typing over the time. Depending on what I'm working on, I don't mind hand-waving type system (coupled with esoteric tests) for a quick isolated stab that brings a lot of benefits v/s a bloat of API to do the same in few years. While still having the confidence in my software being immune to my bad keyboard-fu and assurance that stupid mistakes will not make it all the way to production. Probably, I'm still naive.Nirav Thakerhttp://www.blogger.com/profile/07204297663478577248noreply@blogger.com2tag:blogger.com,1999:blog-11200164.post-91847609940632145052011-12-05T22:58:00.001-05:002011-12-05T23:17:04.675-05:00Avoid storing references of java.net.URLNormally, I avoid writing something so obvious but since I'm bitten multiple times now, it might help future me.<br />
<br />
Never<b> ever store</b> references of java.net.URL in Java collections. The reasoning is pretty simple, 'equals' and 'hashCode' methods of this class does extremely expensive synchronous DNS lookup on <b>every</b> call.<br />
<br />
It is not uncommon to see most of your thread's time being spent on monitors:<br />
<br />
"pool-2-thread-2" prio=10 tid=0x92061400 nid=0x1744 waiting for monitor entry [0x91fad000]<br />
java.lang.Thread.State: BLOCKED (on object monitor)<br />
at java.net.URLStreamHandler.getHostAddress(URLStreamHandler.java:429)<br />
- waiting to lock <0x9731b200> (a sun.net.www.protocol.http.Handler)<br />
at java.net.URLStreamHandler.hashCode(URLStreamHandler.java:354)<br />
at java.net.URL.hashCode(URL.java:875)<br />
- locked <0xaac87290> (a java.net.URL)<br />
at java.util.HashMap.getEntry(HashMap.java:361)<br />
at java.util.HashMap.containsKey(HashMap.java:352)<br />
at java.util.HashSet.contains(HashSet.java:201)<br />
<br />
<br />
"pool-2-thread-1" prio=10 tid=0x9205e800 nid=0x1743 runnable [0x91ffe000]<br />
java.lang.Thread.State: RUNNABLE<br />
at java.net.Inet6AddressImpl.lookupAllHostAddr(Native Method)<br />
at java.net.InetAddress$1.lookupAllHostAddr(InetAddress.java:866)<br />
at java.net.InetAddress.getAddressesFromNameService(InetAddress.java:1258)<br />
at java.net.InetAddress.getAllByName0(InetAddress.java:1211)<br />
at java.net.InetAddress.getAllByName(InetAddress.java:1127)<br />
at java.net.InetAddress.getAllByName(InetAddress.java:1063)<br />
at java.net.InetAddress.getByName(InetAddress.java:1013)<br />
at java.net.URLStreamHandler.getHostAddress(URLStreamHandler.java:437)<br />
- locked <0x9731b200> (a sun.net.www.protocol.http.Handler)<br />
at java.net.URLStreamHandler.hashCode(URLStreamHandler.java:354)<br />
at java.net.URL.hashCode(URL.java:875)<br />
- locked <0xaac97228> (a java.net.URL)<br />
at java.util.HashMap.getEntry(HashMap.java:361)<br />
at java.util.HashMap.containsKey(HashMap.java:352)<br />
at java.util.HashSet.contains(HashSet.java:201)<br />
<br />
This stack-trace just depicts hashCode but expect similar blocking code for 'equals' too. If you care a bit about performance, just stay away from this goddamned class.Nirav Thakerhttp://www.blogger.com/profile/07204297663478577248noreply@blogger.com0tag:blogger.com,1999:blog-11200164.post-62966652260418104732011-11-24T21:25:00.001-05:002012-02-13T20:35:39.417-05:00Optimizing string memory footprint in Java - Part 1This is first in a series of blog posts where I will try to describe my miserable attempts at storing large amount of strings to build efficient spell correction and auto-suggest facility in Java. I learned some important lessons doing this and it will be a waste if I didn't share it. So here it goes..<br />
<br />
In order to efficiently store large amount of strings, we first need to understand how JVM stores string objects in memory. In this post I will try to summarize memory layout of String object.<br />
<br />
Each object in JVM has fixed, unavoidable structural overhead called object header that JVM uses for various tasks such as Garbage Collection, Identification, addressing and others that I don't understand. A 32-bit HotSpot VM uses 8 bytes header per object, 64-bit HotSpot VM <a href="http://docs.oracle.com/javase/7/docs/technotes/guides/vm/performance-enhancements-7.html" target="_blank">with heap larger than 32g</a> as well as <a href="http://www.ibm.com/developerworks/java/jdk/" target="_blank">IBM's J9</a> VM takes 16 bytes per object. As always, arrays are treated differently. <a href="http://java.sun.com/docs/books/jvms/second_edition/html/Compiling.doc.html#4091" target="_blank">Array</a> is an object so it has a fixed header of its own as described above. However, since Java spec guarantees array bounds check on <a href="http://java.sun.com/docs/books/jvms/second_edition/html/VMSpecIX.fm1.html#6956334" target="_blank">every array operation</a> it has to store length of each array which is another 4 byte, making effective array header size 12 bytes instead of regular 8 for objects. And finally there's object padding in multiples of 8 or 16 bytes, depending on CPU word size and JVM to make memory to CPU communication efficient.<br />
<br />
Assuming 32-bit JVM, the <a href="http://docs.oracle.com/javase/7/docs/api/java/lang/String.html" target="_blank">java.lang.String</a> class has three bookkeeping integer fields called offset, count, hash occupying 12 bytes plus a 4 byte char array pointer and 8 byte header totaling 24 bytes fixed overhead per string. This is inefficient but slightly clever because padding is not required for string object itself making hash a free cache.<br />
<br />
Here's the formula to calculate String's shallow and deep sizes: <br />
<ul>
<li>Shallow size = HEADER + ( offset + count + hash + char array pointer) = 24 bytes</li>
<li>Retained size = Shallow size + 12 byte array header + (nchars * 2 + padding)</li>
</ul>
Where padding = ( (nchars * 2) mod word_size) is rounded off to 8/16 bytes depending on 32/64-bit JVM (Except J9) word_size.<br />
<br />
So, on a 32-bit HotSpot VM, 6 byte word "Memory" takes :<br />
24 + 12 + (6 * 2 + 4 padding) = 24 + 12 + 16 = 52 bytes<br />
<br />
That is 77% JVM imposed overhead v/s 23% actual data considering it a unicode string.<br />
<br />
One way to make string representations efficient is to amortize structural overhead by storing larger strings. To illustrate, 100 char string will be 80% data v/s 20% overhead, 200 char string will be 94.33% data v/s overhead, 500 char string will be 97.6% data v/s overhead and so on. This will be one of the key technique in reducing string's memory footprint I will write about in later blog posts. Following is a rough graph that depicts this theory.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhswGgTKKl4I09GMk4P4H6lzazxSEnHXSi_VDaPgfEl7ZeKEcPXgQooLca4eoWIL-OLuHmRPIMP3evT4Y2RDAKWArsMbZneM48imZ6aGvd1LFETiA5yG1DrHtMWeIJsIjhOXPRe4A/s1600/Efficiency+increase+with+Characters+per+string.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="240" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhswGgTKKl4I09GMk4P4H6lzazxSEnHXSi_VDaPgfEl7ZeKEcPXgQooLca4eoWIL-OLuHmRPIMP3evT4Y2RDAKWArsMbZneM48imZ6aGvd1LFETiA5yG1DrHtMWeIJsIjhOXPRe4A/s320/Efficiency+increase+with+Characters+per+string.jpg" width="320" /></a></div>
<br />
It is easy to see that storing a lot of small strings actually waste huge amount of memory which in no less part the reason why Java is considered a memory hog.<br />
<br />
That's all with the basics of understanding overhead involved with storing strings. In next blog post, I will write about various implementations I tried and general rant on Java Collections' memory efficiency.<br />
<br />Nirav Thakerhttp://www.blogger.com/profile/07204297663478577248noreply@blogger.com0tag:blogger.com,1999:blog-11200164.post-69635996704110743852011-10-24T22:25:00.001-04:002011-11-01T20:43:03.913-04:00On using "PermGen" as application level cacheI was reading an interesting article '<a href="http://marcgravell.blogspot.com/2011/10/assault-by-gc.html">Assualt by GC</a>' by <a href="http://stackexchange.com/">stack exchange</a> guy and it felt like a Déjà vu with my past couple of years of development on the JVM. It struck to me that we can definitely do better, so here it goes..<br />
<br />
Automatic <a href="http://en.wikipedia.org/wiki/Garbage_collection_(computer_science)">GC</a> is really a great step forward in software development, except when it is not. If you have deployed application on a JVM with large heap (4g+) you probably know what a long GC pause really feels like [insert familiar knock-knock joke about java]. Jokes aside, JVM's GC advancement is unprecedented. The amount of tuning you can do with different garbage collectors can define a niche profession.<br />
<br />
For most applications where GC latency isn't an issue; default garbage collector works just fine. For applications which need to scale GC can (and does) become a 'bottleneck'. If you disagree, try running a JVM under memory pressure and see app response times. It should be surprising because in most data driven applications bottleneck is usually IO or other IO bound resources (e.g. a DB). This situation generally happens when GC is completely thrashing the process because there are too many "tenured" objects which don't fit in the allocated heap or heap is fragmented and GC wastes a lot of time compacting the heap. Unlike .NET, Java folks are not very lucky with platform specific optimizations such as locking pages to prevent swapping. So it is not uncommon that a full GC causes excessive paging, making GC IO bound.<br />
<br />
Turns out that GCing large "tenured" object space is expensive compared to short lived young objects (sweep). A large population of "tenured" objects is generally a genuine requirement for long running server processes relying on large amounts of data and this requirement shouldn't really punish application with long GC pauses. While not impossible, it is not really practical to set size of tenured generation very large because it may adversely affect young generation collections. JVM GC optimization is a skill not in abundance but the problem is all too common. So what can we do about it?<br />
<br />
One way to eliminate GC on predictable "tenured" application data is to just not store it on JVM heap (i.e. use <a href="http://download.oracle.com/javase/7/docs/api/java/nio/ByteBuffer.html#allocateDirect(int)">direct byte buffer</a> etc. ). I've been watching solutions like Terracotta's <a href="http://www.terracotta.org/bigmemory">BigMemory</a> which uses similar approach to address GC issues. However all such solutions seem a mix of manual memory management with hacks to circumvent GC which end up being half-baked reinvention of JVM's copy-on-write "permgen".<br />
<br />
Most of the java developers I know consider "permgen" to be some kind of evil which causes all kinds of problems including "eclipse crashing", crying JSP/[insert other template library] compiler, unpredictable class unloading and really large interned strings which stick around. "permgen" is <a href="http://javaeesupportpatterns.blogspot.com/2011/10/java-7-features-permgen-removal.html">going</a> to <a href="http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/3582bf76420e">go away</a> from the hotspot vm, which is kind of sad because I think it could be a great way to achieve GC free heap storage for application level data (more specifically cache). This is not really possible unless "permgen" is used for one specific purpose, and if that specific purpose allows application to store its data, we can have standard supported GC free application data without the need of third party solutions which achieve the goal poorly. Even better would be <a href="http://jcp.org/en/jsr/detail?id=107">java.cache</a> using "permgen" for cache storage.<br />
<br />
One of the <a href="http://news.ycombinator.com/item?id=3150407">commenter </a>at HN talked about Smalltalk VM's way of using permgen (just send a message to object to move itself to "permgen"). I like this approach because applications can control which objects are long lived which is sensible because they have the best knowledge about long lived objects. The only similarity in JVM we have is <a href="http://download.oracle.com/javase/7/docs/api/java/lang/String.html#intern()">String.intern</a>, which unfortunately caches strings forever and it is not really as useful as having some kind of eviction control.<br />
<br />
So, what do you think about this approach?<br />
<br />Nirav Thakerhttp://www.blogger.com/profile/07204297663478577248noreply@blogger.com0tag:blogger.com,1999:blog-11200164.post-54083452938922148142011-09-06T23:24:00.000-04:002011-09-06T23:25:56.757-04:00Thoughts on Event sourcingI read about <a href="http://martinfowler.com/eaaDev/EventSourcing.html">event sourcing</a> a while back and I couldn't stop thinking about it so it had to explode here as a blog post.<br />
<br />
A typical data driven application involves <a href="http://en.wikipedia.org/wiki/Create,_read,_update_and_delete">CRUD</a> operations on domain entities which are important to business. Such application typically capture data from user or other system in a centralized database for reporting or for further distribution. Architecture of such application is generally simple and there's a vast
ecosystem of platforms, frameworks, tools and libraries to support it.<br />
<br />
If we wanted to represent traditional design of such application in terms of a <a href="http://en.wikipedia.org/wiki/Finite-state_machine">state machine</a>, then we can say that such application capture, distribute and allow reporting of domain in a <b>certain state</b>. The primary objective of such application is to facilitate data manipulation (CRUD) which changes state of the domain. For most applications it is generally a sound design ignoring familiar caveats.<br />
<br />
Thinking in terms of state machines, there's an interesting alternative: we can store all the <b>state transitions</b> that led initial domain model to its current state. This second perspective to application design has many interesting repercussions. In this approach, current state of domain is no longer as important as the earlier approach because it can be recreated just by repeating all the transitions. This second approach is named "<b>Event sourcing</b>" where event is just a little familiar name for state transition.<br />
<br />
Not every application care about the easy recreatibility aspect of domain, most business applications care only about current state of domain. However many applications, especially the ones with mandated audit trails or domain with significant historical data, can benefit from event sourcing. A common example of such application is a version control system, version control systems capture state transitions (diffs) of domain entities (source files) so you can switch to any state (version) and rebuild it to desired state by successive applications of state transitions (diffs).<br />
<br />
As far as business domains goes, <b>Insurance domain</b> by far seems to be a great area of application for event sourcing given that audit trail is a legal compliance requirement and insurance domain models tend to be really complex. Think of an insurance policy as a state and all the changes to it (endorsements) as transitions. By just tracking the transitions, one can rebuild a policy to its current state and reason about it for underwriting analysis and audit. Compare it, instead, with our initial approach of capturing multiple states (identical records in relational database) with complex logic to diff them and comparing them. This approach has profound positive implication on usability of application as well as testability, with this approach it is easy to visualize and rebuild data of interest to any point in time.<br />
<br />
One more interesting application of event sourcing, I think, is in data mining. If data is stored as events it is fairly easy to sample, plot and build historical and predictive models. My limited experience in mining data has always involved custom (expensive) efforts to store historical data, such custom efforts usually involve complex development efforts just to extract marginally meaningful information.<br />
<br />
It shouldn't be surprising that event sourcing can have significant influence on application architecture which may not be an easy sell especially in a larger setting. There are many related concepts to event sourcing, specifically <a href="http://cqrsinfo.com/">CQRS</a> which lead to wild architectures (which I'm not quite fond of yet). <br />
<br />
I'm learning this is not new or revolutionary and has been done in past but never caught up for whatever reasons, nonetheless I find it interesting. As far as my technical curiosities go I'm very much inclined to try it
out with a pet project to see how far these benefits are viable. Nirav Thakerhttp://www.blogger.com/profile/07204297663478577248noreply@blogger.com0tag:blogger.com,1999:blog-11200164.post-1810164590609199362011-03-07T22:17:00.007-05:002011-03-08T19:40:54.288-05:00Why Concurrency is hardConcurrency is hard because we haven't figure out how to make it easy. For most developers, specifically web developers, concurrency doesn't really matter. I envy that assuasive confident feeling of a sequential execution of http requests. The number of cores on my machine quadrupled in last three years and I don't know a single reliable, comforting (easy) way of harnessing it as much as possible, I feel a little sad about current state of concurrency support.<br />
<br />
Utilizing all the processing power consistently is a lot easier for well defined and not so concurrent tasks such as map-reduce. I have done it a lot, processing gigabytes of data by reducing the problem to independent subsets is programmatic triviality. On the other hand, I have always found developing a relatively concurrent application the "right way" to be a nightmare. Concurrency applications come in two mutually exclusive flavours: slow or complex.<br />
<br />
At this point enthusiasts will point out <a href="http://download.oracle.com/javase/6/docs/api/java/util/concurrent/package-summary.html">java.util.concurrent</a> and move on. While j.u.concurrent is nice and a significant improvement over explicit synchronization, it still mandates that API users be concurrency wizards and its complexity exposure is nearly at par with explicit synchronization. Here's one example <a href="http://dmy999.com/article/34/correct-use-of-concurrenthashmap">blog post</a> explaining common gotcha with <a href="http://download.oracle.com/javase/1.5.0/docs/api/java/util/concurrent/ConcurrentHashMap.html#put(K, V)">ConcurrentHashMap</a>. The only benefit j.u.concurrency provides is finer grained control over where to do <a href="http://en.wikipedia.org/wiki/Compare-and-swap">CAS</a>. I am a huge fan of j.u.concurrent and have been using it pre-1.5 but I still don't think it makes concurrency so easy. For one more example,<br />
<br />
synchronized(this){ aRef = newVal; return aRef;}<br />
<br />
v/s<br />
<br />
while (true) {<br />
V x = atomicRef.get();<br />
if (atomicRef.compareAndSet(x, newValue))<br />
return atomicRef.get();<br />
}<br />
<br />
<br />
Which one do you think is easier to grasp?<br />
<br />
Many people think that <a href="http://en.wikipedia.org/wiki/Actor_model">Actors</a> are the next big thing to tackle concurrency monster and complexities introduced by these shared memory model primitives. I too initially <a href="http://blog.nirav.name/2009/04/forkjoin-concurrency-with-scala-actors.html">thought so</a>, but then I found that Actor model isn't really the sweet spot in practice as it is touted. The very notion that Actors can fail and code must handle the tricky bits to recover from it makes it even more complex than using locks/mutexes etc. I am in constant a awe to see people talking so lightly about fault tolerant/fail safe systems without giving thought on the amount of complexity it adds. I am not necessarily protesting that philosophy but that behaviour is just not common in yer average regular applications (will your user be happy if one actor failed to process her payment and was asked to retry?). We still live in dark ages of transparent concurrency.<br />
<br />
I remain as ignorant and unsatisfied about concurrency support as I was several years ago. For me, concurrency is hard so I am off to shopping!Nirav Thakerhttp://www.blogger.com/profile/07204297663478577248noreply@blogger.com5tag:blogger.com,1999:blog-11200164.post-42610055335825588122010-12-13T22:49:00.001-05:002011-01-24T18:12:45.320-05:00Tackling nulls the functional wayMost programmers have suffered null pointer one way or other - usually a core-dump followed by a segmentation fault on development machine or on a production box with application in smokes. NullPointerException results in a visible embarrassment of not thinking about "that something *could be* null".<br />
<br />
Tracking Null Pointer ranges from loading core-dump in gdb and tracing dereferenced pointer to stack traces pointing to exact location in source. However, ease of tracking nulls opens up the doors to ignore them in practice and throwing null-checks just becomes as common as throwing one more div to fix IE's layout problems which is bad.<br />
<br />
<span class="Apple-style-span" style="font-size: large;"><b>Problems with Null:</b></span><br />
I hate having to ignore nulls as it is not always enough just to add one more null check. The reason why I am writing this blog is because I have several problems with Nulls:<br />
<ol><li>All and Every reference can be a null in languages like Java. This covers everything: method parameters, return values, fields etc. There's no precise way for a programmer to know that some method might return null or accept null parameters. You absolutely have to resort to actual source code or documentation to see if it can possibly return null (and you are going to need good luck with that). All of it adds extra work when you really want to be focusing on fixing the real problem.</li>
<li>The problem with NullPointerException is that they point to causal eventuality and not usually the actual cause. So what you see in stack traces are usually the code paths where damage is not really initiated but done when we are normally interested in case where damage is initiated. </li>
<li>Null is actually very ambiguous. Is it the uninitialized value or absence of value or is it used to indicate an error? The paradigm of null fits well in database but not in programming model.</li>
<li>Having Nulls in your code has major implications in code quality and complexity. For example, it is not unusual to see code branches with null checks breeding like rabbits when an API "may" return null which in turn results in extremely defensive code. This significantly taxes readability.</li>
<li>Null makes Java's type system dumber when a method is overridden and you want to call it. Writing code like methodDoingStuff((ActualType)null, otherArgs) isn't exactly a pretty sight. This results in subtle errors when arguments are non-generic. </li>
</ol>In many ways Nulls are necessary evil. For those of us who care about readability and safety we can't ignore them yet we shouldn't just let it overtake safety and readability.<br />
<br />
I have come to know several techniques to tackle nulls. First, there is <a href="http://en.wikipedia.org/wiki/Null_Object_pattern">Null Object pattern</a> which is not entirely as ridiculous as the name implies but it's not practical in real life software having hundreds of class hierarchies and thousands of classes, and so, I will not talk about it. Then there are languages like Haskell and Scala with library classes that try to treat nulls in, IMO, a better way. Haskell has <a href="http://www.haskell.org/ghc/docs/6.12.2/html/libraries/base-4.2.0.1/Data-Maybe.html">MayBe</a> and Scala has <a href="http://www.scala-lang.org/api/current/scala/Option.html">Options</a>. After using options in Scala for a while in a <a href="https://github.com/niravthaker/slibpst">side project</a>, I found that I was no longer fighting with nulls. I knew exactly when I had to make a decision that a value is really optional and I must do alternate processing.<br />
<br />
The central idea behind Haskell's MayBe and Scala's Option is to introduce a definitive agreement on a value's eligibility to be either null or not-null enforced with the help of type system. I will talk about Scala's Option since I have worked with it, but the concept remains same. I will also introduce how to implement and use Options in Java since this is much more of a functional way of thinking about handling nulls and it doesn't (almost) take Scala's neat language features to implement it.<br />
<br />
<b><span class="Apple-style-span" style="font-size: large;">Treating nulls the better way:</span></b><br />
<br />
<div style="margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px;">Usual course of action when you are not sure what value to return from a method is:</div><div style="margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px;"><script src="https://gist.github.com/737060.js?file=NullDefence.java">
</script></div><div style="margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px;">Most of the times it results in the last option because you don't have to fear about breaking everything (well, mostly) and everyone passes the buck like this.</div><br />
We can do better with Scala's Option classes. We can wrap any reference in to Some or None and handle it with pattern matching or "for comprehension". For example:<br />
<br />
<script src="https://gist.github.com/737084.js?file=ScalaOptionExample.scala">
</script><br />
Some(x) represents a wrapper with x as actual value; None represents absence of value. Some and None are subclasses of Option. Option has <a href="https://lampsvn.epfl.ch/trac/scala/browser/scala/tags/R_2_8_1_final/src//library/scala/Option.scala#L1">all the interesting methods</a> you can use. When a variable in question is null we can: fall back to default value, evaluate and return a function's computed value, filter and so on.<br />
<br />
<span class="Apple-style-span" style="font-size: large;"><b>Options in Java:</b></span><br />
Implementing Options in Java is surprisingly a trivial task. However, it is not as pleasant as Scala's options. Implementation boils down to a wrapper class Option with two children: Some and None. None represents a null but with a type (None[T]) and Some represents non-null type.<br />
<br />
To make Option interesting we make Option extend List, so we can iterate on it to mimic poor man's "for comprehension". We will also go as far as tagging both types with Enums so we can do poor man's pattern matching with a switch. You can find <a href="https://github.com/niravthaker/common-utils/tree/master/src/name/nirav/common/utils/monads">example implementation of Options</a> in Java with a test case <a href="https://github.com/niravthaker/common-utils/blob/master/test/name/nirav/common/utils/OptionsTest.java">demonstrating use of Options</a>. Here's the small snippet which covers the essense:<br />
<script src="https://gist.github.com/739905.js?file=OptionsInJava.java">
</script><br />
As you can see, Option opens up several doors to fix the null situation. You now have choice to compute a value, use default value or do arbitrary stuff when you encounter nulls.<br />
<br />
<span class="Apple-style-span" style="font-size: large;"><b>How are my null problem solved with Options:</b></span><br />
<ol><li>Using Options for optional/null-able references I have at least avoided "all things could be null" problem in my code. When an API is returning a Option,<t> I don't have to wonder if it can return null. Intention is pretty clear.</t></li>
<li>When I am forced to handle null right at the time of using an API, I have to handle it right there: do alternate processing or use default. No surprises.</li>
<li>Option is a very clear way of saying a variable represents possibly an absent value.</li>
<li>Option doesn't really solve this problem completely. For example, method signatures with wrapper Option type can get really long (e.g. def method1(): Map[String, Option[List[Option[String]]] = {}). However, compared to null checks, I would prefer long method signature any day. Other benefits out-weight this limitation.</li>
<li>Clearly, Option[Integer] always means only Option[Integer] and not Option[Integer], Option[String], Option[Character], Option[Date] and so on. Compiler can infer exact method call from generic types.</li>
</ol><div>As good as the concept behind optional values is, it doesn't and will not always save you from Null. You will still have to deal with existing libraries which return nulls and cause all these problems and more. However, most of the time null is problematic in your own code.</div><div><br />
</div><div><span class="Apple-style-span" style="font-size: large;"><b>Where to use Options:</b></span></div><div>Here are the common places where I think using Options makes more sense:</div><div><ol><li>APIs: Make your API as specific and as readable as possible; all optional parameters and return values should be Option<t>.</t></li>
<li>Use in your domain model: You already have fair understanding on null-able columns, use Option<t> for null-able fields in your table. It is not hard to integrate using Options if you are using an ORM with interceptable DB fetch; you can initialize fields to None<t> if database contains null and so on.</t></t></li>
</ol><div><br />
</div><div>In the interest of keeping this post relevant and on topic, I have completely avoided heavy theoretical baggage (monads et. al.) that's inevitable when theoretical functionalists (functional programmers) talk about Options. I really hope this post generates some interest in this topic. If you disagree or would like to share more on this topic, please leave a comment.</div></div>Nirav Thakerhttp://www.blogger.com/profile/07204297663478577248noreply@blogger.com1tag:blogger.com,1999:blog-11200164.post-81612520174753635312010-05-01T12:34:00.006-04:002010-05-04T10:20:56.713-04:00Future of a Java programmerAs a long time Java only programmer professionally, I have been pondering about how things are changing around me as a Java programmer. Ever since I remember I had no choice but to use subset of C++ dialect (Java lang) with an extremely rich class library and ecosystem (Java platform).<br />
<br />
In last few years there has been a drastic shift in number of languages targeting JVM. For example: dynamic (javascript, jruby, jython, groovy), functional + OO (scala) and a lisp dialect (clojure) and <a href="http://en.wikipedia.org/wiki/List_of_JVM_languages">so many others</a>. While I am excited about all the options I have today I don't think a single language will dominate on JVM anymore like Java did so far.<br />
<br />
In a way this is a good thing, one tool rarely fits all needs (I couldn't curse Java enough for GUI programming). Like C, Java was never designed to be used for developing dynamic web apps, but we still tried and miserably failed with JSP/JSF and plethora of frameworks against PHP/Rails/Python in terms of productivity. One really good thing Java did was to raise a level of abstractions from platform specific details and memory management. These new languages on top of JVM raise the abstraction level even further for its area of strength.<br />
<br />
It is not a remote future when we will see concurrent processes being programmed in clojure and presented with jruby/rails with intermediate code written in Java. Each layer of application is going to be implemented in different programming languages while interfaces being transparent for developers working in each layer. This is a big thing, it has never been envisioned before for Java Platform, the lowest coupling we have seen so far is through remoting (web services et. al.) where clients and servers are on different runtimes and languages.<br />
<br />
What this means for a Java developer is if you are<br />
<br />
<ul><li>A web developer: you are going to learn things which are extremely different from struts/jsf/jsps, no more artificial model1/model2 MVCs.</li>
</ul><ul><li>A non web-developer : you are going to write code which is far more readable and very specific to your business domain via DSL created in any of the languages mentioned above without worrying about accidental complexity Java and its frameworks imposed on you.</li>
</ul><br />
While I can keep classifying developers on Java platform all day long, these two are major ones whose life (and resumes) are going to change soon, they will be expected to know more than one programming languages rather than frameworks now. Contrary to the cool kids on interwebz, I don't think Java the language is going to die anytime soon not because many of the existing libraries are written in it, but because of the number of programmers on earth who know Java, tooling around it and the native JVM support for it. Java is like C in a way, you can do whatever is supported by underlying implementation.<br />
<br />
Many of you who are like me are going to see change around them soon, I am thrilled to see how my career is going to transform as polyglot programmer are you?Nirav Thakerhttp://www.blogger.com/profile/07204297663478577248noreply@blogger.com5tag:blogger.com,1999:blog-11200164.post-56090668503916563262010-03-07T12:58:00.004-05:002010-03-07T13:04:28.980-05:00Eclipse Refactoring for legacy code<span class="Apple-style-span" style="font-family: Arial; font-size: small;"><span class="Apple-style-span" style="font-size: 13px;"><span class="Apple-style-span" style="font-family: 'Times New Roman';"><span class="Apple-style-span" style="font-size: medium;">It has been quite sometime since I wrote anything on this blog, twitter probably spoiled me. If you are <a href="http://twitter.com/niravn1">following me on twitter</a>, you probably noticed announcement of a small eclipse plugin for automated refactoring for Legacy Code. </span></span></span></span><br />
<span class="Apple-style-span" style="font-family: Arial; font-size: small;"><span class="Apple-style-span" style="font-size: 13px;"><span class="Apple-style-span" style="font-family: 'Times New Roman';"><span class="Apple-style-span" style="font-size: medium;"><br />
</span></span></span></span><br />
<span class="Apple-style-span" style="font-family: Arial; font-size: small;"><span class="Apple-style-span" style="font-size: 13px;"><span class="Apple-style-span" style="font-family: 'Times New Roman';"><span class="Apple-style-span" style="font-size: medium;">Before few months, I wrote an LTK refactoring mainly in Scala (yes, eclipse plugin in Scala language) to forward static method calls in a Java method to an instance method in same class. I am not really an expert at Scala (or functional programming for that matter) so the code is more of javaish Scala but I am improving and thats the best thing about Scala. This is also an attempt to prove how easy it is to write eclipse plugins in Scala and how seamlessly it integrates with Java source; Scala is not only a better language, it is much more suitable to deal with Eclipse APIs (you can define views etc. on extremely verbose interfaces like JDT AST).</span></span></span></span><br />
<span class="Apple-style-span" style="font-family: Arial; font-size: small;"><span class="Apple-style-span" style="font-size: 13px;"><span class="Apple-style-span" style="font-family: 'Times New Roman';"><span class="Apple-style-span" style="font-size: medium;"><br />
</span></span></span></span><br />
<span class="Apple-style-span" style="font-family: Arial; font-size: small;"><span class="Apple-style-span" style="font-size: 13px;"><span class="Apple-style-span" style="font-family: 'Times New Roman';"><span class="Apple-style-span" style="font-size: medium;">Enough about Scala; the real purpose of the refactorings provided in this plugin would be to ease development with Legacy Java code, most of the code generators (think JavaCC) generate ugly Java code which is not only non unit testable but pain to comprehend and is often not usable with concurrent routines. Using this automated refactoring should make such code better. You can read more about the motivation behind the <a href="http://code.google.com/p/java-ext-refactorings/wiki/StaticCallForwardRefactoring">plugin in wiki</a>.</span></span></span></span><br />
<span class="Apple-style-span" style="font-family: Arial; font-size: small;"><span class="Apple-style-span" style="font-size: 13px;"><span class="Apple-style-span" style="font-family: 'Times New Roman';"><span class="Apple-style-span" style="font-size: medium;"><br />
</span></span></span></span><br />
For the performance heads who are worried about method chains introduced by this refactoring are encouraged to run their own "sane" micro-benchmarks to be sure JVM is really in-lining the method calls created by this refactoring.<br />
<span class="Apple-style-span" style="font-family: Arial; font-size: small;"><span class="Apple-style-span" style="font-size: 13px;"><span class="Apple-style-span" style="font-family: 'Times New Roman';"><span class="Apple-style-span" style="font-size: medium;"><br />
</span></span></span></span><br />
<span class="Apple-style-span" style="font-family: Arial; font-size: small;"><span class="Apple-style-span" style="font-size: 13px;"><span class="Apple-style-span" style="font-family: 'Times New Roman';"><span class="Apple-style-span" style="font-size: medium;">The plugin is currently in beta and I am open for any new refactoring proposals. If you have any feedback, you are welcome to comment on this blog post or <a href="http://code.google.com/p/java-ext-refactorings/issues/list">create a bug</a>. The <a href="http://java-ext-refactorings.googlecode.com/svn/branches/0.1-beta/name.nirav.refcatoringman.update">update site is here</a>.</span></span></span></span>Nirav Thakerhttp://www.blogger.com/profile/07204297663478577248noreply@blogger.com5tag:blogger.com,1999:blog-11200164.post-40792239885537143762009-08-13T21:00:00.012-04:002009-08-14T00:23:46.230-04:00Real RefactoringA lot of <a href="http://www.refactoring.com/sources.html">really good material</a> has been written about <a href="http://en.wikipedia.org/wiki/Code_refactoring">refactoring</a>. However, just like a lot of other things in software development, refactoring is also victimized by becoming the buzzword implying 'rewrites' and every other thing that is not refactoring. A lot of people really don't understand what they mean when they refer to 'refactoring', this post aims to provide a systematic explanation of refactoring for such audience.<div><br /></div><div>Refactoring is merely a process of restructuring existing code so that its end result and meaning remains intact. However, this restructuring has a great potential to become far better design than the original one. (It is implied that the refactored design is easier to refactor and hence better) In rest of this post I will try to summarize how to approach and refactor a code in real life application development.<div><br /></div><div><b>1. Get familiar with code</b></div><div><br /></div><div>I am assuming here that we are almost always refactoring code written fully or partially by others, refactoring your own code should be much more simple exercise. Primarily you would be dealing with Legacy code or testable code. If you are lucky enough to get the code which is almost covered with unit tests, your job becomes substantially easy and you can start refactoring very fast without a lot of trouble. However if you are working with existing code which just exists and works somehow, you will have to start slowly. The first step is to understand the incomprehensible. There are several ways you can get familiar with code:</div><div><ul><li>Read the code</li></ul><div><span class="Apple-tab-span" style="white-space:pre"> </span>Reading code is one of the fundamental activity we developers do most of the time, if any employer is in the illusion that she is paying developers just to write code then they are paying 1/3 of the salary. Reading code is an art which develops over the time, reading good code can make you better developer (with a precondition that one possesses the ability to judge good and bad code for the language). The more you read bad code the more you familiarize yourself with the repeating mistakes in the code (duplication, absolute hostility towards testability, extremely fearful defensive checks and other hilarities). The goal is to grasp the mindset of the original developer(s) who wrote it. You will know it immediately how deeply thought out the code is in a few passes. Use any modern IDEs to navigate through files, ignore the comments which don't make sense.<br /></div><ul><li>Write test</li></ul><div><span class="Apple-tab-span" style="white-space:pre"> </span>Once you have some understanding of inputs/outputs and/or interactions in code's life cycle you can write some tests just so that you can identify if you made some mistake in next step (Step 2). These tests might not be unit-tests (unless the code itself is unit testable). Writing test is incredibly useful way to get familiar with the code base.</div><div><br /></div><div><b>2. Isolate the refactoring hot-spot </b> (or "The Inflection points" as Michael Feathers calls it)</div><div><br /></div><div><span class="Apple-tab-span" style="white-space:pre"> </span>There has to be a really good reason why you are refactoring and it certainly can't be a full 'rewrite'. Irony will kill itself when it finds out that the problems in a bad code manifests itself in popular hot-spots. By isolating these hot-spots you should be able to mock out the uninteresting and untestable (or very slow) dependencies. If you have multiple inflection points; deal with them one by one in isolation. Isolation may become tricky because you may have to introduce some inevitable changes before you actually have any unit tests. For example, you might want to eliminate inherently untestable 'statics', extract methods/interfaces which you can stub with NullObjects/mocks. The tests created in earlier step will be valuable to identify any problems you introduced while isolating the code. The goal here is to not concern yourself with trivialities other than the refactoring hot-spots.</div><div><br /></div><div><b>3. Write unit tests</b></div><div><br /></div></div><div>Now that you have code which can be isolated, start writing unit tests. If you are working on Java sources I highly recommend using <a href="http://mockito.org/">Mockito</a> to mock the dependencies. Don't waste time on accidental complexities of other mock libraries. A reasonable analogy would be: if Agile software development is a good thing than other mocking tools are worse than Waterfall - Mockito is Agile. </div><div><br /></div><div>Your primary goal is to cover code under refactoring as much as possible, there are no hard numbers on code/branch coverages (but anything beyond 90% should be good enough :)), use common sense and quality metrics like <a href="http://www.artima.com/weblogs/viewpost.jsp?thread=215899">CRAP</a>. The more unit tests you will write, more you will learn about the code base. There may be totally unused code for anti-<a href="http://c2.com/xp/YouArentGonnaNeedIt.html">YAGNI</a> stronghold, or there might be bugs, Your unit test will reveal these naturally. Depending on the code in question, A good test suit generally reaches the size of the code under test.</div><div><br /></div><div><b>4. Refactor</b></div><div><br /></div><div>Refactoring is particularly painful when it has to be done in an environment with highly volatile code base and for the parts of code which are critical to overall application functionality. Make small changes; make sure all tests pass. </div><div><br /></div><div>If you are using Eclipse - turn off auto build and add a ANT or Maven builder so that it runs your tests after each compile - you will be running tests a lot. </div><div><br /></div><div>Use a real source control system, it might be much harder for you to revert the changes otherwise. You might consider using something like <a href="http://git-scm.com/">git</a> in between upstream and your local repository if your primary SCM is not good enough. In practice, this becomes a lot more important than what IDE you use, you will need the ability to identify and rollback a commit specifically in code base with many hands. Commit after each change, the smaller the commit the lesser chance of breaking a lot of things together by a long shot.</div><div><br /></div><div>With each commit going in repository without external complains (like "You broke my build!"), you will gain confidence to make bigger changes. You should continue writing tests while refactoring because if at this point you are making changes without violating functional contracts you are evolving a new design and doing something good. If you have broken something and your justification involves the word 'refactoring', you are doing it wrong! you either don't have enough tests or you failed to understand the code entrails.</div><div><br /></div><div>So this is refactoring in real life. For the primary audience, please consider following these simple steps before tossing the word 'refactoring' around. If you disagree, then invent the new word and let me know :).</div><div><br /></div></div>Nirav Thakerhttp://www.blogger.com/profile/07204297663478577248noreply@blogger.com2tag:blogger.com,1999:blog-11200164.post-12036327208758674052009-05-12T22:01:00.010-04:002009-05-13T00:21:42.405-04:00Scala v/s Java arraysHere's a Java puzzler for the curious (and a good interview question too!). Given a array merge method below, what will be the output of following program?<br /> <br /><pre name="code" class="java"><br /><br />public class Generics {<br /><br /> static class A {<br /> }<br /><br /> static class B extends A {<br /> }<br /><br /> public static void main(String[] args) {<br /><br /> A[] copy = merge(new B[] { new B() }, new A[] { new A() }, new B[1]);<br /> System.out.println(copy.length != 1);<br /><br /> }<br /><br /> static <Z> Z[] merge(Z[] arr1, Z[] arr2, Z[] store) {<br /> List<Z> list = new ArrayList<Z>();<br /> list.addAll(Arrays.asList(arr1));<br /> list.addAll(Arrays.asList(arr2));<br /> return list.toArray(store);<br /> }<br /><br />}<br /></pre> <br /><br />If you didn't guess it already, the program above results in a runtime exception (java.lang.ArrayStoreException). <br /><br /><pre><br />Exception in thread "main" java.lang.ArrayStoreException<br /> at java.lang.System.arraycopy(Native Method)<br /> at java.util.Arrays.copyOf(Unknown Source)<br /> at java.util.ArrayList.toArray(Unknown Source)<br /> at name.nirav.Generics.merge(Generics.java:23)<br /> at name.nirav.Generics.main(Generics.java:16)<br /></pre><br /><br />I am not a huge fan of generics in Java because we are left with whatever type safety we get from a half-hearted implementation (and I'm not even criticizing). It is too much to expect from a Java compiler to check that the program above has type safety compromised at call site, mostly because that's how arrays in Java are handled by VM. Arrays are special types of mutable objects with components as anonymous members which are accessed with indices. An array itself isn't a type, it assumes whatever type <a href="http://java.sun.com/docs/books/jvms/second_edition/html/Concepts.doc.html#21035">its components are</a>. This is where the problem starts. <br /><br />With current generics implementation, generic arrays are treated as covariant by default i.e. an array of component type T is also array of component type S where T is a subclass of S. This introduces type issues such as above where syntactically valid programs are victimized, making Java's "statically typed, type safe language" designation an irony. If arrays were regular objects, compiler will report an error in code without type variance information.<br /><br />Arrays are regular objects in Scala, each array is an instance of Scala.Array class. The code below is equivalent to Java program above with some syntactic differences, unlike Java code the Scala code below is not syntactically valid. Scala arrays are non-variant, and Scala compiler uses what is called "conservative approximation" to ensure type safety at compile time.<br /><br /><pre class="scala" name="code"><br />object App extends Application{<br /><br /> class A<br /><br /> class B extends A<br /> <br /> def merge[T](arr1 : Array[T], arr2: Array[T], store: Array[T]) : Array[T] = {<br /> val list = new ArrayList[T]<br /> list.addAll(Arrays.asList(arr1:_*)) // :_* is for vararg conversion<br /> list.addAll(Arrays.asList(arr2:_*))<br /> list toArray store<br /> }<br /><br /> merge(Array[B](new B), Array[A](new A), new Array[B](1)) //Error, type mismatch <br /><br />}<br /></pre><br /><br />The Scala compiler will report an error on "merge" call, complaining about type mismatch. <br /><br />Not everyone likes to know about such details until it bites back with million dollar bugs. Why are Java arrays co-variant? Who needs more run time checks?Nirav Thakerhttp://www.blogger.com/profile/07204297663478577248noreply@blogger.com10tag:blogger.com,1999:blog-11200164.post-32429154004057527012009-05-05T22:23:00.000-04:002009-05-05T00:18:39.620-04:00Fork/Join Concurrency with Scala ActorsHave you ever wondered why there are no special frameworks to address concurrency in a Java based application? Considering Java's rich (NIH) ecosystem, I do wonder why I have to write same old state management code while introducing even a small amount of concurrency in Java application.<br /><br />The reason why I think it is almost impossible to consider concurrency as an aspect in arbitrary application is because of JVM's native support for shared memory concurrency. As a result every developer is forced to think in terms of threaded shared state with guarded blocks. If you have read or written non-trivial piece of code using shared memory concurrency primitives (Mutex, Semaphore etc.) you probably know that the resultant code is hard to visualize and test.<br /><br />I have been reading about Scala's Actor library and its share-nothing message passing abstraction built over existing concurrency model of JVM. While it doesn't try to solve the fundamental problem, it provides an alternative to address concurrency in your application from a different perspective which is testable and easier to understand.<br /><br />In <a href="http://en.wikipedia.org/wiki/Actor_model">actor model</a>, an Actor is a forkable task which runs independently, something like a serializable+immutable object with its private data and behavior. Each actor can send and receive (or react to) messages asynchronously, very similar to object oriented programming with objects responding to messages, but in a concurrent way. This abstraction can seamlessly be applied to a given application of <a href="http://en.wikipedia.org/wiki/Divide_and_conquer_algorithm">divide and conquer</a> nature and can be made concurrent with minimal efforts as compared to adapting to Java's concurrency primitives.<br /><br />To explain my point further take a look at classically trivial Producer/Consumer example in Java.<br /><pre name="code" class="java"><br />public class Consumer extends Thread {<br />private final Buffer buffer;<br />public Consumer(Buffer buffer) {<br /> super("Consumer");<br /> this.buffer = buffer;<br />}<br />@Override<br />public void run() {<br /> while (true){<br /> System.out.println(buffer.next());<br /> }<br />}<br />}<br />public class Producer extends Thread {<br />private final Buffer buffer;<br />public Producer(Buffer buffer) {<br /> this.buffer = buffer;<br />}<br />@Override<br />public void run() {<br /> Random random = new Random(System.nanoTime());<br /> while (true) {<br /> String num = Integer.toString(random.nextInt());<br /> System.out.println(getName() + "=putting: " + num);<br /> buffer.add(num + ": " + getName());<br /> try {<br /> sleep(400);<br /> } catch (InterruptedException e) {<br /> }<br /> }<br />}<br />}<br />public class Buffer {<br />private String string;<br />private boolean ready = false;<br />public synchronized String next() {<br /> if (ready != true)<br /> try {<br /> wait();<br /> } catch (InterruptedException e) {<br /> }<br /> ready = false;<br /> return string;<br />}<br /><br />public synchronized void add(String string) {<br /> while(ready == true)<br /> try {<br /> wait();<br /> } catch (InterruptedException e) {<br /> }<br /> this.string = string;<br /> notifyAll();<br /> ready = true;<br />}<br /><br />}<br />public class Test {<br />public static void main(String[] args) throws Throwable {<br /> Buffer buffer = new Buffer();<br /> new Consumer(buffer).start();<br /> Producer producer = new Producer(buffer);<br /> producer.start();<br /> producer.join();<br />}<br />}<br /><br /><br /></pre>Take a look at Buffer class, we have used some concurrency primitives there since that's the place where state is being manipulated. We didn't declare variable ready as volatile since primitive assignments are guaranteed to be atomic (<a href="http://java.sun.com/docs/books/jvms/second_edition/html/Threads.doc.html#22244">except long and double</a>), Even a simple problem like this involves fair bit of understanding of the underlying threading model. There's no doubt this complexity will extrapolate in non-trivial applications e.g. multi-phase concurrent incremental compiler, SEDA based server etc.<br /><br />Now take a look at the equivalent Producer/Consumer example in Scala.<br /><pre name="code" class="Scala"><br />import actors._<br />import actors.Actor._<br />import util.Random<br /><br />case class SimpleMessage(num: Long)<br /><br />class Producer(c: Consumer) extends Actor{<br />val random = new Random(System nanoTime)<br />def act = {<br /> loop{<br /> val num = produce<br /> println("Sending: " + num )<br /> c ! SimpleMessage(num) // asynchronous message passing<br /> }<br />}<br />def produce(): Long = {<br /> Thread sleep 400<br /> return random.nextLong<br />}<br />}<br />class Consumer() extends Actor{<br />def act = {<br /> loop{<br /> receive{ //blocks here<br /> case SimpleMessage(num) => println("Received: " + num);<br /> }<br /> }<br />}<br />}<br />object PCTest {<br />def main(args : Array[String]) : Unit = {<br />var c = new Consumer()<br />var p = new Producer(c)<br />c.start;p.start<br />}<br />}<br /></pre><br />Even if we don't compare the amount of code, the Scala code above is much more clear in terms of its functionality. In Scala, Actors can be mapped to a single native thread with 'receive' (similar to Thread#wait()) or we can replace 'receive' with 'react' which is event based invocation but doesn't cost a blocked thread. The code within 'react' is executed by any non-blocked thread from a pre-created thread-pool. Just a single change and your application is scalable!<br /><br />The Java example code above can be equally trivialized with the util.concurrent BlockingQueue, but the important point to take away is, writing shared memory concurrency code is inherently difficult and error-prone. With JDK1.7 we will get similar <a href="http://gee.cs.oswego.edu/dl/papers/fj.pdf">fork/join abstraction</a> in Java itself (JSR166y), which will add new alternative to how we design and write concurrent applications.<br /><br />Scala borrowed Actors from Erlang and similar <a href="http://sujitpal.blogspot.com/2009/01/more-java-actor-frameworks-compared.html">libraries exist for Java</a> as well. If you are curious about interesting details on Actor based OO concurrency implementation in Java, take a<a href="http://www.jroller.com/sebastianKuebeck/entry/object_orinetned_concurrency_meets_actors"> look at some of</a> the thoughts<a href="http://www.jroller.com/sebastianKuebeck/entry/object_oriented_concurrency"> Sebastian is sharing with</a> his ConcurrentObjects library.Nirav Thakerhttp://www.blogger.com/profile/07204297663478577248noreply@blogger.com1tag:blogger.com,1999:blog-11200164.post-20566094800949350892009-04-21T22:29:00.015-04:002009-04-24T23:20:56.507-04:00How Scala's pattern matching can replace VisitorsThe primary motivation of <a href="http://en.wikipedia.org/wiki/Visitor_pattern">Visitor design pattern</a> is to separate model traversal from operational logic. A visitable model takes the responsibility of model navigation while the behavior is defined by arbitrary visitors. In this post I will try to explain problems associated with Visitors in general and how <a href="http://www.blogger.com/www.scala-lang.org/node/120">Scala's pattern matching</a> feature can eliminate such problems cleanly.<br /><br />Consider a simplified Insurance Policy model as follows (In Java):<br /><pre name="code" class="java"><br /><br />public class PolicyElement {<br /> static class Quote extends PolicyElement {<br /> protected final Risk risk;<br /> public Quote(Risk risk) {<br /> this.risk = risk;<br /> }<br /> public void accept(PolicyVisitor visitor){<br /> visitor.visit(this);<br /> visitor.visit(this.risk);<br /> }<br /> }<br /><br /> static class Risk extends PolicyElement {<br /> protected Coverage coverage;<br /> public Risk(Coverage coverage) {<br /> this.coverage = coverage;<br /> }<br /> public void accept(PolicyVisitor visitor){<br /> visitor.visit(coverage);<br /> }<br /> }<br /><br /> static class Coverage extends PolicyElement {<br /> protected final Premium prem;<br /> public Coverage(Premium prem) {<br /> this.prem = prem;<br /> }<br /> public void accept(PolicyVisitor visitor){<br /> visitor.visit(prem);<br /> }<br /> }<br /><br /> static class Premium extends PolicyElement {<br /> protected final double amt;<br /> public Premium(double amt) {<br /> this.amt = amt;<br /> }<br /> public void accept(PolicyVisitor visitor){<br /> visitor.visit(this);<br /> }<br /> }<br />}<br /><br />public interface PolicyVisitor {<br /> public void visit(Quote quote);<br /> public void visit(Risk risk);<br /> public void visit(Coverage cvrg);<br /> public void visit(Premium prem);<br />}<br />public class PolicyTest {<br /> static class PremiumCalcVisitor implements PolicyVisitor {<br /> private double totalPremium;<br /><br /> @Override<br /> public void visit(Premium prem) {<br /> totalPremium = getTotalPremium() + prem.amt;<br /> }<br /><br /> @Override<br /> public void visit(Coverage cvrg) {<br /> }<br /><br /> @Override<br /> public void visit(Risk risk) {<br /> }<br /><br /> @Override<br /> public void visit(Quote quote) {<br /> }<br /><br /> public double getTotalPremium() {<br /> return totalPremium;<br /> }<br /> };<br /><br /> public static void main(String[] args) {<br /> Quote quote1 = new Quote(new Risk(new Coverage(new Premium(10))));<br /> Quote quote2 = new Quote(new Risk(new Coverage(new Premium(30))));<br /> PremiumCalcVisitor visitor1 = new PremiumCalcVisitor();<br /> PremiumCalcVisitor visitor2 = new PremiumCalcVisitor();<br /> quote1.accept(visitor1);<br /> quote2.accept(visitor2);<br /> assert visitor1.getTotalPremium() + visitor2.getTotalPremium() == 40;<br /> }<br />}<br /><br /></pre><br />(Generally, we introduce one more abstract class to omit empty implementations in Visitors but I have left it for brevity.)<br /><br />Now, not so apparent problem here is that if the object model changes (which is more frequently the case in real life), we have to add one more method to PolicyVisitor interface, all visitor implementations if change is substantial and have new Policy elements implement visitor methods. This invasive nature of Visitor couples it tightly with the model.<br /><br />With pattern matching and <a href="http://www.scala-lang.org/node/130">views</a> in Scala, you can have alternative implementation which is precise as well as non-invasive unlike visitors.<br /><pre name="code" class="scala"><br />class PolicyElement <br />case class Quote(risks: Risk) extends PolicyElement<br />case class Risk(cvrg: Coverage) extends PolicyElement <br />case class Coverage(limit: Premium) extends PolicyElement <br />case class Premium(amt: Double) extends PolicyElement<br />object PremCalcTest {<br /> class PremCalculator(pol: PolicyElement){<br /> def calcPrem : Double = calcPrem(pol)<br /> <br /> def calcPrem(policy: PolicyElement): Double = policy match{<br /> case Quote(risk) => calcPrem(risk)<br /> case Risk(coverage) => calcPrem(coverage)<br /> case Coverage(premium)=> calcPrem(premium)<br /> case Premium(amt) => amt<br /> }<br /> }<br /> <br /> implicit def calPremV(pol: PolicyElement)= new PremCalculator(pol)<br /> <br /> def main(string: Array[String]){<br /> val risk1 = Risk(Coverage(Premium(10)))<br /> val risk2 = Risk(Coverage(Premium(30)))<br /> println(Quote(risk1).calcPrem + Quote(risk2).calcPrem)<br /> }<br />}<br /></pre><br />This code requires some explanation. What we have done here is we labeled domain classes with a 'case' keyword in Scala. If you tag a class with 'case' it can be used for pattern matching in a switch-case like structure as done in method 'calcPrem'. You don't need to create members or setter/getters for them, they are created by compiler for you. A case class can be instantiated without 'new' keyword; So Risk(Coverage(Premium(0)) is translated as new Risk(new Coverage(new Premium(0D))) in equivalent Java code.<br /><br />The code in 'calcPrem' function can be assumed to be something similar to instanceOf checks for each possible case in Java, for example:<br /><br /><pre name="code" class="scala"><br />if(object instanceOf Premium)<br />return ((Premium)object).amt;<br /></pre><br /><br />What we also have done silently is added a method 'calcPrem' to PolicyObject class. This is done through implicitly defined function 'calPremV', this will allow us to call 'calcPrem' method on any PolicyObject without actually modifying the domain model code. This type of lexically scoped class extension is known as a View in Scala and is similar to what is available in Ruby as <a href="http://rubylearning.com/satishtalim/ruby_open_classes.html">open classes</a> except without scoping.<br /><br />In case if the model changes in this case, we just need to modify a single function and we are done. These programming language features of Scala frees us from coupling introduced by inheritance.<br /><br />So it is easy to see that Scala's language features can be elegant and far more powerful than other languages (specifically Java) without sacrificing compiler checks and type safety.Nirav Thakerhttp://www.blogger.com/profile/07204297663478577248noreply@blogger.com1tag:blogger.com,1999:blog-11200164.post-89291832702168005992009-04-16T21:38:00.003-04:002009-04-16T22:47:47.946-04:00Your Language is not SLOW!Do you really give a thought when you say "Ruby is slow or Python is slow"? Just because Twitter moved their <span class="blsp-spelling-corrected" id="SPELLING_ERROR_0">back end</span> messaging to <span class="blsp-spelling-error" id="SPELLING_ERROR_1">JVM</span> doesn't necessarily make Ruby any slower than it already was. If a language <span class="blsp-spelling-error" id="SPELLING_ERROR_2">runtime</span> can't handle concurrent load or long running processes it is not a limitation of the language!<br /><br />This is <span class="blsp-spelling-error" id="SPELLING_ERROR_3">dejavu</span> for me as Java was considered "a slow language" back in 1.1 days when <span class="blsp-spelling-error" id="SPELLING_ERROR_4">HotSpot</span> <span class="blsp-spelling-error" id="SPELLING_ERROR_5">JVM</span> was in its poorer life and ISO/<span class="blsp-spelling-error" id="SPELLING_ERROR_6">IEC</span> C++ was hot girl in town. Now that you realized your pony implementations can't catch up with real life performance expectation you start blaming languages, are you serious?<br /><br />Whether it's <a href="http://en.wikipedia.org/wiki/Global_Interpreter_Lock">global interpreter lock</a> or <a href="http://en.wikipedia.org/wiki/Green_threads">lack of native threads</a> it's the <span class="blsp-spelling-error" id="SPELLING_ERROR_7">runtime</span> (re-read the <span class="blsp-spelling-error" id="SPELLING_ERROR_8">runtime</span>) and not the language that is slow. For the love of technology, Stop <span class="blsp-spelling-corrected" id="SPELLING_ERROR_9">blaming</span> languages for poor performance of your <a href="http://unlimitednovelty.com/2009/04/twitter-blaming-ruby-for-their-mistakes.html">suboptimal reinventions</a>!<br /><br />Every language <span class="blsp-spelling-error" id="SPELLING_ERROR_10">implementor</span> should at least consider the host platform support before coming up with their "Not Invented Here" approach, sadly that's what is happening with most modern languages.Nirav Thakerhttp://www.blogger.com/profile/07204297663478577248noreply@blogger.com7tag:blogger.com,1999:blog-11200164.post-90523352800812053162009-04-09T22:21:00.004-04:002009-04-10T00:21:40.220-04:00Scala: First impressionIf you are curious enough about programming languages then you probably have heard about Scala - the 'statically typed' functional and object oriented language. <a href="http://www.scala-lang.org/">Scala</a> is the new sun rising to balance 'the burn factor' between functional and object oriented schools of thoughts.<br /><br />Unlike what <a href="http://www.scala-lang.org/sites/default/files/linuxsoft_archives/docu/files/ScalaOverview.pdf">this paper suggests</a>[pdf], The reason why I think Scala exists is because functional v/s object oriented groups are moving in opposite directions, which is not only inefficient but they can't leverage achievements of one another. If you read about functional v/s object oriented programming comparison, every argument boils down to productivity, tooling and maintainability of code. While functional languages (Lisp, Haskell, Python etc.) offer excellent productivity compared to OO languages (Java, C++ etc.), Object oriented languages offer excellent tooling and are relatively maintainable. The reason why I think OO languages have been so popular is due to its easier to understand concept which is easy to map in real life, so for most people who have never took computer science course OO is still easier to grasp compared to Functional programming methods like list comprehension, closures or the higher order functions which are rooted from the formal systems of mathematics.<br /><br />Scala tries to satisfy both of the groups by providing grammar and a type system which seamlessly integrates with mainstream platforms (Java, .NET) and offers powerful functional abstractions only available in dynamic languages. What this means is, Java developers can write their code in same fashion they write in Java using existing libraries and frameworks but with an added advantage of functional programming techniques wherever they feel it might be productive. Functional programming language enthusiast get access to rich class libraries and powerful tooling (eventually).<br /><br />If you take a look at the Scala language <a href="http://www.scala-lang.org/docu/files/ScalaReference.pdf">grammar</a>[pdf] you will notice that <a href="http://debasishg.blogspot.com/2008/05/designing-internal-dsls-in-scala.html">what you can create</a> with Scala is limited by <a href="http://blog.fogus.me/2009/03/26/baysick-a-scala-dsl-implementing-basic/">your creativity</a>. Based on what I have learned so far, I find Scala much more refreshing than Java, Scala feels a lot more like a programming language of the 21st century! Scala compiler itself is pluggable so you can do heck of a stuff you can only dream with javac, ecj. What is missing is tooling, the existing tooling is scrap but that will improve hopefully with an active community.<br /><br />Bill Venners of <a href="http://www.artima.com/">Artima</a> has presented Scala wonderfully, take a <a href="http://www.parleys.com/display/PARLEYS/Home#slide=1;title=The%20Feel%20Of%20Scala;talk=27131945">look at the presentation</a>[requires flash] on 'The feel of Scala'.Nirav Thakerhttp://www.blogger.com/profile/07204297663478577248noreply@blogger.com1tag:blogger.com,1999:blog-11200164.post-66512245698717129062009-03-24T23:04:00.010-04:002009-03-25T23:11:47.342-04:00OPath ported for Java object modelI have been thinking about alternate uses of OPath I created for EVars plug-in. And it occurred to me that I can very well use it for my unit testing (which involves pretty complex insurance object model) and for things like JSPs where I really hate to write ten lines of Java code just to display some value.<br /><br />So I wrote a <a href="http://code.google.com/p/evars/source/browse/#svn/trunk/name.nirav.opath.reflect">port of OPath for Java object model</a> (less than 200 lines of real code). Following example should explain how it can add some value to your development efforts:<br /><br />Consider an example of code for simple <a href="http://java.sun.com/developer/technicalArticles/GUI/accessibility2/#code5">Accessible Swing Table</a> :<br /><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://java.sun.com/developer/technicalArticles/GUI/accessibility2/SimpleTable.gif"><img style="margin: 0px auto 10px; display: block; text-align: center; cursor: pointer; width: 515px; height: 121px;" src="http://java.sun.com/developer/technicalArticles/GUI/accessibility2/SimpleTable.gif" alt="" border="0" /></a><br />If you are writing a UI test to see specific table's column heading, you just write following<br /><br /><pre style="background: none repeat scroll 0% 0%; color: rgb(0, 0, 0); -moz-background-clip: -moz-initial; -moz-background-origin: -moz-initial; -moz-background-inline-policy: -moz-initial;">Collection<Object> findAll = OPathReflectiveInterpreter.findAll(frame, "<span style="color: rgb(63, 127, 89);">//dataModel//@val\\$column.*");</span><br />assertEquals("First Name",((Object[])findAll.toArray()[0])[0]);<br /></pre><br />This is very trivial test, of course. But it is sufficient to express the power of OPath micro-scripting.<br /><br />If you like to try it out for unit-testing or templating check-out the download <a href="http://evars.googlecode.com/files/opath-jom_1.0.0.jar">here</a> (You will also need <a href="http://evars.googlecode.com/svn/tags/b32209_01/name.nirav.evariablesview/lib/opath.jar">opath.jar</a>).<br /><br />Disclaimer: This is experimental work at best, it might be slow and it might have bugs at this time.Nirav Thakerhttp://www.blogger.com/profile/07204297663478577248noreply@blogger.com0tag:blogger.com,1999:blog-11200164.post-91372079962899525482009-03-22T22:58:00.005-04:002009-03-22T23:29:56.937-04:00EVars UpdateBased on the awesome feedback, I have been <a href="http://code.google.com/p/evars/updates/list">doing some offline development</a> on <a href="http://code.google.com/p/evars/">EVars</a> plug-in lately. I have added some basic documentation on <a href="http://code.google.com/p/evars/w/list">wiki</a>. Installation is now easy, let P2 do the work to <a href="http://evars.googlecode.com/svn/evars-update">install/update</a> the plug-in (it's a struggle to host update-site with google code).<br /><br />One of the most exciting feature (Which I can't stop talking about) is value based filtering. Now you can have all the powers of predicate expression, how about searching a map like map//key['@user.*']/.. to select entries matching regular expression user.* ? This update also includes support for relational operators so you can search exactly you want like this //value[count > n] .<br /><br />I have uploaded <a href="http://code.google.com/p/evars/wiki/OPathGrammar">OPath grammar</a> for the language enthusiasts (left factored, left recursion free). One feedback was 'experiencing some unresponsive behavior for huge graphs' I have addressed that to some extent by integrating progress monitoring and asynchronous interpretation job.<br /><br />Thanks for the feedback! Also, for those at <a href="http://www.eclipsecon.org/2009/">EclipseCon</a> have fun with your sessions!Nirav Thakerhttp://www.blogger.com/profile/07204297663478577248noreply@blogger.com0tag:blogger.com,1999:blog-11200164.post-43198818787205353292009-03-10T19:37:00.012-04:002009-03-11T20:55:20.117-04:00Improve your debugging speed with EVars Eclipse pluginUpdate: Added alternate link to screen-cast. Workaround to start plug-in<br /><br />I have been debugging a lot lately which included open source libraries, closed source web-service engine and parts of closed source application server (WebLogic). During this painful debug-fest I felt a strong need for several features missing in Eclipse (NetBeans as well, for that matter) . Debugging closed applications is a pain beyond imagination, even with IDE integrated decompilers, it takes incredible amount of patience and time to debug.<br /><br />To improve productivity (or prevent burnout), I jotted down a plugin to export/import live variables, filter variables view with a xpath like expressions etc. The plugin, called <a href="http://code.google.com/p/evars">'evars'</a>, features a small expression interpreter (similar to xpath) which can do a wonderful job of filtering variables on current stackframe. It also allows you to export variables to a file and reload them at a later point.<br /><br />For the first time, I have attempted to create a screencast to explain its usefulness. <a href="http://nirav.thaker.googlepages.com/evars.htm" target="_blank">You may watch it over here</a> [10mb non-streaming, 1275x860], <a href="http://evars.googlecode.com/files/evars.swf" target="_blank">alternate link</a> (open with your browser).<br /><br />I have also created a beta release to see if it finds any interest which you can <a href="http://evars.googlecode.com/files/name.nirav.evariablesview_1.0.0.jar">download it from here</a> [JAR ~800kb, Jdk6] (<a href="http://evars.googlecode.com/files/name.nirav.evariablesview_1.0.0-1.5.jar">Click here for Java 5 version</a>) and drop it in dropins folder [Eclipse 3.4+]<br /><br />If you find it interesting, please leave feedback here.Nirav Thakerhttp://www.blogger.com/profile/07204297663478577248noreply@blogger.com14tag:blogger.com,1999:blog-11200164.post-49402222181781136662009-03-09T20:05:00.000-04:002009-03-10T00:08:02.383-04:00Two types of ArchitectsI am amused by these creatures called 'Architects' in software development. In recent phenomena, They are available under numerous headings such as 'Software architect', 'Solution architect', 'Front end architect', 'Enterprise architect' and so on. To me, in what they really do, there are only two broad types of architects. My brain timed out while guessing fancy names for them so their description is in order with uninteresting machine generated type names, it is up to you to decide what to call them.<br /><br /><span style="font-weight: bold;font-size:130%;" >The Type1 Architect:</span><br />A Type1 architect lives near 'The well of Eternal dreams' in his tranquility. He speaks high of latest technologies, buzzwords from internet meme. He actively attends all expensive technology conferences, management meetings, and is excellent at presenting management with summaries of what he may possibly be capable of.<br />The ideal Type1 architect rarely talks to developer and/or QA teams, he doesn't really waste his time for trivial details and is religious about development-by-exception (don't stop coding/testing till you hit the roadblock); he would rather express his greatness with another Type1 architect who can really appreciate him. He is a huge fan of his super-mega automated, ultra-modern cloud-based, universally-ultimate end-of-the-world web 9000.0 ready architecture, which he thoughtfully insists in applying wherever it's not needed. His thinking is beyond languages, frameworks, platforms and business needs, no mortal can grasp what he thinks. He usually masters the skill of overkill and is full of without-the-box ideas. I can really go on for next few weeks talking about this type of architects but I need to talk about the other type so I will stop here.<br /><br /><span style="font-weight: bold;font-size:130%;" >The Type2 Architect:</span><br />This type of dude is a very simple earthliving guy, he lives by the belief that success of software development efforts is dependent only on the people who are involved in it rather than tools and technologies. He holds the shared vision of what the end product is likely to be and thrives at driving the team efforts in that direction <span style="font-style: italic;">without managing </span>them. He doesn't fear coding (more like the existing code fears for its life when he starts coding), testing or training whenever he needs to do it. He believes in pleasing management with frequent stable releases than presentation of the obvious. He communicates with everyone, right from tester to business analysts and managers frequently, this guy is often found roaming around discussing with different team members.<br /><br />So if you are an architect, what type are you?Nirav Thakerhttp://www.blogger.com/profile/07204297663478577248noreply@blogger.com2tag:blogger.com,1999:blog-11200164.post-72842797059535955762009-01-30T18:49:00.015-05:002009-01-30T22:36:04.068-05:00Formal grammars, parsing etc. for dummiesI thought it may be useful to post summaries of what I have <a href="http://books.google.com/books?id=4yVQFVvsBNAC&dq=engineering+a+compiler&printsec=frontcover&source=bl&ots=rbgQ1OvQHy&sig=CrE6Ecva7LK6uhBf1Mu_nL5ocpk&hl=en&ei=b7ODSYC7DIqhtwfzq5jICQ&sa=X&oi=book_result&resnum=6&ct=result">been reading recently</a>. In this post, I will try to explain some basic grammar and parsing stuff in as simple way as I can (omitting all the academic complacency) .<br /><br />A grammar defines a language with a set of rules of type x -> y, where x is left hand side of the rule and y is right hand side of the rule. x and y can be either expandable or literals depending on grammar type (math zealot? read terminals and non-terminals).<br /><br />Chomsky hierarchy defines four levels of grammar (although these are <a href="http://en.wikipedia.org/wiki/Template:Formal_languages_and_grammars">not the only grammar types</a> in literature but <a href="http://web.mit.edu/linguistics/people/faculty/chomsky/index.html">Chomsky</a> is cool dude in linguistic literature, hence the list):<br /><br /><span style="font-weight: bold;">0. Unrestricted grammar:</span><br /><br />Languages based on such grammar can have any rule for derivation (which usually means any text can belong to a possible unrestricted grammar like 'yo dawg', where 'yo dawg -> u'). However, it is possible to define a language with unrestricted grammar which is also Turing complete. A language based on unrestricted grammar is extremely difficult to parse, but not completely impossible. Such language doesn't necessarily make sense, e.g. It is possible to create a math expression such as this 1++1=1--*1=1 in an unrestricted language, as well as an unrestricted English statement such as this: "all your bases are belong to us".<br /><br /><span style="font-weight: bold;">1. Context sensitive grammar:</span><br /><br />A language defined with CSG may represent all the natural languages. Such grammar is defined with a set of rules where both sides may have expandable symbols (e.g. "a" B "c" -> "a" "x" "c"). It is very difficult to build a parser which can parse CSG.<br /><br /><span style="font-weight: bold;">2. Context free grammar:</span><br /><br />All programming language grammars are context free grammars. It can have only one expandable symbol on left hand side of a grammar rule and is very easy to parse. E.g. X -> "if" (y) z | "if" (y) z "else" (X), where y and z can be represented as other statements of the same grammar. There are several well known parsing techniques to parse CFGs such as:<br /><br />- LL(1)-LL(k) with a recursive descent parser (top down parsers with look-aheads 1 to k) and,<br />- Bottom up parsers such as LR(1) and LALR which can parse more CFGs than LL parsers (generally shift reduce parsers).<br /><br />LL parser starts with <span style="color: rgb(255, 0, 0);">L</span>eft to right and always expands <span style="color: rgb(255, 0, 0);">L</span>eft expandable symbol first (think of queue) where as LR starts with <span style="color: rgb(255, 0, 0);">L</span>eft to right but expands <span style="color: rgb(255, 0, 0);">R</span>ight symbol first (think of stack).<br /><br /><span style="font-weight: bold;">3. Regular grammar:</span><br /><br />A regular expression is a language defined by a regular grammar. It is represented as X -> "t" | "t" Y, where Y represents expandable symbol and always follows literal (if it exists). E.g. ab*, where * may be an expandable symbol defined to mean one or more occurrence of the literal it followed as a grammar rule.<br /><br />Each grammar type above is a subset of previous grammar type, meaning every regular grammar is context free grammar, every context free grammar is also context sensitive grammar and so on.Nirav Thakerhttp://www.blogger.com/profile/07204297663478577248noreply@blogger.com1