Java Programming Exercise
Home Tutorials Reviews Weblog

Review: Here is a Java Programming Exercises
Feature: It is designed to illustrate tools, books and design approaches all at once


Java is becoming so pervasive with very strong showings on the server, growing use on the desktop - especially for vendors that want instant cross platform delivery. Even Web pages are getting more and better options from Java with JSP, then JSF and now JavaFX available including mixed solutions coupled with AJAX. However, given that diversity there also comes some measure of complexity as the display code and data reference logic that is put in place for say Web applications differs mightily from that used for desktop or mobile applications. So the advantage of write once, run anywhere though miles ahead of Microsoft .NET (or Apple's App Developer for that matter), is dissipated because of the need to write different code depending on device, delivery system or mode of operation.

Just as Physics is looking for its Grand Unified Theory that will bring the gravitational, electro-magnetic, weak nuclear, and strong nuclear forces into a single complete model, IT is looking to bring its four major development paradigms - 1)user interfaces and interactions, 2)data persistence and integrity, 3)resource mapping and monitoring plus 4)process scheduling, sharing and workflow control into a unified development approach. That approach is intended to finally deliver systems that are not only functional but also flexible and adaptable to constantly changing needs and requirements. The intent is not only to be able to deliver working systems with a high success rate but to be able to maintain, adapt and even re-use large portions of those systems in new and evolving contexts. Finally such an approach will be judged not only by its success rate but also by its ability to minimize wasteful overlap, avoid fragility to attack, and yet still be agile in modification and maintenance.

Currently SOA is being offered as the IT framework that will deliver this unified development approach. And it certainly does a good job on aspects of the problem - particularly resource mapping plus process scheduling, sharing and workflow in a more unified fashion. But SOA stands almost silent about the user interface and interactions, always subsumes everything into its XML framework without utilizing alternative methodologies and has a mixed record on specifying and supporting the metadata necessary to supply a robust control and reuse infrastructure. So if you think SOA governance is tough to do - what happens when SOA Provision does not have the scope to carry the load.

So these exercises, while touching on very specific Java problems , will also be attempting to relate the issues encountered to this broader, grand unified theory of development. But also I will attempt to point to books, articles and tools that attempt to address these issues. And then, more than occasionally, I shall attack a problem for the sheer interest of it and/or my need to know how exactly this is done within Java.

Creating a Math Class Extension: parsedFloat()

This Java Exercise involves creating a Math class extension parsedFloat() using Stringbuffer instead of the String primitive. The exercise was prompted by 3 things:
1)the need to understand what could be passed by name versus by value into a Java method;
2)the need to work with StringBuffers/StringBuilders to avoid memory overload of Strings;
3)the need to create a parsedFloat counterpart to parseInt().
Let consider the each of these factors. First, the excellent book Head First Java by Sierra and Bates points out on page 661 that Strings are immutable - once assigned to, a String cannot be changed by concatenation, insertion, or deletion - instead the old string is replaced by these operations as a completely new memory assignment while the old string is left in memory but being immutable is retained for the remainder of the session. If your program does a lot of string manipulations with concatenations, insertions or deletions, the resulting memory bloat can be substantial.

To avoid this wastage of memory use Java's StringBuffer or StringBuilder classes. The two classes are nearly identically the same in methods supported with the notable difference that StringBuffers are thread-safe and StringBuilders are faster. I chose to stay thread-safe in this example and used the StringBuffer class. For more details see Sierra and Bates page 669.

Now the second problem involves passing parameters into parseFloat(). I want it to return three values - 1)the value of the numeric field, if any, as a floating point number, 2)the number of characters left to parse in the StringBuffer strinb parameter, and 3)strinb also passed back and truncated of the numeric field so that I can parse the remainder straightforwardly elsewhere.

This requires a quick review of parameter passing in Java. All the primitive data types like boolean, int, float, etc are pass by value. This means that substitute values are placed into the parameters before calling the method which prevents any changes to primitive datatype parameters like int and double inside the called method. But this is opposite of what I want. For example I want the parameter leftover to tell me how many characters are left over in the string after parsing. However, to the rescue is the fact that objects are passed by reference, so any changes made to them in the called method are also "returned" to the calling method(in point of fact the same memory is referenced in both methods - so the object if changed will be passed back - so just make leftover an Integer object.

So the following code creates the desired ParsedFloat() routine - well sort of.

Now there is a problem with this routine. The wrapper variable, Integer left, despite being an object, also like Strings turns out to be immutable. It can't be changed once assigned to. So there is no convenient way to pass back changed primitive parameters like int, Integer, float, Float, etc in a Java method. Now why Java designers chose these design characteristics is a mystery to this party (I have done the appropriate Google search for why - no luck so far). As Jacquie Barker points out in her excellent book on Java Objects(page 352-3), wrapper classes like Integer and Float are vital to Java containers class usage. So this is sort of a Java conundrum like why Java class and package identifiers are tightly coupled to file and directory names respectively - another piece of "why-for-art-thou" that diminishes Java's usability.

Finally let us consider the use of the two static methods, isnum() and parsedFloat(). There is a disadvantage to static methods, you cannot use either instance variables or methods from which the class static methods are contained in (class floats in our example). But that turns out to be no real burning restriction. Since class floats does not have any non-static methods or refernces to class variables except as passed legitimately as parameters. The personal advantage to me is that I have a big myutils.jar file filled with my frequently used static methods similar to Java's own Math class. These are routines that are cross class in nature - a shortcut to full blown AspectJ-type programming.

Meanwhile anybody who can do the following:
1)point out an efficient way to pass primitive types as changeable parameters in Java;
2)can cleanup the hideous switch statement in parsedFloat() ;
3)and can add exponent recognition (1e+10 or 9.9e-3 or 0.066e2) to the routine ;
will get a copy of the Head First Java book plus their solution published on this site. Send solutions here.

So what have we learned ? Last first, it is fairly simple to create a parsedFloat() counterpart to parseInt(). Second, static methods have there place in Java usage. Third, a little bit about StringBuffer/StringBuilder usage as substitute for Strings. And last but not least, passing parameters in Java are simple, maybe too simple.
Top of Page  Home  Tutorials  Developers Weblog  Graphics Reviews and Tips