Improving gwtClassRun using NanoXML

gwtClassRun is definitely not standing still. It is currently undergoing improvement in term of architecture and added features in slate of its final release of version 1.0. One of the major changes involve replacing XML file processing by NanoXML , a extremely compact Java XML Parser. Current release of gwtClassRun is using plain string manipulation for processing gwt.xml file which make it less scalable and flexible. By using a XML Parser, the code is more maintainable and extensible. Apart from this, gwtClassRun will include option for JavaScript Obfuscation and for turning off sound. So stay tuned…

There is a post on NanoXML,

The proliferation of XML for data interchange and configuration file format have resulted in numerous open-source Java XML Parser libraries (left image). Indeed, Java includes its own full-fledged XML library obviating the need to download additional XML library. However, the in-built and majority open-source Java XML Parsers tend to suffer from few major problems ranging like complexity and bloated size, and this tend to be normal rather than exceptional. This is because the majority of  Java XML Parsers are designed for enterprise usage and therefore the latest XML technologies like XPATH, SCHEMA are integrated into the libraries resulting in increasing sophistication and bloat. Moreover, most of these libraries actually reuse additional external libraries which greatly increase its size and complexity and prohibit its widespread usage in development of desktop and mobile applications (majority of open-source projects suffer from poor documentation and support). In addition, the large library size and overwhelming complexity are just overkill if one just want to use XML in rudimentary way (like configuration file, data download through Web 2.0 service eg Amazon). Therefore a simple and easy-to-program solution is needed if one want to deploy a mobile, applet, desktop solution that will be downloaded and deployed.

Continue at GeekyCoder’s blog

Resolving memory leak in GWT

While using gwtClassRun, users are likely to encounter problems while repeatedly refreshing the GWT browser. This is likely due to a memory leak in GWT. After several iteration of refresh, GWT’s browser complains of insufficient memory to run the application. Unfortunately this problem cannot be resolved completely rather it can only be alleviated. Either users have to enlarge the pool of memory available to GWT or rerun (Close and Rerun) the GWT browser.

At times, it will be more efficient to just assign it more memory so that browser can refresh properly rather than keep restarting the browser which incurs longer waiting time. To reduce the occurrence of insufficient memory due to memory leak, just increase the memory available to GWT. It will at least allows several more Refresh before user need to close the browser and rerun it.

Here’s how:

In a IDE’s configuration for running GWT application, add the VM parameter with

-Xmx128m

This means setting maximum heap memory available to a application to 128mb.

More info http://edocs.bea.com/wls/docs61/perform/JVMTuning.html

Developing gwtClassRun as a IDE plug-in

Most popular IDEs are built with modular structure using plug-in which make it easy to control and manage.

Plug-in in Intellij

Plug-in in Netbeans

gwtClassRun as a application works outside the IDE but communicates through a common resource (module descriptor file).

Possibly some will ask why not develop gwtClassRun as a IDE plug-in/extension as now it is a popular trend to develop plug-in that work within the IDE leveraging on the environment like auto-update. Initially, the gwtClassRun conceived as a plug-in only to be redesigned as a application.  There are many decisions to consider before starting development. In gwtClassRun, among the major consideration includes the ease of IDE plug-in development, time constraint and possibility of porting and extending this feature to other popular IDE. It might be cool to learn and hack new stuff however learning a API takes a lot of time and commitment even though the marketing material will say it otherwise. For example, learning Intellij’s plug-in development takes time to explore and see what possible. In fact, the real thing starts only when one relies on the forum for support rather than on supportive documentation. There always a great contrast between understanding and doing something.

 

So my reasons for developing gwtClassRun as application:

• time constraint. It costs in term of time and resource to learn something new that does not warrant the investment. Leverage on existing Swing development expertise and experience to create the application as fast as possible.
• Plug-in development takes too much effort and commitment.
• Work with any IDE. Most IDE now having option to automatically detect and accept external changes to file.
• Swing is cool. Contrary to many belief that Swing is bloated, slow and difficult to master, Swing has improved tremendously in term of raw performance. However it takes practice and commitment to learn a flexible and powerful GUI toolkit like Swing just like any other good tool. Once pass that hurdle, Swing can do wonders and amazing thing. I actually prefer to develop Swing application than web application because the full power of desktop capability and function are available without the constriction of by the web technology, and this is done so without using patch or workaround.
• Not affected by major change in IDE. Compatibility issues with plug-in arises when IDE introduce or revamp plug-in architecture, and this will cause plug-in to malfunction, and new version of plug-in must be developed to address the compatibility.

 

So what’s not with application design:

• no doubt that designing as a plug-in means it knows the current state of IDE since it becomes part of IDE itself. This means that the plug-in can be more intelligent in automating task. For example, the plug-in can detect the active Java Source Window and check if it implements EntryPoint interface, if it does, the plug-in will enable the option of Running the Java Source in context menu or in toolbar, and this is done without user’s intervention. Whereas in application, gwtClassRun does not know about the state of IDE and therefore relies on user to inform it by manually update the database or to switch project manually.
• Not tightly-integrated with IDE.
• Duplicate some features that already exists in IDE. eg AutoUpdate

Logo design and naming of gwtClassRun

