test post

test post

Yahoo, a sizeof function in Java

Finally, a possible addition to your logging arsenal.

A better way of calculating the size of objects since the early days of do-it-yourself-pseudo-calculations and using profilers is already part of Tiger (JDK 5.0).

With JDK 5.0, you can get size in two new ways without using expensive do-less-good profilers (why I say less is because, the programmer is still the best profiler) or native runtime-engine specific bridges:

java.lang.instrument.Instrumentation.getObjectSize API.

This class provides services needed to instrument Java programming language code. Instrumentation is the addition of byte-codes to methods for the purpose of gathering data to be utilized by tools. Since the changes are purely additive, these tools do not modify application state or behavior. Examples of such benign tools include monitoring agents, profilers, coverage analyzers, and event loggers.

getObjectSize() returns an implementation-specific approximation of the amount of storage consumed by the specified object. The result may include some or all of the object's overhead, and thus is useful for comparison within an implementation but not between implementations. The estimate may change during a single invocation of the JVM.

richard@work

Closer to an-all Java Desktop Dream

Tracking back to the my post regarding JDistro and other Swing developments, again, I see yet another compelling reason for me to convince my PHBs about decommisioning some, if not much, of our approach to User Interfaces. I really do believe that our DHTML-based approach will not scale and is not nimble and fast enough for mission-critical projects that we usually do.

Presenting to you, Flying Saucer, the latest of my Swing-based craze. This renders XHTML and CSS contents. Talk about RSS-fed blog-craze nowadays. The good thing with Flying Saucer is that it will allow close interaction and inter-operation of ultra-thin content with rich applications with Swing. With a rich-client based on Java, your application can be more adaptive to any standards: HTTP, WebServices, object serialization, RMI, etc. You can also treat your application in a cross-channel mode: standalone, as an applet, or as a WebStart service. Name it, you have it.

Now, let me collate some more and perhaps soon, we'll start our projects on a new user interface framework. That's all for now.

richard@work

Swing, Synthetica and Matisse

Javasoft Software Engineering release of new Swing look and feel is another plus to Swing. The new look and feel really are miles away from the usual Metal or Motif look. However, I got the sense of the Synthetica l&f as too Windows-XP-esque while the Blackstar reminds me of the soon to be released Windows Vista. However, regardless of its Windowish experience, I still feel that they could be the best and business-presentable Swing l&f ever.

Have you seen NetBeans 4.2 alpha sources lately. It has the new fabled Matisse. Don't know what Matisse is, kindly check on NetBeans site.

When I say I like Swing does not mean I love GUIs. I am still the text-based, CLI, server-side maniac. Why I promote Swing is because IMHO, HTML cannot scale to the needs of mission-critical over-the-internet/intranet applications. Yes, we have the AJAX approach but, AJAX has its flaws, one of them is performance. Couple your souped-up net-enabled Swing-based application with Java WebStart and your ready to go. One tough nut to crack compared to HTML over HTTP.

richard@work

Is C# Dead?

Is C#, the much touted Java killer from the Redmond giant, dead? In my opinion, it is. C# was invented to halt C++ developer's migration to Java. C# was meant to keep people to COM/DCOM-based .Net. Just go to your neareast bookstore and compare the books for Java and C#. Compare C# and Python/PHP/Perl for that matter. It is clear that C# is in lost ground.

But did Java really kill of C#. Nope. The C# killer is none other than Open Source. Well, here's the rationale. The Java language, alone will not be able to compete with the much user-friendly C#. But the truth is, why do enterprise have to buy nasty licenses when they can go at an enterprise-level perormance on a lot-cheaper alternative, that is, Open Source. In Java, you have JBoss, you have SJAS, you have Jonas, you have Apache, name all of it, you'll have it. What you pay for (in case of the commercialized open-source Java EE server) is the service, not the product. After getting the product, you don't own the code. Noone owns the code. You can play around it, you can modify it. With the advent of non-GPL OSI-approved licenses, any OSI-approved license (except copyleft-leaning GPL) is commercial friendly.

One notable thing to consider why .Net will screech to a halt will be the other players Mono and the LAMP stack. Why, even Microsoft is courting OSDL for a joint R&D, right? So the conclusion is that Open Source is the way to go. It is in competition in collaboration that will dictate the future IT industry fight. Until then, I am still and will always be for Java.

Have a break, have a cup of Java.

richard@work

DAO Code Generator

Free DAO (Data Access Object) Code Generator
— DAO Code Generator can be used for J2EE applications to generate high quality source code for the Data Access Layer in service-oriented and object-oriented architecture for accessing relational database schemas. DAO-Generator follows the Data Access Object(DAO) design pattern and generates java code. Current Version of this tool supports Oracle, MS Sql server, MySql and PostgreSQL databases to connect and generate code.

Just makes me wonder how un-DAO our DAO is... :( I am wondering when can I replace our ORM (aka DAO) with JDO?

richard@work

Current state of GCJ

GCJ is the Java compiler component of GNU's GCC.

So where is GCJ now? Probably, still not enough to catch with Sun's JDK. When at least full-1.4 compatibility is released, I'll be one of the first ones to jump ship.

• java.applet - Believed to be complete, but note that without a functional AWT it isn't very useful.


• java.awt - A lot of code exists, but not enough for use in real applications.


• java.beans - Believed to be functional and complete, should be compatible with JDK 1.4.


• java.io - Ok.


• java.lang - Ok.


• java.lang.ref - Ok.


• java.lang.reflect - Ok. Does not check access permissions.


• java.math - Ok.


• java.net - Ok.


• java.nio - The public interface is ready, but the implementation is not working yet.


• java.rmi - Ok.


• java.security - Code exist; completeness unknown.


• java.sql - Ok, should be compatible with JDK 1.4.


• java.util - Ok.


• java.util.jar - Ok.


• java.util.regex - Ok.


• java.util.zip - Ok.


• java.text - Ok, but most localization data not available.


• javax.accessibility - Some code; status unknown.


• javax.crypto - We recommend using GNU Crypto.


• javax.naming - Complete, but no providers written.


• javax.sql - Some code; status unknown.


• javax.swing - Some code, but not enough for real applications.


• javax.transaction - Complete, but no providers written.

Hmm, when can we finally set Java free. When can Java be fully open. So far, it is in a use-at-your-delight-and-risk thing.
Cheers!

richard@work