Java IO fundamentals

I am usually questioned by friends regarding Java IO. Questions usually revolve between byte and char conversion and what determines the codepage used. My answer to them is always the same: if you are using Streams you are dealing with bytes and if you are dealing with Readers and Writers then you are dealing with Chars (usually you specified codepage to be used or it is using system default). I usually tell them to distrust any class named SomethingStream that have any method that operates over Strings (eg.: ServletOutputStream) cause they’ll usually do some implicit conversion (either using system codepage or something else out of your control).
I’ve prepared a diagram to clarify the main Java IO classes (and their main methods also):

Basic Java IO Classes

On the bottom you’ll find Stream classes, they operate on bytes so codepage here is irrelevant. In the middle you’ll find conversion classes: those are the ones that allow you to forcefully define a codepage, they are the bridge classes that allow you to plug a Writer on an OutputStream or a Reader on an InputStream. You may use them to specify, for example, a codepage for writing on a TCP socket. And lastly, on top, you’ll find Character (and therefore String) oriented classes: Reader and Writer.
You may have noticed that I have included the Buffered version of the Stream classes. The Output one provides better performance under certain scenarios. The BufferedInputStream on the other hand allows you to mark and rewind its content, something usually useful for implementing protocol interpreters.

Android Adapters

I’ve been fooling around with Android for a couple of weeks... I bought a Motorola Milestone, downloaded the ADT plugin, a few device images and started reading and coding…
I have to admit that the Android Architecture has some ingenious points, one example is the idea of having one process (a Dalvik VM instance) hosting both application activities and also its services but this will be subject for another post (android.os.Looper and Handler are worth mentioning too).
Getting back to the reason for the post…

Android Adapter vs Swing TableModel

Having once used Java Swing Toolkit my first impression when I saw Android SimpleAdapter was that I was seeing a DefaultTableModel sibling but the reality was that I couldn’t be more wrong!
Android Adapters and ListViews are more similar to Java’s c:forEach tag (Yeah, I know… probably you thought I would use a Swing metaphor but I couldn’t think of one) since it does not impose a resulting Widget, it is up to the Adapter getView method to determine which will be the rendered View instance. Swing’s TableModel only determines the content that will be displayed but it can’t redefine the UI component JTable uses. This responsibility on Swing is delegated to JTable getDefaultRenderer method.

Android SimpleAdapter

Android’s SimpleAdapter employs a rather simple yet smart strategy: you handle it Composite component ID that will be displayed for each row of a List of HashMaps. The mapping of each subcomponent from the composite component is performed by two Arrays that are also passed at SimpleAdapter construct time. These arrays maps the Keys from the HashMap into the subcomponent IDs.

SimpleAdapter drawback

What I sincerely miss with the SimpleAdapter approach is a more direct mapping between domain objects and the ListView. The developer ends up coding a plumbing code that moves data from Domain Objects into the HashMap and this code easily violates the DRY principle.
Although reflection poses a performance penalty I’ll try to see if a ReflectionAdapter based on SimpleAdapter is a valid alternative.

Designing Glassbox Tests and Failure focused Tests using Byteman

There is one thing that always intrigued me, the absence of tools that supported the design of GlassBox tests and tests that focused on failure scenarios up to the point that I ever thought about starting my own open source project but recently I stumbled upon Byteman project from JBoss.
The project description on the project site states that Byteman is:

Byteman is a bytecode injection tool which simplifies development of tests for Java applications using a technique called fault injection. Byteman works by inserting scripted side effects into application code, Test scripts may include actions which create and propagate conditions appropriate to the test scenario. Or they may simply verify correct execution of the application program.

Byteman has a good list of pros:

• Powerful Scripting Language
• Possibility of adding and updating the Scripts for code modification at runtime
• Simple Java class for uploading scripts to a running JVM which makes it easy for integrating script updates into a JUnit test

I started to test the tool today and I can say that the first impression was incredible. I agree that the scripting syntax may improve a little (eg.: every rule has to have an IF what forces you to use IF true sometimes) but this can’t be considered an impeditive problem.
I’ll try to post here some examples of its usage.

Mapping JavaEE and .NET stack components

Recently I started to research how to develop on .NET as I’ve been developing for JavaEE.
First thing that came to my mind as a JavaEE architect was: “Okay, IIS and ASP.NET are some of the presentation tier alternative I have for .NET but what for business tier?” or rephrasing as someone that has
been using JavaEE for a long time: “What would be the .NET EJB?”.
First thing I missed was the concept of the MDB that in .NET stack that seems to be replaced by an MSMQ message trigger.

Another major .NET difference is that even though it seems to have the concept of the VM process (as Java does) it has the concept of a shared library, or the Global Assembly Cache. If you think in terms of Java then you have to either manually replicate the jar or share them using a shared storage and having it on the classpath.

As we are on the classpath subject, .NET and its CLR seems to avoid (and limit it to J#) the concept of a ClassLoader. Although sometimes problematic, the Java concept of the ClassLoader allows very sofisticate scenarios of application composition and also for hot code generation (by the application) at runtime.

I hope this post has helped anyone in the situation as I were before and I also hope it does not sound as a comparison of which platform is better as you might guess that I sincerely know that each one has its applications, strengths and weaknesses.