The logo is designed on 16 May 2008 around 9:30am and it takes several paper prototype within a hour to come out this design.  The original design comprise of just purely text and is plain ugly. My intention is to deliver a working gwtClassRun first with all the functionality tentatively then spend some times along the way to spice up the cosmetic. Unfortunately, the logo is just too plain ugly to ignore. So how did I come such design ? This design is developed using Xara Studio which offers a real time view of graphics manipulation and effect. Due to unfamiliarity with the tool forces me to think out a simple and easy design that can be quickly mock up with the tool. So it begin by experimenting with Xara’s tools and find that it is intriguing to use circle within circle as logo.

This is how the logo is been interpreted. It requires some creativity and imagination but never mind, this is okay for me as I love to day-dream and wander my mind to lalaland . Each class is represented as a circle. Any Java application is actually comprises of many classes of various complexity and composition, and so one class ‘compose’ the other as depicts in the logo. And been circle means that it rolls fast just like a wheel. It runs like a wheel as metaphor and therefore Runnable class is EntryPoint class. Yellow gradient is used because Yellow is light and non-threatening, and it mix well with the gwt text. gwt text is placed there to indicate these EntryPoint class circle representative is pertaining to GWT. gwt is lowercase because it syncs with name gwtClassRun.

So how does the name gwtClassRun evolves ? In fact, this no brainer as it is about EntryPoint class execution, therefore it is easy to come out a list of name initially like

GWT RunClass

GWT ClassRunner

GWT ClassSwitcher

GWT ClassSwitch

ClassSwitch might reflect what it does accurately however it just too long and seem weird with two W. gwtClassSwitch.

So in the end gwtClassRun wins because it is shorter, fluent and easier to understand. The lowercase of GWT comes about as I surf the net to seek inspiration from existing artwork that pertain to GWT like extension eg. I came across gwtExt and it seems to me that such lowercase single-word naming is prevalent for product relating to GWT. Hence, GWT ClassRun becomes gwtClassRun, and I really like the new name. Capital letter words are somehow distractive and too standout. Since GWT is already so popular, why not give other product name visibility ? So I guess putting gwt as lower prefix really is attractive and suitable.

gwtClassRun unveiled….

Demonstration of gwtClassRun

After weeks of development  and preparation in the midst of other commitments, gwtClassRun ,  as a side project,  is finally released in beta. The work begin on 24 April 2008 after around the week I suggest a proposal entitled Improving the development experience of Google Web Toolkit to propose a better way of building GWT application by making it easy to run a EntryPoint class so as not to consume too much time testing unnecessary integration. This is particular relevant as the compilation and execution times increase as GWT application becomes larger subsequently. So to manage the expectation, it might not be feasible to continue to rely on GWT team to improve the performance because each version of GWT takes few months for improved releases. Thus a viable option is to break GWT application down in each testable class that faster to test and perform integrated testing when necessary.

The proposal suggests that a “executable” GWT class is identified with its own main method similarly to a normal Java class that executed by a JVM. This required a standard method call that support across IDEs and the probability of such support is slim as it requires too much too work to gain such rapport. Before this, the use of EntryPoint is considered as a replacement for main method however GWT supports multiple EntryPoints , and there is a possibility for developers to depend on the order of EntryPoints for Initialization, and probably end up creating more problems than it solves. AFter playing around with gwt.xml descriptor file and understand it better, I figure that it just be easier and more effective to make use of EntryPoint tag so as not to introduce complication and unnecessary changes to GWT’s way of working, and maybe that’s what GWT team is thinking all this while.

After weeks of experimentation, development and testing, gwtClassRun is done as bug free as possible. The initial platform is Windows, and if reception is good, likely to port to other platform like MacOS and Linux. Since this application is written in pure Java without using any native OS call, the port shall not impose too much change. What is more problematic is probably file and directory handling. Anyway, gwtClassRun is officially released as beta test today and just have to wait and see how other GWT developers respond to it. In the mean time, I will take a good rest to day-dream and continue further work on other remaining projects that will be released in GeekyWare.

Welcome to GeekyWare

This is my first welcome blog for GeekyWare. So what is exactly  GeekyWare ? To cut it short, GeekyWare is the site where I will distribute and support self-developed free software. GeekyWare is my first ‘experiment’ to leverage on WordPress’s capability and WordPress.com’s infrastructure by harnessing its strong blogging feature, widget support and generous free storage to build and market my own brand of software. My objective is to encourage and to demonstrate the use of blogware to support the product and aspiration of a software developer. I foresee a long challenging route ahead but the experience and learning make along the way will surely make the journey worthwhile.

As you can see, the site is still undergoing construction. There are still lot of things left to be done in setting up a software site. Things like logo, site design, site feature, and all sort of things that are essential for positive user experience. Nonetheless, I taking it one at a time to make sure that things aren’t too rush. A journey start with a single step. Yes, everyday feels like a journey, and each journey needs to be broken down into short achievable destination so that one can feel a sense of achievement frequently to persist on.

So what kind of software am I developing ? For a start, desktop productivity application that I myself will find dispensable and time-saving. If it save me time, it will probably save yours too. Talking about eating own dog food !

So stay tuned for exciting software coming your way . This day 4May2008 will be remember as the day GeekyWare is born officially