Ivaturi's Java Blog

2004-05-14T02:54:00.000-07:00

These are Good to share -----

Friends may b old. friends may b new but real friends r very few,So
whenever u r lonely,Remember its true... Someone at some where, is
thinking of u...missing u
****************
If u love some one its nothing ,if someone loves u its something but,if
u love someone n someone also loves u its every thing.
*****************
life ends when u stop dreaming, hope ends when u stop believing, love
ends when u stop caring.. friendship ends when u stop sharing.. so
always be in touch my friend!!!!
**************************
A girl asked a guy if he thought she was pretty, he said...no. She
asked him if he would want to be with her forever....and he said no.
She then asked him if she were to leave would he cry? and once again
he replied with a no. She had heard enough . As she walked away, tears
streaming down her face the boy grabbed her arm and said....You're
not pretty you're beautiful. i dont want to be with you forever. i
NEED to be with you forever, and i wouldnt cry if you walked away...
i'd die...
******************************
A Guy & a Girl can just be frends but at one point of time they will
fall 4 each other....May be temporarily ,may be at wrong time,may be
too
late or may be forever...
*******************************
Someone asked me how much i miss u .I said ::Try catching raindrops,the
ones u catch is perhaps how much u miss me & the ones u miss is how
much
i miss u..
**********************************
If kiss was a raindrop, i'd send u showers .If hugs were seconds ,i'd
send u hours.If smiles were waters, i'd send u the sea.If frendship
was
a person i'd send u me..
**************************************
Kisi ki chahat pe jinda rehane wale ham na the,
kisi par mar mitne wale hum ne the,
aadat si pad gayi tumhe yaad karne ki, warna kisi ko yaad karne wale hum

naa the..
*******************
Heart beats are countless...spirits are ageless...dreams are
endless...memories are timeless...a friend like u priceless.
*************************
Sirf chahne se koi baat nahi hoti, Suraj ke saamne kabhi raat nahi
hoti, hum chahte hai jisse jaan se bhi jyada, woh saamne hai par baat
nahi hoti .
***************************
muskuraengi ankhen firse rone ke baad ... subha ayegi sham dhal jane ke

baad...
oh jane wale zara mudke to dekh ...shayad ye zindgi na rahe tere jane
ke
baad
***********************************
If u ask me that how long i'll be ur friend, I'll say i don't know....
caz i really don't know whichone is long... FOREVER or ALWAYS...
*************************************
Maana Hum Izhaar Nahi Karte Maana Hum Ikraar Nahi Karte Magar Yeh Mat
Sochna `Pagal' Ki Hum Pyar Nahi Karte
*************************************
u know y GOD created gap b/w fingers...so tat on some day the one who
is
made 4 u comes and fill those gaps by holding ur hand forever.
**********************************
Life is 4 u, death is 4 me, being happy is 4 u, being sad is 4 me,
being together is 4 u, being lonely is 4 me, everything 4 u but u r 4
me.
***********************************

yaad karo ya na karo, ham gila nahi karte, Virane me phool kabhi nahi
khila karte,
magar itna yaad rakhna e janeeman, mujh jaise aashik bar bar mila nahi
karte
***********************************

Nigahen aapki pehchan hain hamari, muskurahat apki shan hai hamari,
rakna hifazat ap apni, kyunki saanse apki jan hai hamari
***********************************

ab to tumhi se pyar karne ka man mene bana liya, kal sapne mein dekha ke
tumko pa liya, mujhe bhool na jana ae humsafar ke ab ye dil humne tumse
laga liya
***********************************

Doori na rahe koi humme tum itna karib aa jao, pyar karunga tumhe sabse
jyada, meri jaan meri bahon mein aajao.
***********************************
Shaam dhali phir kaali raat aayi, dil dhadka phir tumhari yaad aayi,
aankho ne mehsoos kiya us hawa ko,
jo tumhe chukar hamare paas aayi...
***********************************

Koi shaam aati hai tumhari yaad lekar, koi shaam jati hai tumhari yaad
dekar,
hame to us shaam ka intezaar hai jo aaye tumhe saath lekar...
***********************************

2004-05-05T21:17:00.000-07:00

Got Gmail account. It is great to have 1GB space with clean and friendly environment.

2004-02-02T22:47:00.000-08:00

About Methods

Even 20 to 25 lines is a bit long. There are many reasons that your average method size should be considerably smaller. One to twelve lines is a better goal.

Some benefits (these are a few off the top of my head):

Maintenance costs. The longer a method, the more it will take you to figure out what it does, and where your modifications need to go.
Code readability. After the initial learning curve, smaller methods make it far easier to understand what a class does.
Reuse potential. If you break down methods into smaller components, you can start to recognize common abstractions in your code. You can minimize the overall amount of code dramatically by reusing these common methods.
Subclassing potential. The longer a method is, the more difficult it will be to create effective subclasses that use the method.
Naming. It's easier to come up with appropriate names for smaller methods that do one thing.
Performance profiling. If you have performance issues, a system with composed methods makes it easier to spot the performance bottlenecks.
Flexibility. Smaller methods make it easier to refactor (and to recognize design flaws, such as feature envy).
Coding quality. It's easier to spot dumb mistakes if you break larger methods into smaller ones.
Minimizes the need for comments. While comments can be valuable, most are unnecessary and can be eliminated by prudent renaming and restructuring. Comments that restate what the code says are unnecessary.

Downsides (maybe):

Initially it's harder to work with code with lots of methods. Over time, however, you will see well-composed code as having greater clarity.

Myths:

Performance. You rarely create performance problems with more methods. If you do, it's very easy to inline methods. The rule of performance is always: make it run, make it right (e.g. small methods), make it fast (optimize).

Caveats:

It's difficult to do, but you can go too far. Make sure each method has a valid reason for existing; otherwise inline it.

2003-12-15T21:28:00.000-08:00

One could learn the Java keywords with a poem

Abstract boolean, break the byte!
(break the scheme)
Case and catch and "char" with class!
(have your own style)
Const continue, default do.
(don't be like the others)
"double else" extendS final

(thinking twice make things harder (?))
(remember to pronounce the S here)

Finally, float for goto
if implementS import
(if you need a strong programming implement, rebel and try "goto" (this is ironic,of course. Pronounce the S here, don't forget))
instanceof int: interface
(talks for itself)
Long native? New package!
(Change old traditions for new technologies)

(now it comes the superhero saga part)
"Private Protected Public" return!!
(in part I, Private Java protected the public classes city. Now, the saga continues)
Short, static, strictfp
(a description of his braveness fp: firm precission (?) )
super switch synchronized this
(?)
throw, throws transient
(?)
try "void, volatile" while assert
(He can dissapear)

What do you think? No... please don't tell the truth.

Courtesy: JavaRanch

2003-12-14T20:23:00.000-08:00

http://java.sun.com

Good to see Gosling photo on Header and Navigation changes gives more accessibility to developers...

Seems Gosling has changed the UI :)

Sun is trying to reach developers... they kept the Developers Home Link.

2003-12-12T06:38:00.000-08:00

http://today.java.net/pub/a/today/2003/12/11/mvc.html Beyond MVC: A New Look at the Servlet Infrastructure

2003-12-10T20:17:00.000-08:00

http://www.moelholm.com/

This has Mock Exams, Exam Docs for SCEA, SCBCD.

2003-12-10T20:00:00.000-08:00

JDJ SPECIAL - Answered: The J2EE Questions No One Else Dared to Ask

http://www.sys-con.com/story/?storyid=38149&page=2

There are some interesting answers for the questiosn asked.

2003-12-09T05:39:00.000-08:00

Implement JSP custom tags in five easy steps: http://www-106.ibm.com/developerworks/java/library/j-pj2ee8/

A good article on creating JSP CTLs.

2003-12-08T20:52:00.000-08:00

Top 20 Replies by Programmers when their programs don't work..:)

20. "That's weird...."
19. "It's never done that before..."
18. "It worked yesterday."
17. "How it that possible?"
16. "It must be a hardware problem."
15. "What did you type in wrong to get it to crash?"
14. "There is something funky in your data."
13. "I haven't touched that module in weeks!"
12. "You must have the wrong version."
11. "It's just some unlucky coincidence."
10. "I can't test everything!"
9. "THIS can't be the source of THAT."
8. "It works, but it hasn't been tested."
7. "Somebody must have changed my code."
6. "Did you check for a virus on your system?"
5. "Even though it doesn't work, how does it feel?"
4. "You can't use that version on your system."
3. "Why do you want to do it that way?"
2. "Where were you when the program blew up?"

And the Number One Reply by Programmers when their program doesn't work:
1. "It works on my machine."

2003-12-08T20:45:00.000-08:00

http://www.javarss.com A one-stop link to all Java News, Articles, Blogs.

2003-12-02T20:25:00.000-08:00

In enterprise shops, Java and .NET is more like it

Excerpts from this Article
1. For smart clients, .NET rules.

2. Java is the way to go for large-scale, multiplatform integration at the back end.

3. In terms of development tools and ease of use, .NET is No.1.

4. As for security, Java running on Linux or Unix is a better bet than the .NET languages on Windows.

5. Apart from those I belive Time to Market.

A must read one article for all Developers who really fight Java Vs .NET.

2003-12-01T22:39:00.000-08:00

Aggregate - Entity Bean Notes:

§ Entity beans represent the distributed persistent business objects.
§ We access Entity beans via remote interfaces.
§ Object granularity is very important what to implement as an Entity bean.
§ Entity-Beans should represent the coarse-grained objects.
§ Coarse-Grained objects will have the dependent objects.
§ Dependent Object: An object with no real world - meaning when this object is not associated with the Independent/ Coarse-grained Parent Object.
§ Impact of Fine-Grained design
o Inter-Entity Bean relationship
o Impact on Manageability of Code, Classes that are generated
o Network Performance
o Database Schema Dependency
o Impact of Object Granularity
§ The solution to the above impacts are Aggregate Entity Bean
o This contains set inter-related persistent objects.
§ Persistent Object: An object that is stored in some type of data store. Multiple clients share persistent objects. There are two types of persistent objects
o Coarse-grained: This is self-sufficient, and has its own life cycle and manages the reference with other objects. So the Coarse - grained objects maintain the life -cycle of these objects, so these are called dependent objects.
o Dependent: A self-contained object, which may contain other dependent objects.
§ Two types of strategies to implement Aggregate Entity Bean
o Aggregate Entity bean holds the reference to the Coarse-Grained object.
o Aggregate Entity bean it self as a Coarse - Grained object.
o Lazy Loading of Dependent objects in ejbLoad()
o Aggregate value object strategy
§ Consider dependent Object as Enterprise Bean
o If the dependent object appears to be depending on two different parents
o If the dependent object is already exists as an entity bean/ imported from other application.
§ Don't use Entity-entity relationship, Instead of that start using session façade.

2003-12-01T21:41:00.000-08:00

http://www.leocrawford.org.uk/work/jcea/part1/index.html#general A good link for SCEA

2003-12-01T01:15:00.000-08:00

http://www.c2.com/cgi/wiki?EjbRoadmap
EJB Raod Map contains all EJB related stuff

2003-11-30T23:34:00.000-08:00

http://www.theserverside.com/resources/article.jsp?l=MavenMagic Maven Magic

2003-11-30T21:53:00.000-08:00

Encapsulation or Representation

Several engineers are building a complicated software system together, and naturally, they are trying to figure out how to divide the work up. There are two different strategies that they can take.

Encapsulation. The engineers can agree upon the "behavior" they must build and the "behavior" other components of the system must support.
Representation. The engineers can agree upon the "data" they are allowed to produce and the "data" they need to consume.
In the abstract, you can approach any architectural division either way, although in practice usually one way fits better than the other. How can you tell which one is right? Let's take a look at an example.

Order Management by Encapsulation

Suppose you are building an order management system for a car-repair shop. Then the idea is that you have various "orders" that go through the system; each order has information about the customer, the request, the price, and so on. Similarly, there are several different things to do with an order, such as displaying them, submitting them for execution, and closing them out when they are done.

One way to divide up the work is to encapsulate the behavior or an "order" object as a formal interface, and then leave it up to the different engineers to implement the order objects using whatever data representation they choose. In this classical, often-advocated object-oriented approach, the process begins with the engineers deciding, for example, that an "order" object is just a bit of running code that supports a formal interface:

interface Order
{
show(); // present the order to the user for editing
submit(); // send the order in for execution
close(); // close out an executed order
}
Once they have agreed upon how to encapsulate an order in the abstract like this, the engineers can then go and work independently. All the details of "what an order is" would be up to the implementor of any particular order object, so long as the order object supported the encapsulating interface.

The nice thing about this approach is that it allows a system to be enhanced with a "new kind of order" without much difficulty. For example, if we were an auto repair shop getting into the restuarant business (perhaps inspired by Dixies BBQ and Auto Repair), we could probably have some software engineers convert our order management system from being able to handle only "car" orders into one that could also handle "food" orders. Although many details of the order may be different, as long as they can implement the same "Order" interface, the system should work. Similarly, "order users" can also be enhanced fairly easily, so long as they only use the services that an order has been defined to provide.

Order Management by Representation

The other way to divide up the work is to represent an "order" as a formal data format, and then leave it up to the different engineers to build systems that exchange that data for whatever purpose they choose. They would just need to ensure, for example, that an "order" is a document that matches a formal defined data format:

12345
2003-11-26
Change oil, check tires
45.00
Jim
450.00

Once the representation of an order has been agreed upon, the engineers can then go and work independently. Exactly "what should be done with an order" would be left to the implementor of any particular subsystem, so long as the orders flowing between parts of the system follow the schema correctly.

The nice thing about this design is that it allows a system to be enhanced to add "a new kind of order application" very easily. So for example, if we wanted to add an application that, say, did statistical analysis of an archive of all previous customer orders to help us forecast customer purchases (perhaps inspired by Wal-Mart's data warehousing), we could do that.

Notice that with the "representation" approach, it wouldn't matter that our engineers never anticipated that an order should be able to answer questions that might be interesting to a new application, like "What was the difference between the estimated price and the actual price?" Since the full representation of the data is exposed, it gives us full flexibility to define new behavior in the future - new queries, new patterns of update.

Choosing Between Encapsulation and Representation

Which model should be chosen for our order-entry system? It is a business decision. Each approach has strengths and weaknesses. Here is the choice facing the owners of our car-repair shop:

If it is important for you to keep your current computer applications, but you want to free yourself to let your applications be capable of working with new kinds of data - as Dixies has done by adapting their existing business process to a new kind of business - then what you want is program encapsulation.
On the other hand, if it is important for you to keep your current data, but you want to fee yourself to use your data in new applications in the future - as Wal-Mart has done by finding new business techinques to utilize their cash register receipts - then what you want is data representation.
Most modern businesses are inspired more by Wal-Mart than by Dixies. Wal-Mart is certainly the more intuitive model - it makes sense to be prepared to enhance an auto-repair computer system with more advanced computer functionality while keeping the same auto-repair-order data. It's a little more unusual to want to keep an auto-repair computer system, while changing the kind of underlying data (not to mention the associated staff, clients, and facilities) in order to turn it into a restaurant system.

In other words, people tend to hold the data that they have as sacred and something they want to keep forever, and they tend to assign less permanence to the particular programs that work with the data. This preference comes from practical experience. Experience has shown that hot new computer systems come and go, but a successful business keeps its boring old data forever.

Maybe the underlying causes for this experience can be attributed to Moore's law; or maybe on the amazing economies of magnetic media. Or maybe the success of representation is a characteristic that is inherent to all kinds of large-scale integration. (Compare the power of written language to that of spoken language.) At any rate, over the long term, representation tends to win over encapsulation as a large-scale architectural strategy.

When use Encapsulation?

Encapsulation is still useful in many situations, of course, but it tends to be most useful within transient programs when the particular data being encapsulated is temporary. Our guidelines are:

Use encapsulation when your program outlasts your data.
Use representation when your data outlasts your program.
Clearly, when defining a data structure that is tailored to implement a specific algorithm - the kind of data structures we learn about in Freshman Computer Science 101 - our data is ephemeral. In that case, our program outlasts our data, and it makes a lot of sense to subdivide the program by encapsulating any data that it works with using object-oriented interfaces.

Encapsulation, therefore, is still the main technique to use when implementing a single tightly-coupled computer system. However, as soon as we move to larger, more loosely-coupled networks of systems where individual programs can come and go while the network of data exchange remains, data representation becomes a much more powerful technique.

Use encapsulation to subdivide tightly-coupled components of a system.
Use representation to connect loosely-coupled systems together.
Encapsulation is for organizing programming in the small, and representation is for organizing programming in the large.

Why we Care

Why is this all relevant? Because it gets behind the whole architecture of XML versus Java. The world is organized into many individual systems written in object-oriented programs like Java, exchanging data-oriented messages in formats like XML.

Java is an excellent tool that can be used to define robust encapsulation for programs, and is useful for building systems in the small.

XML is a standard idiom for describing a human-readable representation of data, and is useful for connecting system in the large.

In future articles, we will delve into more of the differences between "thinking XML" and "thinking Java." In many of these cases, the differences come down to the differences between representation and encapsulation.

2003-11-23T21:56:00.000-08:00

protected void finalize() throws Throwable {}

every class inherits the finalize() method from java.lang.Object
the method is called by the garbage collector when it determines no more references to the object exist
the Object finalize method performs no actions but it may be overridden by any class
normally it should be overridden to clean-up non-Java resources ie closing a file
if overridding finalize() it is good programming practice to use a try-catch-finally statement and to always call super.finalize() (JPL pg 47-48). This is a saftey measure to ensure you do not inadvertently miss closing a resource used by the objects calling class
protected void finalize() throws Throwable {
try {
close(); // close open files
} finally {
super.finalize();
}
}

any exception thrown by finalize() during garbage collection halts the finalization but is otherwise ignored
finalize() is never run more than once on any object

2003-11-23T21:54:00.000-08:00

GC: variables and objects are eligible for garbage collection when they become unreachable.any variable set to null automatically becomes eligible for garbage collection.

static field --> as long as the class is loaded
instance field --> for the life of the instance
Array components --> as long as the array is referenced
Method parameters --> until method execution ends
Constructor parameters --> until the constructor execution ends
Exception handling parameters --> until the catch clause completes execution
Local variables --> in a for-loop, until the loop completes in a code-block, until the code block completes

2003-11-18T02:55:00.000-08:00

10 Things I Bet You Didn't Know about http://www.bu.edu/mfeldman/Google/ Google

2003-11-10T06:00:00.000-08:00

http://www.itbooksearch.com/ Free E-Book Download

2003-11-06T00:51:00.000-08:00

http://www.sdtimes.com/cols/integrationwatch.htm

.NET Progress Worries Java

2003-11-06T00:36:00.000-08:00

http://www.ergnosis.com/java-spec-report/java-language/index.html

JLS UnOfficial Erratta

2003-11-04T04:27:00.000-08:00

http://www.jroller.com/resources/behrangsa/software-project.jpg This image has been causing loads of laughs among my fellow developers

2003-11-03T06:02:00.000-08:00

http://www.revisingscbcd.co.uk/index.htm

A good study guide for SCBCD

2003-10-23T07:08:00.000-07:00

WHAT MOTIVATED YOU TO WRITE JAVARULES Doug Dunn

Why do I feel like I'm being baited here?
Okay, well first off, I thought it would be a five month job, not change my life. It has, however, because it turned out to be an unbelievable huge job, one that is far from complete. Originally, the "Java Rules" book in print, Mastering the Fundamentals, Volume 2, and all the unpublished chapters were one book. I work in Adobe FrameMaker, which has .book files. I still maintain a .book file that includes all my work for the purpose of searching. However, several years ago I renamed it to "The Monster.book"

Why I have not given up is one thing, why I started is another. Doubtless there were mixed motives, but I think the main one was that I was so frustrated trying to learn C++. I just thought I could do a better job. Java came along right when I was working on the beginnings of a C++ book, and leveled the playing field. I saw that as a once in a lifetime opportunity and threw myself into the writing of a Java fundamentals book.

Here I want to point out that I was a construction worker for five years before becoming a computer programmer. I throw that out because I have never thought of myself as one of the "best and brightest" in the profession. James Gosling, Guy Steele, Gilad Bracha, Neil Gafter, and the other luminaries at Sun are gods in the Java pantheon, and I admire them as much today (if not more) than I did when I started.

I have written a number of papers on this subject, but will try to condense the thoughts. I do not think the MIT or IIT grads or what I call the "best and brightest" can write this book. It simply had to be done by a lesser mortal. As your understanding progresses, you lose the perspective of someone that knows nothing about the subject. That perspective is what allows you to "translate" the knowledge. The best and brightest lose that perspective long before they even graduate from college. (I dropped out after three years and joined the Army, by the way.) I cannot overemphasize this point. That is why I have been so diligent in documenting my learning experience from day one. Java Rules and all my other work on this subject are what I like to characterize as a "travel log" of my journey from knowing nothing to having a reasonably good understand of Java language fundamentals. I have been maintaining that travel log from the 1.0.2 release, fully seven or eight years now, which is why I am confident that noone will ever be able to reproduce my work. A thousand times over my understanding of the subject has blossomed and I have never once failed to document the experience. If you wait even a day or two to do so, you begin to lose the perspective of where you were before. No one else has ever done this. Instead they wait until they have already mastered the subject, and then it is too late, way too late. I still have a long way to go. I know this. Just last night I completely rewrote the section on narrowing reference conversions. It was a massive leap forward in that particular section.

You can't imagine how time consuming it is to do this. It has derailed my entire career in computer programming to the point that the book has now become my career.

Beyond this historical perspective, I have always enjoyed helping other programmers even more than I enjoy programming. I really mean this. The programmers I have worked with in the past have known this, and I always had people coming to my cube because they knew I would not make them feel stupid no matter what the problem. I suppose I thought I could do the same on a larger scale by writing this book, at least I hope so. Time will tell. I never promoted the "Java Rules" book in print because I see all of the flaws in it. It has only been with the publication of Mastering the Fundamentals, Volume 2 some three months ago that I have begun for the first time ever to promote my work, and things are unfolding rapidly.

You asked a huge question, and I have taken the bait. I hope what little I have said here gives you a better idea of what motivated me.

2003-10-21T02:57:00.000-07:00

http://weblogs.java.net/pub/wlg/574 JavaWorld Stopped Updating Articles??????

2003-10-20T20:50:00.000-07:00

Worker blogs raising concerns?

http://www.usatoday.com/tech/news/2003-10-05-blogs_x.htm

2003-10-14T20:46:00.000-07:00

http://www.britishpathe.com/ Historic photo archive available on the Web

2003-10-13T06:04:00.000-07:00

http://www.objectlearn.com/index.jsp This is Good website contains Plugins for Eclipse (JSP, ....).

2003-10-07T21:17:00.000-07:00

"One of the main problems with today's software development is that many projects start programming too soon and concentrate too much effort on writing code. This is partly because managers lack the understanding of the software development process and become anxious when their programming team is not producing code. It's also because the programmers themselves feel more secure when they're programming—a task with which they are very familiar—than when they're building abstract models of the system they are to create."

—Eriksson, Hans-Erik and Penker

2003-10-07T20:55:00.000-07:00

http://www.itorg.auc.dk/borch/web_oos2001.E5/Blocks/Uml/UMLOnlineCourse/ Practical UML A Hands-On Introduction for Developers

2003-09-29T02:05:00.000-07:00

public class Mod{
public static void main(String argv[]){
}
public static native void amethod();
}
=========================================================

This will be compiled and Executed...

Here the method is declared as native.The native key word alerts the

compiler that the method will be defined externally.Native methods will not

conatin any coding in Java language.

This code will compile and run with out any error.But if you try to use the

method in another class,during run time it will throw

exception "UnsatisfiedLinkError",since JVM doesn't know how to find

aMethod().

So before using native methods,load the library file containg the method

definition for aMethod()developed in a language other than Java like C/C++.

You can do this by System.loadLibrary("moose.dll");

2003-09-28T23:10:00.000-07:00

http://java.sun.com/features/2003/05/bloch_qa.html New Language Features for Ease of Development in the Java 2 Platform, Standard Edition 1.5: A Conversation with Joshua Bloch

2003-09-28T22:40:00.000-07:00

INTERFACES AND CONSTANTS

When you want to use global constants in an application, it is often tempting to define the constants in an interface and then implement the interface in the class using the constants. For example, suppose you have the following interface that contains approximations for the numbers pi and e.

public interface TranscendentalConstants {
public static final double PI = 3.14159;
public static final double E = 2.71828;
}

Suppose too that you have a second collection of constants that contains approximations for the square roots of two and three.

public interface IrrationalConstants {
public static final double SQRT_TWO = 1.414;
public static final double SQRT_THREE = 1.732;
}

A common strategy for using these constants is to create a class like the following.

public class BadUseOfConstants implements
TranscendentalConstants, IrrationalConstants {

public double sinPiOverFour(){
return SQRT_TWO / 2;
}

public double sinPiOverThree(){
return SQRT_THREE / 2;
}

private void outputResults() {
System.out.println("Pi is approximately " + PI);
System.out.println(
"The sin of Pi/4 is approximately " +
sinPiOverFour());
System.out.println(
"The sin of Pi/3 is approximately " +
sinPiOverThree());
}

public static void main(String[] args) {
new BadUseOfConstants().outputResults();
}
}

Even though this code runs, it is an improper use of interfaces. That's because BadUseOfConstants is not an extension of the type TranscendentalConstants. Instead, BadUseOfConstants is a consumer of TranscendentalConstants. There are two reasons why using interfaces in this way is so attractive. First, you can easily use constants defined in two different interfaces. If the constants were used in different classes instead, multiple inheritance would be required to perform the same task. Second, by implementing the interfaces, you can refer to the constants without qualifying them as SQRT_TWO instead of as IrrationalConstants.SQRT_TWO.

You can address this second problem of having to qualify constants by caching the variables locally like this.

public class OKUseOfConstants {

private double PI = TranscendentalConstants.PI;
private double SQRT_TWO =
IrrationalConstants.SQRT_TWO;
private double SQRT_THREE =
IrrationalConstants.SQRT_THREE;

public double sinPiOverFour() {
return SQRT_TWO / 2;
}

public double sinPiOverThree() {
return SQRT_THREE / 2;
}

public void outputResults() {
System.out.println("Pi is approximately " + PI);
System.out.println(
"The sin of Pi/4 is approximately " +
sinPiOverFour());
System.out.println(
"The sin of Pi/3 is approximately " +
sinPiOverThree());
}

public static void main(String[] args) {
new OKUseOfConstants().outputResults();
}
}

When J2SE 1.5 is released, a new mechanism for importing specific constants will be introduced that will address both of these issues. In the meantime, you might want to introduce an inner class or a different class that collects all of the interfaces containing the constants you want to use. Here's an example. In the BetterUseOfConstants program that follows, the inner class ConstantCollector is used to collect the constants declared in TranscendentalConstants and IrrationalConstants.

public class BetterUseOfConstants {

private ConstantCollector constants =
new ConstantCollector();

public double sinPiOverFour(){
return constants.SQRT_TWO / 2;
}

public double sinPiOverThree(){
return constants.SQRT_THREE / 2;
}

private void outputResults() {
System.out.println(
"Pi is approximately " +
constants.PI);
System.out.println(
"The sin of Pi/4 is approximately " +
sinPiOverFour());
System.out.println(
"The sin of Pi/3 is approximately " +
sinPiOverThree());
}

public static void main(String[] args) {
new BetterUseOfConstants().outputResults();
}

private class ConstantCollector implements
TranscendentalConstants, IrrationalConstants{}
}

Running this code should produce the following results:

Pi is approximately 3.14159
The sin of Pi/4 is approximately 0.707
The sin of Pi/3 is approximately 0.866

In this case ConstantCollector is a type extension of the two interfaces.

2003-09-26T03:33:00.000-07:00

"Any fool can write code that a computer can understand. Good programmers write code that humans can understand." -- Martin Fowler

2003-09-26T03:17:00.000-07:00

The greater the difficulty,the more the glory in surmounting it.

2003-09-26T01:47:00.000-07:00

http://patterndigest.com/ A good URL for Patterns

2003-09-22T22:43:00.000-07:00

Understanding that parameters are passed by value and not by reference

common misconception exists that parameters in Java are passed by reference. They are not. Parameters are passed by value. The misconception arises from the fact that all object variables are object references. This leads to some unexpected results if you do not understand exactly what is happening. For example:

import java.awt.Point;
class PassByValue
{
public static void modifyPoint(Point pt, int j)
{
pt.setLocation(5,5); //1
j = 15;
System.out.println("During modifyPoint " + "pt = " + pt +
" and j = " + j);
}
public static void main(String args[])
{
Point p = new Point(0,0); //2
int i = 10;
System.out.println("Before modifyPoint " + "p = " + p +
" and i = " + i);
modifyPoint(p, i); //3
System.out.println("After modifyPoint " + "p = " + p +
" and i = " + i);

}
}

This code creates a Point object, initialized to (0,0) , and assigns it to the object reference variable p at //2. It then assigns the primitive int i the value 10 . The static modifyPoint method is then called at //3, passing p and i. The modifyPoint method calls the setLocation method on the first parameter, pt , changing its location to (5,5) . In addition, the second parameter, j , is assigned the value 15. When the modifyPoint method returns, method main prints the values for p and i . What is the output of this code and why?

The output of this code is as follows:

Before modifyPoint p = java.awt.Point[x=0,y=0] and i = 10
During modifyPoint pt = java.awt.Point[x=5,y=5] and j = 15
After modifyPoint p = java.awt.Point[x=5,y=5] and i = 10

This output shows that the modifyPoint method changed the Point object created at //2 but not the int,i . In main , i is assigned the value 10. Parameters are passed by value, therefore, a copy of i is passed to the modifyPoint method. This method changes the value of the copy to 15 and returns. The original value, i in main , is not changed.

On the other hand, you might think the Point object created at //2 is unmodified by the modifyPoint method. After all, Java passes parameters by value. Therefore, when modifyPoint is called with the Point object created at //2, a copy is made for the modifyPoint method to work with. Changes to the Point object in modifyPoint are not reflected in main because there are two different objects. Right? Wrong.

Actually, the modifyPoint method is working with a copy of a reference to the Point object, not a copy of the Point object. Remember that p is an object reference and that Java passes parameters by value. More specifically, Java passes object references by value. When p is passed from main to the modifyPoint method, a copy of the value of p, the reference, is passed. Therefore the modifyPoint method is working with the same object but through the alias, pt . After entering the modifyPoint method, but before the execution of the code at //1, the object looks like this:

Figure 1

Therefore, after the code at //1 is executed, the Point object has changed to (5,5) . What if you want to disallow changes to the Point object in methods such as modifyPoint ? There are two solutions for this:

Pass a clone of the Point object to the modifyPoint method.
Make the Point object immutable.

2003-09-22T21:52:00.000-07:00

Understand that for instance methods, synchronized locks objects, not methods or code

The synchronized keyword is used as either a method modifier or as a statement inside of a method. This dual usage causes some confusion about exactly what the synchronized keyword does. It is often described in terms of mutual exclusion (mutex) or a critical section. This causes many programmers to incorrectly think that because code is protected by synchronized , it can be accessed by only one thread at a time.

For instance methods, the synchronized keyword does not lock a method or code; it locks objects. Remember that there is only one lock associated with each object.

When synchronized is used as a method modifier, the lock obtained is that for the object on which the method was invoked.When it is used on an object refer-ence, the lock obtained is that for the object referred to. For example, consider the following code:

class Test
{
public synchronized void method1()
{
//...
}

public void method2()
{
synchronized(this) {
//...
}
}

public void method3(SomeObject someObj)
{
//...
synchronized(someObj) {
//...
}
}
}

The first two methods, method1 and method2 , are functionally identical regarding the object being locked. (They differ in the amount of code generated and in how they perform.) Both methods are synchronized on this . In other words, a lock is obtained for the object on which the method was invoked. Because both methods are of the class Test , the lock is obtained for an object of class Test . The method3 method is synchronized on the object referenced by someObj .

What exactly does it mean to synchronize on an object? It means that the thread that invoked the method has that object s lock. To hold an object s lock means another thread requesting a lock for the same object through a synchronized method or a synchronized statement cannot obtain that lock until it is released. However, another thread executing the same synchronized method or block on a different instance of the same class can obtain that instance s lock.

Thus, code in a synchronized method or block can be executed at the same time by multiple threads if the method is invoked on two different objects. For example, consider the following code:

class Foo extends Thread
{
private int val;
public Foo(int v)
{
val = v;
}

public synchronized void printVal(int v)
{
while(true)
System.out.println(v);
}

public void run()
{
printVal(val);
}
}
class Bar extends Thread
{
private Foo sameFoo;
public Bar(Foo f)
{
sameFoo = f;
}
public void run()
{
sameFoo.printVal(2);
}
}

class Test
{
public static void main(String args[])
{
Foo f1 = new Foo(1);
f1.start();
Bar b = new Bar(f1);
b.start();
Foo f2 = new Foo(3);
f2.start();
}
}

Class Foo contains a synchronized method, printVal . This method is executed by three different threads. You might think that because printVal is declared synchronized , it is executed by only one thread at a time. However, this code demonstrates that even though the printVal method is declared synchronized , it can be executed by multiple threads concurrently. Running this code generates output of the form:

1
1
1
1
3
3
3
3
1
1
1
3
3
3

What might be surprising is the interleaved execution of two of the threads. If only one thread could execute a synchronized method at a time, you would never see interleaved output. In fact, what happens is the code that prints the 1 s and 3 s is executing the printVal method concurrently. Examining this code shows why this happens.

An object of the class Foo , referenced by f1 , is created, passing the value 1, and then run on another thread. The run method of class Foo is called, which then calls the synchronized printVal method. When the printVal method is entered, it has obtained the lock for the Foo object. It then begins printing the value 1. Because it has entered an infinite loop, the lock for this Foo object is never released.

Then an object of type Bar , referenced by b , is created, passing the same Foo object currently in use. It is run on another thread and calls the same printVal method, with the value 2, on the same Foo object. Because the printVal method is synchronized , this call attempts to obtain the lock for the object on which the method is called. The printVal method is called on the same Foo object as the previous invocation, so this call blocks until the first execution of the printVal method is finished. Because the first thread holds this lock and is in an infinite loop, the code never outputs both a 1 and a 2. The first thread to obtain the lock blocks out the other thread forever. Therefore, you do not see any interleaved execution of these two invocations of the printVal method.

Finally, a second object of the Foo class, referenced by f2 , is created, passing the value 3, and then run on a third thread. The run method of class Foo is called, which then calls the synchronized printVal method. When that method is called, it attempts to obtain the lock for the object on which it is called. The attempt to get this lock succeeds regardless of whether the thread for f1 or b still holds a lock. Because this invocation of the printVal method is called on a different object, it can obtain that object s lock.

Thus, you can see interleaved execution between the threads for f1 and f2 , but never between the threads for b and f1 . The threads for f1 and f2 operate on unique objects and therefore are not affected by the synchronized keyword. The threads for f1 and b , however, operate on the same Foo object and therefore must synchronize on its lock.

Remember that synchronization locks objects, not methods or code. Simply because a method, or section of code, is declared synchronized does not necessarily mean it is executed by only one thread at a time. This is important if the code in the synchronized method or block alters a mutually shared resource.

If the code alters an instance variable of the object, no problem results. In the previous example, f1 and f2 are two distinct objects and therefore contain two distinct instance variables. If the printVal method alters the instance variable val , then the code works as expected without conflict because the threads for f1 and f2 alter different data. However, if the printVal method shares some other non-object resource, such as a static variable, a conflict might result. In this case, you must synchronize on a mutually shared object in order to prevent conflicts.

One final note about the synchronized keyword. The Java language does not allow constructors to be declared synchronized . (A compiler error is generated if the synchronized keyword is present on a constructor declaration.) This is because two threads that call the same constructor concurrently operate on two distinct pieces of memory for two distinct instances of the same class. However, if these constructors contain code that contends for a mutually shared resource, you must synchronize on that resource in order to avoid conflicts.

2003-09-19T05:35:00.000-07:00

Enable-AutoComplete Feature In Command Line

change registry by using regedit. If you have XP you can do this also by using powertoys (tweakxp)

HKEY_LOCAL_MACHINE/SOFTWARE/Microsoft/Command Processor

Right click on CompletionChar
DWORD change that to 9

restart and you are done. Pressing tab in the command line can complete the next match of the command that you are typing.

2003-09-19T05:06:00.000-07:00

The Java language does not allow constructors to be declared synchronized . (A compiler error is generated if the synchronized keyword is present on a constructor declaration.) This is because two threads that call the same constructor concurrently operate on two distinct pieces of memory for two distinct instances of the same class. However, if these constructors contain code that contends for a mutually shared resource, you must synchronize on that resource in order to avoid conflicts.

2003-09-19T05:03:00.000-07:00

http://www-106.ibm.com/developerworks/java/library/j-praxis/pr46.html Understand that for instance methods, synchronized locks objects, not methods or code.

2003-09-10T21:53:00.000-07:00

"He who controls vocabulary controls thought" - Luigi Wittgenstein

2003-09-08T21:26:00.000-07:00

http://books.wontstop.com/ Good E-Books on .NET

2003-09-08T21:10:00.000-07:00

javacoder.net the on-line resource for Java(tm) coders. http://javacoder.net/

2003-08-28T23:51:00.000-07:00

Today my number changes (dint get!!!) my b'day. Huh.!! I am getting Old.

2003-08-26T02:18:00.000-07:00

The Law of Leaky Abstractions

There's a key piece of magic in the engineering of the Internet which you rely on every single day. It happens in the TCP protocol, one of the fundamental building blocks of the Internet.

TCP is a way to transmit data that is reliable. By this I mean: if you send a message over a network using TCP, it will arrive, and it won't be garbled or corrupted.

We use TCP for many things like fetching web pages and sending email. The reliability of TCP is why every exciting email from embezzling East Africans arrives in letter-perfect condition. O joy.

By comparison, there is another method of transmitting data called IP which is unreliable. Nobody promises that your data will arrive, and it might get messed up before it arrives. If you send a bunch of messages with IP, don't be surprised if only half of them arrive, and some of those are in a different order than the order in which they were sent, and some of them have been replaced by alternate messages, perhaps containing pictures of adorable baby orangutans, or more likely just a lot of unreadable garbage that looks like the subject line of Taiwanese spam.

Here's the magic part: TCP is built on top of IP. In other words, TCP is obliged to somehow send data reliably using only an unreliable tool.

To illustrate why this is magic, consider the following morally equivalent, though somewhat ludicrous, scenario from the real world.

Imagine that we had a way of sending actors from Broadway to Hollywood that involved putting them in cars and driving them across the country. Some of these cars crashed, killing the poor actors. Sometimes the actors got drunk on the way and shaved their heads or got nasal tattoos, thus becoming too ugly to work in Hollywood, and frequently the actors arrived in a different order than they had set out, because they all took different routes. Now imagine a new service called Hollywood Express, which delivered actors to Hollywood, guaranteeing that they would (a) arrive (b) in order (c) in perfect condition. The magic part is that Hollywood Express doesn't have any method of delivering the actors, other than the unreliable method of putting them in cars and driving them across the country. Hollywood Express works by checking that each actor arrives in perfect condition, and, if he doesn't, calling up the home office and requesting that the actor's identical twin be sent instead. If the actors arrive in the wrong order Hollywood Express rearranges them. If a large UFO on its way to Area 51 crashes on the highway in Nevada, rendering it impassable, all the actors that went that way are rerouted via Arizona and Hollywood Express doesn't even tell the movie directors in California what happened. To them, it just looks like the actors are arriving a little bit more slowly than usual, and they never even hear about the UFO crash.

That is, approximately, the magic of TCP. It is what computer scientists like to call an abstraction: a simplification of something much more complicated that is going on under the covers. As it turns out, a lot of computer programming consists of building abstractions. What is a string library? It's a way to pretend that computers can manipulate strings just as easily as they can manipulate numbers. What is a file system? It's a way to pretend that a hard drive isn't really a bunch of spinning magnetic platters that can store bits at certain locations, but rather a hierarchical system of folders-within-folders containing individual files that in turn consist of one or more strings of bytes.

Back to TCP. Earlier for the sake of simplicity I told a little fib, and some of you have steam coming out of your ears by now because this fib is driving you crazy. I said that TCP guarantees that your message will arrive. It doesn't, actually. If your pet snake has chewed through the network cable leading to your computer, and no IP packets can get through, then TCP can't do anything about it and your message doesn't arrive. If you were curt with the system administrators in your company and they punished you by plugging you into an overloaded hub, only some of your IP packets will get through, and TCP will work, but everything will be really slow.

This is what I call a leaky abstraction. TCP attempts to provide a complete abstraction of an underlying unreliable network, but sometimes, the network leaks through the abstraction and you feel the things that the abstraction can't quite protect you from. This is but one example of what I've dubbed the Law of Leaky Abstractions:

All non-trivial abstractions, to some degree, are leaky.

Abstractions fail. Sometimes a little, sometimes a lot. There's leakage. Things go wrong. It happens all over the place when you have abstractions. Here are some examples.

Something as simple as iterating over a large two-dimensional array can have radically different performance if you do it horizontally rather than vertically, depending on the "grain of the wood" -- one direction may result in vastly more page faults than the other direction, and page faults are slow. Even assembly programmers are supposed to be allowed to pretend that they have a big flat address space, but virtual memory means it's really just an abstraction, which leaks when there's a page fault and certain memory fetches take way more nanoseconds than other memory fetches.
The SQL language is meant to abstract away the procedural steps that are needed to query a database, instead allowing you to define merely what you want and let the database figure out the procedural steps to query it. But in some cases, certain SQL queries are thousands of times slower than other logically equivalent queries. A famous example of this is that some SQL servers are dramatically faster if you specify "where a=b and b=c and a=c" than if you only specify "where a=b and b=c" even though the result set is the same. You're not supposed to have to care about the procedure, only the specification. But sometimes the abstraction leaks and causes horrible performance and you have to break out the query plan analyzer and study what it did wrong, and figure out how to make your query run faster.
Even though network libraries like NFS and SMB let you treat files on remote machines "as if" they were local, sometimes the connection becomes very slow or goes down, and the file stops acting like it was local, and as a programmer you have to write code to deal with this. The abstraction of "remote file is the same as local file" leaks. Here's a concrete example for Unix sysadmins. If you put users' home directories on NFS-mounted drives (one abstraction), and your users create .forward files to forward all their email somewhere else (another abstraction), and the NFS server goes down while new email is arriving, the messages will not be forwarded because the .forward file will not be found. The leak in the abstraction actually caused a few messages to be dropped on the floor.
C++ string classes are supposed to let you pretend that strings are first-class data. They try to abstract away the fact that strings are hard and let you act as if they were as easy as integers. Almost all C++ string classes overload the + operator so you can write s + "bar" to concatenate. But you know what? No matter how hard they try, there is no C++ string class on Earth that will let you type "foo" + "bar", because string literals in C++ are always char*'s, never strings. The abstraction has sprung a leak that the language doesn't let you plug. (Amusingly, the history of the evolution of C++ over time can be described as a history of trying to plug the leaks in the string abstraction. Why they couldn't just add a native string class to the language itself eludes me at the moment.)
And you can't drive as fast when it's raining, even though your car has windshield wipers and headlights and a roof and a heater, all of which protect you from caring about the fact that it's raining (they abstract away the weather), but lo, you have to worry about hydroplaning (or aquaplaning in England) and sometimes the rain is so strong you can't see very far ahead so you go slower in the rain, because the weather can never be completely abstracted away, because of the law of leaky abstractions.
One reason the law of leaky abstractions is problematic is that it means that abstractions do not really simplify our lives as much as they were meant to. When I'm training someone to be a C++ programmer, it would be nice if I never had to teach them about char*'s and pointer arithmetic. It would be nice if I could go straight to STL strings. But one day they'll write the code "foo" + "bar", and truly bizarre things will happen, and then I'll have to stop and teach them all about char*'s anyway. Or one day they'll be trying to call a Windows API function that is documented as having an OUT LPTSTR argument and they won't be able to understand how to call it until they learn about char*'s, and pointers, and Unicode, and wchar_t's, and the TCHAR header files, and all that stuff that leaks up.

In teaching someone about COM programming, it would be nice if I could just teach them how to use the Visual Studio wizards and all the code generation features, but if anything goes wrong, they will not have the vaguest idea what happened or how to debug it and recover from it. I'm going to have to teach them all about IUnknown and CLSIDs and ProgIDS and ... oh, the humanity!

In teaching someone about ASP.NET programming, it would be nice if I could just teach them that they can double-click on things and then write code that runs on the server when the user clicks on those things. Indeed ASP.NET abstracts away the difference between writing the HTML code to handle clicking on a hyperlink () and the code to handle clicking on a button. Problem: the ASP.NET designers needed to hide the fact that in HTML, there's no way to submit a form from a hyperlink. They do this by generating a few lines of JavaScript and attaching an onclick handler to the hyperlink. The abstraction leaks, though. If the end-user has JavaScript disabled, the ASP.NET application doesn't work correctly, and if the programmer doesn't understand what ASP.NET was abstracting away, they simply won't have any clue what is wrong.

The law of leaky abstractions means that whenever somebody comes up with a wizzy new code-generation tool that is supposed to make us all ever-so-efficient, you hear a lot of people saying "learn how to do it manually first, then use the wizzy tool to save time." Code generation tools which pretend to abstract out something, like all abstractions, leak, and the only way to deal with the leaks competently is to learn about how the abstractions work and what they are abstracting. So the abstractions save us time working, but they don't save us time learning.

And all this means that paradoxically, even as we have higher and higher level programming tools with better and better abstractions, becoming a proficient programmer is getting harder and harder.

During my first Microsoft internship, I wrote string libraries to run on the Macintosh. A typical assignment: write a version of strcat that returns a pointer to the end of the new string. A few lines of C code. Everything I did was right from K&R -- one thin book about the C programming language.

Today, to work on CityDesk, I need to know Visual Basic, COM, ATL, C++, InnoSetup, Internet Explorer internals, regular expressions, DOM, HTML, CSS, and XML. All high level tools compared to the old K&R stuff, but I still have to know the K&R stuff or I'm toast.

Ten years ago, we might have imagined that new programming paradigms would have made programming easier by now. Indeed, the abstractions we've created over the years do allow us to deal with new orders of complexity in software development that we didn't have to deal with ten or fifteen years ago, like GUI programming and network programming. And while these great tools, like modern OO forms-based languages, let us get a lot of work done incredibly quickly, suddenly one day we need to figure out a problem where the abstraction leaked, and it takes 2 weeks. And when you need to hire a programmer to do mostly VB programming, it's not good enough to hire a VB programmer, because they will get completely stuck in tar every time the VB abstraction leaks.

The Law of Leaky Abstractions is dragging us down.

2003-08-26T01:59:00.000-07:00

2003-08-19T22:56:00.000-07:00

Java Interfaces are a great tool for providing clean designs. I almost hesitate to point out that they can have a minor performance penalty. A method call on an object that is declared as an interface type is slower than a method call on a regular class type. I would only consider attempting optimizing this type of code in the most severely performance sensitive code.

For those interested, I have provided some details. Regular Java virtual method calls are done by looking up the method stored at a constant offset into the object's Class's method table. A method call on an interface will be called on object's with different method table layouts. The correct method in the method table cannot be found with a constant offset. A distinct mechanism for finding the right method must be used. There are technique to make this operation fairly efficient, but it is fundamentally slower than a normal method call.

2003-08-17T22:30:00.000-07:00

This website is personal experience while doing SCEA, SCJP... of Jane. http://www.janeg.ca/

2003-08-17T22:28:00.000-07:00

Check this website for Java Tips http://www.javafaq.nu. I have to dowload this eBook yet.

2003-08-13T21:36:00.000-07:00

One of the first lessons you should learn about tuning is not to guess. Don't guess that there may a performance problem. Implement the code simply, with good coding practices, then measure the performance and find the bottlenecks. If there is a bottleneck, use one of the hundreds of performance tuning techniques available (including reusing objects just like the example above) to improve the performance of the bottleneck. Then document clearly what you've done. (I like to keep the old code in comments.)

2003-08-13T21:09:00.000-07:00

The Java News Brief
http://www.ociweb.com/jnb/index.html

2003-08-13T20:54:00.001-07:00

This website has good book for Mastering The Fundamentals of the Javaï?½ Programming Language http://www.javarules.com

2003-08-13T20:54:00.000-07:00

About equals()

equals() method can be misleading. Every class in Java inherits this
method from the Object class whether it's a Java class or a class
created by you.

If you think about it, equals can mean different things to different
classes. Imagine two people - you can think of them as equal if they
are
the same age, same height, same shoe size OR all of the above. So
clearly, Object has to define SOME criteria of comparing the two.

If you don't write your own equals method, you get the DEFAULT equals
from Object, which basically says that one object is ONLY equals to
another if they are located in the same place in memory. So, even if
they have the same behavior and same attributes to them, if they are
located in different places in memory - they are NOT equals.

To give you another example, take the String class. String class
decided not to keep the DEFAULT implementation of the Object class,
but
to override it and say that if two strings are the same, even if they
are located in different places in memory it will still consider them
equal.

2003-08-12T21:18:00.000-07:00

Overloading considered harmful

What is overloading, once again? Same method name for different methods - sounds harmless enough!

Sure it's one of the first things Java programmers are confronted with when learning the language. You are told things like: Do not mix it up with overriding - remember, these things may look quite similar, but are altogether different concepts! Then your Java introduction goes on telling you about unique parameter lists, and after one and half pages you get the impression that this is something not so terribly hard to understand. [HK: I can vouch for this argument. In my Java courses, students commonly make this mistake.]

What is the value proposition of this seemingly simple feature?

Shorter interfaces, not bogged down by artificial, tiresome discriminators, and a bit of lexical structuring of your class text: Overloading allows you to indicate the conceptual identity of different methods, letting you stress common semantics across methods so that similarities become apparent at first sight. It's supposed to make your code more readable, and what regards server code - the code, where these method siblings are defined -, it really does.

There are many who like it. There is tons of code using what overloading has to offer. And of course, you cannot even escape it in Java, where you're simply forced to use it when you want to provide different initializers. It seems, overloading rules - a feature not only popular, but tightly integrated into some important programming languages, an open commitment of venereous language designers that surely does not fail to impress the masses. And, what is more: no performance penalty whatsoever...

Now, should we fully embrace overloading in our own code then? Should we use it wherever possible? This discussion shall present an attempt to put the technical facts investigated in-depth by a former edition of this newsletter into a usage perspective - a bit similar in spirit to the popular harping on pointers which you can find in every Java introduction. The seminal idea that overloading clashes with dynamic binding is taken from a discussion of overloading to be found in "Object-Oriented Software Construction" by Bertrand Meyer.

There is no reason to question that naming conventions to indicate conceptual interrelatedness of different methods will benefit the class text where these methods are defined. To adopt the convention of reusing the same method name, however, has unfortunate consequences on client code which can become quite unintuitive, to say the least.

Overloading with parameter lists of different length pose no problem for client code interpretation, as they openly disambiguate client calls at first sight. Things that could irritate you just will not compile. However, when overloaded methods with the same method name have parameter lists of the same length, and when the actual call arguments conform to more than one signature of these overloaded methods, it somehow gets a little hard to tell which methods are actually executed just looking on the client calls. In this situation, you experience the strange phenomenon that the methods being called are not independent of the reference types being used for the calls.

There are several problems related to this, but first let's take another look on the small code example presented in a former edition of this newsletter in order to really get a feel for what it's like when methods being called are not independent of the reference types being used for the calls.

A minimal modification allows us to focus on the ugly side of overloading: The program still tells us which method gets actually called, but on top of that also delivers rather strong comments when overloading is caught to harm our ability to reason about the client code without knowing the server classes.

Basically, we have two fixed instances, which will play always the same roles: one serving as call target, the other serving as argument. Now we mix and match several calls always to be executed on these same instances (always the same target object, always the same argument object) the only difference being the reference types through which these objects are accessed. And behold: Different methods are being called. If you are familiar with this simple setting, you may skip the program part to directly go on with the following discussion.

public class OverloadingTest {
public abstract static class Top {
public String f(Object o) {
String whoAmI = "Top.f(Object)";
System.out.println(whoAmI);
return whoAmI;
}
}

public static class Sub extends Top {
public String f(String s) {
String whoAmI = "Middle.f(String)";
System.out.println(whoAmI);
return whoAmI;
}
}

public static void main(String[] args) {
Sub sub = new Sub();
Top top = sub;

String stringAsString = "someString";
Object stringAsObject = string;

if (top.f(stringAsObject) == sub.f(stringAsString))
//if (top.f(stringAsObject) == sub.f(stringAsObject))
//if (top.f(stringAsString) == sub.f(stringAsString))
//if (top.f(stringAsString) == sub.f(stringAsObject))
//if (sub.f(stringAsString) == sub.f(stringAsObject))
//if (top.f(stringAsString) == top.f(stringAsObject))
{
System.out.println("Hey, life is great!");
} else {
System.out.println("Oh no!");
}
}
}

Can you tell what happens with activating each of the conditions?

Let us carefully go through the code.

There are two overloaded methods spread across a class hierarchy (one class inheriting from another class). This is the server code to be called by the client.
The superclass defines: String f(Object o).
The subclass defines: String f(String o).
The signatures are chosen to make both methods eligible candidates to be executed in the context of calls on the subclass instance with a String argument.
The client provides two objects, reused for all calls and chosen in a way that both overloaded methods are potentially eligible candidates for executing the client calls.
Through polymorphic assignment, the client obtains references of different types for these two instances.
The client makes method calls that differ only in the different references used for making the call. In the given setup, there are 4 different call forms possible: Overloading has the method name fixed, so only the target reference type and the parameter reference type are variable. Every reference type for the target can be combined with every reference type for the argument. (Mathematically spoken, there are 4 binary strings of length 2).
The comparisons then are really just for fun, eliminating detail. They shift the focus of attention from the question what particular method gets called to the general insight that different methods get called, additionally allowing the program to be explicit about its likes and dislikes: Every case of seeming reference-independence of the calls is instantly interpreted as an example of how things should be, and welcomed with a happy, optimistic "Hey, life seems great!" In those some dark moments, however, when overloading casts its dark shadow upon the else so object-oriented Java world, and just nothing seems right, our little program starts to complain... Combinatorics tells us six 2-combinations of a 4-set (consisting of 4 call forms) exist, and so you find six comparisons (five of them showing up as comments), but of course, already one single predicate returning false (different methods having been called) suffices to get the point across.
And that's it.

Discussion
The program shows, once again, that one thing to be aware of in connection with overloading is that it's all about reference types. This is as true for target reference types as it is for parameter reference types. For instance, the predicate "sub.f(stringAsObject) == sub.f(stringAsString)" will resolve to false in our setup because two different methods are executed. This dependence on reference types in connection with overloading may or may not be what you expected, but the question remains if this is a clean approach to object-oriented programming.

No doubt, this may puzzle many a brave programmer, as it is a result absolutely exclusive to overloaded methods. And, as the use of overloaded methods does not identify itself as such in the method call, the intuitive, but unfortunately wrong expectation might be that the predicate returns true, as it would be the case with any gentle non-overloaded method.

Honest, do we like this? No. Object-oriented programming, as we know it, is about objects, not about references. We expect objects to behave the way they are and not the way they are referenced. Objects do their thing regardless of the role the client assigns them. This is how it should be be, and we call this thing dynamic binding. It is not cosmetics, it is not just a feature, it is THE feature. It shapes the architecture of our systems, decoupling clients from servers.

Now, with overloading a second rule, reference type dependence, takes over, breaking the fundamental polymorphic equivalence property described above (that polymorphic assignments do not change the results of method calls as long as the code can be compiled). The choice of references in the client, which should be based on considerations like grouping and low coupling, suddenly has to take the demands of overloading into account. Overloaded server objects affect the design of client code. Cosmetics beat structure. Unlike overriding, overloading cannot just be applied in a server method definition act and end of the story. It is a feature you have to stay aware of in your clients whose specific referencing of server objects influences what functionality gets called in the end. While with dynamic binding alone the method to be executed is completely server-defined, overloading proves to be client-sensitive.

Now to the problems. An important issue closely connected to software quality is readability. Our ability to reason about the software text is essential for any kind of maintenance, and, as you might have guessed by the direction this discussion has taken by now, overloading affects readability of client code in a rather negative way. It is all very well to let the program run and after the surprise look at the server code and explain the strange things away (oh, of course, overloaded methods, you know...), but nevertheless it would be preferable by far to predict the behaviour, simple as it is, by simply (i.e. exclusively) examining the client. Show me the client class, tell me no overloading is involved, and I tell you: "Hey, life seems great!" I can reason about the result of the condition solely looking at the client class.

With overloading being introduced, or even with just the slightest chance of overloading being used (this includes all unknown Java code), this statement is impossible to make, because you cannot tell if the same server method gets called without examining the server sources. In our program, you would have to read three classes instead of one to know what's going on. So, use of overloading weakens the expressive power of client code as the polymorphic equivalence property cannot be relied upon.

Sometimes, of course, you are willing to dig into the server code because you want to find out the exact server method that gets called. But even then overloading significantly complicates things. Without overloading, you just work your way bottom up through the target's class hierarchy, and when you find a match, bingo, you're done! With unknown code or code known to use overloading, this can be only your second step. First you have to examine the class of the reference and find the matching method. Only then can you check the class hierarchy for overriding methods. The bad thing about this is probably not the additional step involved, but that you have to repeat this analysis for every different reference type, because results can vary. Thus, overloading complicates the analysis of client-server interaction.

There is also a psychological dimension to all this. The following will try to show that overloading is not a gentle, unobtrusive language feature, but, as it stands in conflict with other language features, late binding and inheritance, particularly prone to abuse. In other words, overloading is an open invitation for introducing conceptual errors. Think of novice programmers or programmers in a rush. Overloaded methods, coming with its own method selection rules, present an anomaly in the object-oriented landscape shaped by the presence of dynamic binding, and will surely go on to puzzle people, who will falsely think overloaded methods behave like "normal" methods, or mistake overloading for overriding just because the methods signatures involved in overloading look so similar.

In fact, such a mistake may be seen as expressing justified desires regarding object-oriented design. Hell, we'd sure like to see the overloaded methods in our example being handled as an instance of overriding! The parameters of our methods are related through inheritance, so inspired by other programming languages, it does not take great imagination to see the derived class define a method that overrides the inherited method. Of course, this is an additional twist adding a bit of vision to our discussion, and of course, we know that Java does not support such covariant method redefinition (restricting the parameter domain of the method): Most of us have learnt by now that Java allows only specification inheritance (overriding being only defined for methods with the same return and parameter types). But still. Do we not think, deep in our heart, that the subclass method with the more specific parameter should, in a better world maybe, be the one in charge, overriding the superclass method? Think about an Integer class inheriting from Number while redefining addition for integers only. Not allowed in Java, but still desirable (and a real feature in other languages such as Eiffel). Sure, overloading is not to be blamed for an incorrect understanding of inheritance in Java, but it clearly invites such fantasies (and the corresponding errors) when used in a context such as the presented one. And even if such interpretations are wrong - shouldn't they be right?

And then the poor integration of overloading and inheritance in Java, which is very misleading as well. Reference type dependence means that overloading is simply not developed to conceptual consistency in the context of inheritance. Guessing from experience with overloaded methods defined in one and the same class, we might expect the method with the best match in terms of formal parameter type and actual method argument to be called on the object. This does not happen, though. Java does not produce any kind of "flat form" for the object's class with all overloaded methods, inherited or not, appearing side by side in a list in order to allow the runtime to choose the most appropriate.

No, what technically happens, is, in my understanding, that the compiler takes the method symbol plus the parameter reference types of some method call and calculates a position in the method table of the target's reference type. So, choosing between overloaded methods is done compile-time, and it is restricted to the overloaded methods of one class: the class of the reference type. Overloaded methods defined in subclasses of the reference type are never called: Java ignores the exiled siblings although the whole thing looks so very similar to overriding.

With overloaded methods being defined in superclasses of the reference type, Java exhibits quite strange behaviour: While the server code can still be compiled, client code will break: Trying to make a method call where the compiler would have to choose between them, you get a compilation error, complaining that the call is ambiguous. Put the method into the reference type and all is well. Don't ask me why - just remember selection of overloaded methods is limited to the reference type class. I personally believe this further anomaly might is more a compiler issue than a language issue. If you find a logic explanation for this, other than that it helps to improve compilation performance, please let me know.

Once again (the last time): overloaded methods defined in subtypes of the target reference will not be taken into consideration as candidates for execution by the runtime. With the table position given in the bytecode, the runtime will only check if there are overriding methods (which will appear at the same position in the method tables of subclasses if they exist). So, the compiler cannot hunt them down, and the runtime does not want to.

A consequence of this is, disturbingly, that the place where non-overridden overloaded methods are defined in the class hierarchy is of essential importance what regards the selection of the method being actually called. To me, this sounds a little scary, or would you really want your class design to be influenced by the crippled demands of overloading? Summing up: Overloading is a static compile-time feature which does not integrate well with our expectations shaped by dynamic method lookup coming along with inheritance.

What else can we do to shoot the dead man? (Who is still alive enough to ruin our programs, of course.) Bertrand Meyer sees overloading as a violation of the "principle of non-deception: differences in semantics should be reflected by differences in the text of the software" (OOSC 94, Bertrand Meyer). But wait a second, isn't late binding another case where there is only one method symbol for different methods?

As I understand it, the difference between late binding and overloading can be pinned to the observation that late binding lets one method name to be the pointer to one operation contract (which then can be fulfilled by several different methods whose differences are nevertheless absolutely transparent to the client code), whereas overloading lets one method name to be the pointer for several method specifications whose differences can be experienced in the client code. In the scope of the client, there is no difference between polymorphic calls bound to different methods. The polymorphic call specification is all the client has to know about the call. Overloaded methods, on the other hand, need not share common semantics, to be more precise, a common contract, their pre- and postconditions potentially varying wildly. This is something the client always has to take into account: Overloaded methods can not be used interchangeably, as different methods just under the same hood they have to be treated according to their specific contracts. These contracts, however, are hidden behind the same name which makes them hard to identify.The same method name does not point to a common denominator, in this case, but only serves to disguise differences that have to be laboriously disambiguated lateron. The client has to stay aware of the method contract being pointed to by a complicated three component key for the method which, as we have seen, consists of target reference type, method name, and parameter reference types.

So what are my final words to the programmer who, after having read this article, wonders if he should try to use overloading now wherever possible or not? Keep going... And if you really, really want to use it, go on and do so, but only with different method names - this is a trick stolen from real experts that can improve your overloading a lot! :o)

2003-08-12T21:16:00.000-07:00

James Gosling:

I've been inescapably tagged as "the Java guy", despite the fact that I havn't worked in the Java product organization for a couple of years (I do still kibbitz). These days I work at Sun's research lab about two thirds of the time, and do customer visits and talks the other third.

2003-08-12T05:44:00.000-07:00

SCEA meterial :http://www.leocrawford.org.uk/work/jcea

2003-08-05T07:40:00.000-07:00

"I've always had this question: do we invent patterns or do we discover them? By definition patterns are sets of (problem-context-solution) and have value only if the problem occurs repeatedly. So it's clear that we invent neither the problem nor the context..."

- Tunisian

2003-08-04T22:48:00.000-07:00

Patterns 101: The Factory Method
The source code listings for this article are available in our download section.

It looks as though there are still a lot of software developers out there that just don't get it when it comes to design patterns. When interviewing architects and senior developers, I always ask the following question: "Are you familiar with design patterns, and if so, how would you describe the value in applying them to your work?"

For the most part, I get either no answer or a textbook answer without much substance. I guess that shouldn't be too surprising. I personally picked up the book Design Patterns: Elements of Reusable Object-Oriented Software by the so-called Gang of Four (or GoF for short) several times before I understood patterns, each time saying "this time I'm going to get it". I never did; or at least not by reading the book anyway.

I finally got it while designing an application a couple of years ago. This was an application that I knew would eventually have to be extended to handle new (and changing) requirements. I started sketching out my design, and as I did so, I remembered some things I had read about factories, commands, and how they related to pattern basics. Suddenly those ideas made sense and guided me through a design that stood up to extension. Now that I understand pattern basics and how they apply to my design, I get a lot more out of reading about new patterns.

This article is intended to be very fundamental as it applies to patterns. Anyone who has a basic or strong understanding of the importance and appropriate use of patterns will probably not learn anything new. This article is directed at the developer who has heard about patterns or read about them and finds himself or herself saying "I just don't get it." If that describes you and you are willing to give this article careful thought, I'm confident that this will be a turning point for you. I believe we can make the light bulb go on by taking a simple problem, first doing it the wrong way, and then doing it the right way.

So if you think you have something to learn about design patterns, then on to the example...

The Factory Method Pattern
There are a slew of design patterns out there. Let's look at one of the basics: the factory method. A factory method class commits to return an object of a base class (or interface). The object returned by the factory method will actually be a subclass of that type. The calling program will treat that object in the generic manner (as defined by the base class), and the object will demonstrate specific functionality (of the extended class). These statements will become clearer after we've stepped through the example. You may want to read this paragraph again, once you have a better understanding of the approach.

Example: My Tasks
Being a software architect, I can't remember what I'm supposed to do without writing it down, so I've composed a program to list my daily tasks based on what day of the week it is.

Here is my task list:
Monday: Move the trash to the curb
Tuesday: Put out the recyclables
Wednesday: Tape "South Park"
Thursday: Move the trash to the curb
Friday: Buy beer
See Listing 1: MainProcedural.java for the class I've written to display those tasks.

Note that this class doesn't give me any direction on the weekends. After some time, I decide to extend it to include my weekend tasks:

Saturday: Cut the lawn
Sunday: Call Mom.
The changes I have to make are pretty straight forward:

Change the switch statement to include cases for Saturday and Sunday.
Write new methods to handle the task displays: showSaturdayTasks() and showSundayTasks().
There's an object oriented guideline that I've found to be pretty consistently valid: if you're asking a lot of questions about the nature of your objects in the operational parts of your application, you probably aren't taking an object oriented approach to the problem. In other words, if you see a lot of if, switch, and instanceof statements when you're dealing with your objects, there's a good chance you have some room to improve your design.

So I decide I'm not going to modify my application as I've indicated above. First, I'm going to redesign it with what I consider a better approach:

I'm going to replace the switch statement with a static method in a class that will function as a factory.
I'm going to replace the show[Day]Tasks() methods with individual classes that extend a new base class called DayTasks. (A whole class for each day of the week? And it just prints out a task list? Yeah, probably overkill for this example, but bear with me; it makes sense.)
So I will replace MainProcedural.java with these classes:

The central class as shown in Listing 2: MainPatterns.java
The factory class, as shown in Listing 3: DayTaskFactory.java, that will return us a specific class depending on what day of the week it is.
An abstract base class as shown in Listing 4: DayTasks.java. The core class will deal with objects of this type. We could have just as easily made DayTasks.java an interface.
Five other classes, as shown in Listing 5, that each extend DayTasks.java and manage the specific message for the day of the week.
These classes will each extend DayTasks.java and manage the specific message for the day of the week.

When I run this application, my output is identical to my procedural design. That's not a surprise. We don't employ a pattern-based approach for the application end-user's benefit (not directly, anyway).

So what can I accomplish with design patterns that can't be done with a more traditional procedural approach? If you're talking about application functionality, the answer is: probably nothing. Patterns deal with how you design your system and organize your code. The example in this article will demonstrate how the procedural approach builds a routine and the pattern approach builds a framework. This pattern approach lends itself to simpler extensibility because decision-making is handled in the factory, which itself hides (or encapsulates) the operational specifics that are handled in the DayTasks subclasses. With the procedural approach, the separation of functionality isn't organized (or separated) as well. The act of encapsulating variation is an important principle that runs throughout the object oriented paradigm and many software patterns.

So my initial modification plans:

Change the switch statement to include cases for Saturday and Sunday.
Write new methods to handle the task displays: showSaturdayTasks() and showSundayTasks().
Are now replaced with these plans:

Create classes that print messages for Saturday and Sunday.
Modify the factory to also return these classes.
The modified factory is provided in Listing 6: DayTaskFactory.java, and new classes for Saturday and Sunday are provided in Listing 7.

The Important Part
The reader might think: "So basically you just moved the switch statement into the factory and handled the messages in separate classes instead of using specific methods. Is that such a big deal?"

Response: Yeah, it is. That's the whole idea. It may not seem like such a big deal with this trivial example (in fact it may seem like more work), but as the core application gets more complicated, and the scope of the application grows, the organization of application code is a very big deal. The second approach is more suitable for teams of developers: each developer could work on his or her DayTasks subclasses without worrying about dependencies, working on the same file concurrently, or duplicating effort. And imagine that you got your core classes to the point where they were stable, handling exceptions where necessary, logging, and performing other base functionality as well. Isn't it nice that you extended the functionality of the system at large without touching the core class? That's why this approach is considered a framework: the functionality was extended by adding a class that plugged in to the existing model - a class that wasn't even conceived by the time the core class stabilized.

What are the major points?

The approach we took here is founded on encapsulating variation and polymorphism. Each task (or set of tasks) for a day descends from a common interface (DayTasks). We only deal with this common interface (which the factory always returns), while the underlying implementation may provide varying behavior.
The purpose of a factory class is to isolate the decision-making code of your system. Of course you may need separate factories if you're dealing with a range of object types. When you are comfortable with the concepts presented in this article, you may want to read about a related pattern that builds on the factory method – the abstract factory.
We extended the functionality of our program without changing the core classes (class, in this case), and that's a good thing.
Conclusion
So that's it. I think by having a grasp of the why when it comes to patterns, you can understand what they are. As I mentioned earlier, you might have to implement an example similar to the one presented here to fully understand and appreciate the approach. Look for some application you've written that has a switch statement or a series of if/else conditions. Look at the statements that are called in each if/else block and think about the base classes and extended classes that can perform the necessary operations. You may never code an application the same old way again.

2003-08-04T07:51:00.000-07:00

http://www.modelingstyle.info/ for UML Diagram Tips & Guidelines
http://www.itbookclub.net/ for books
http://www.bredemeyer.com/ for Architecture
http://www.softwarearchitect.biz/ for the same above

2003-08-04T07:45:00.000-07:00

This is a good Resource for Java 1.4 Examples by Package wise http://javaalmanac.com/

2003-07-31T21:20:00.000-07:00

This guys blog is very cool(Siva Jagadeesan) http://java2simple.blog-city.com/

2003-07-30T21:44:00.000-07:00

Urban performance legends : http://www-106.ibm.com/developerworks/java/library/j-jtp04223.html?ca=dgr-lnxw01JavaUrbanLegends

2003-07-30T21:35:00.000-07:00

http://www.javacamp.org/index.html Has some good stuff

2003-07-30T21:28:00.000-07:00

Intersting link from Suds blog on J Vs c#

http://www.javacamp.org/javavscsharp/

2003-07-30T21:23:00.000-07:00

I got dragged into a little flame-fest on a mailing list and got a little out of hand... Here's a email from me:
--------------------------------------------------------------------------------

What a troll-ish set of remarks based on zero knowledge and spreading massive falsehoods. Normally I don't respond to such drivel, but this time, if feels like I have to:

From: XXX Subject: Re: YYY
No, as I understand it he is a C developer.

It is true, I have been a C developer, and I still do occasionally. But I have also developed code in C++, Fortran, Algol, SNOBOL, Mesa, Smalltalk, Pascal, Modula, Simula, Cobol, Basic, Focal, BLISS, PL/1, Pearl, several versions of Lisp, and assembler code for x86, Sparc, PowerPC, IBM 360/370, CDC 7000(CPU and PPU), PDP {8,10,11,VAX} and a bunch of stuff too obscure for me to remember at all. Of that lot I've probably written the most in C - at least 500K lines of C written by me, personally, over a couple of decades. For the last decade I've written almost zero C code and write almost exclusively in Java.
Apart from throwing T-shirts, he hasn't done any work with Java lately.
One could start a Clintonian debate on the use of the word "with". Almost everything I write is in Java these days. I mostly work on things other than the compiler or the JDK release.

This is the piece that makes my blood boil:

He designed Java so marginally capable developers could have a job. Hence all the annoying little limitations that slow down development but prevent errors (and features). He finds it too limiting to use himself. I can't really blame him.
This is so damned false I don't know where to begin. I designed Java so I could write more code in less time and have it be way more reliable. In the past I've wasted huge numbers of hours chasing down memory smashes and all the other time wasters that are so typical of what happens when writing C code. I wanted to spend time writing code, not debugging. Life is too short for debugging. All of those little "limitations" turn out to be things that make coding faster and debugging vanish.

For example, lots of newbie's coming in from the C world complain about exceptions and the fact that they have to put exception handling all over the place - they want to just write their code. But that's stupid: most C code never checks return codes and so it tends to be very fragile. If you want to build something really robust, you need to pay attention to things that can go wrong and most folks don't in the C world because it's just to damn hard.

One of the design principles behind Java is that I don't care much about how long it takes to slap together something that kinda works. The real measure is how long it takes to write something solid. Lots have studies have been done on developer productivity, and Java beats C and C++ by a factor of 2.

It's kinda like the evolution of the airplane. Once upon a time when folks scooted around in open cockpit biplanes they navigated by sticking their heads out over the side of the plane and looking down. When covered cockpits with windows were first introduced pilots didn't like them because there was no way to stick their head out. But if they had won the argument, they'd never have been able to fly at Mach 1 or at 30,000 feet. Stick your head into a Mach 1 airflow and see what the bloody stump looks like. I want to fly at Mach 1. I'll take the windows.

On Sunday, July 27, 2003, at 02:55 PM, ZZZ wrote:
I've forgotten, is Gosling a Java developer? If he is, why does he use a Mac? Masochism? "A state of denial"?

I use the MAC because it's a great platform. One of the nice things about developing in Java on the MAC is that you get to develop on a lovely machine, but you don't cut yourself off from deploying on other platforms. It's a fast and easy platform to develop on. Rock solid. I never reboot my machine... Really! Opening and closing the lid on a Powerbook actually works. The machine is up and running instantly when you open it up. No viruses. Great UI. All the Java tools work here: NetBeans and JEdit are the ones I use most. I tend to think of OSX and Linux with QA and Taste.

2003-07-30T21:18:00.001-07:00

I was quite busy and not updating my blog (Huh..) I will do bloggging from today..

2003-07-30T21:18:00.000-07:00

I was quite busy and not updating my blog (Huh..) I will do bloggging from today..

2003-07-27T21:40:00.000-07:00

Check out www.jpackage.org. If you're running Linux and need anything Java-related, then this is definitely the place to go. The JPackage Project has two primary goals:

To provide a coherent set of Java software packages for Linux, satisfying all quality requirements of other applications.
To establish an efficient and robust policy for Java software installation.

2003-07-24T04:24:00.000-07:00

Viva - Open Source Java - Operation Java Freedom --> http://viva.sourceforge.net/

This has some good links so far...

2003-07-23T00:00:00.000-07:00

Rise of the blogs http://www.smh.com.au/articles/2003/06/06/1054700380653.html

2003-07-22T05:05:00.000-07:00

2003-07-22T03:53:00.000-07:00

How to Work with Poor Code

It is very common to have to work with poor quality code that someone else has written. Don't think too poorly of them, however, until you have walked in their shoes. They may have been asked very consciously to get something done quickly to meet schedule pressure. Regardless, in order to work with unclear code you must understand it. To understand it takes learning time, and that time will have to come out of some schedule, somewhere, and you must insist on it. To understand it, you will have to read the source code. You will probably have to experiment with it.
This is a good time to document, even if it is only for yourself, because the act of trying to document the code will force you to consider angles you might not have considered, and the resulting document may be useful. While you're doing this, consider what it would take to rewrite some or all of the code. Would it actually save time to rewrite some of it? Could you trust it better if you rewrote it? Be careful of arrogance here. If you rewrite it, it will be easier for you to deal with, but will it really be easier for the next person who has to read it? If you rewrite it, what will the test burden be? Will the need to re-test it outweigh any benefits that might be gained?
In any estimate that you make for work against code you didn't write, the quality of that code should affect your perception of the risk of problems and unk-unks.
It is important to remember that abstraction and encapsulation, two of a programmer's best tools, are particularly applicable to lousy code. You may not be able to redesign a large block of code, but if you can add a certain amount of abstraction to it you can obtain some of the benefits of a good design without reworking the whole mess. In particular, you can try to wall off the parts that are particularly bad so that they may be redesigned independently.

2003-07-22T03:50:00.000-07:00

Singleton

The office of the Presidency of the United States is an example of a Singleton, since there can be at most one active
president at any given time. Regardless of who holds the office, the title “The President of the United States” is a
global point of reference to the individual.

2003-07-22T00:48:00.000-07:00

http://weblogs.java.net/jag/

2003-07-22T00:35:00.000-07:00

Interesting: Java Vs C# for CONST declaration

In Java there is no direct CONST keyword available, We need to make it by declaring static final.
In C# CONST is there which acts similar to static final in Java.
What is the diff between final, static final?
Here is my answer. final variable will be given memory location each time the object is instantiated.
But if we declare it as static final then it will act as CONST.

2003-07-21T06:14:00.000-07:00

2003-07-21T02:20:00.000-07:00

The new Java logo was unveiled at this year's JavaOne conference. There was so much secrecy around the logo that, even though O'Reilly edits the content for java.net and the new logo sits at the top of every page. How come I dont know this ????

2003-07-21T02:18:00.000-07:00

This is all about human tendancy towards emotions.. killing your emotions is literally killing yourself.

.NET Truths http://manand.typepad.com/DotnetTruth/

Java Good and Bads

An Article on Hungarian Notation

2003-07-21T01:34:00.000-07:00

It has been quite exciting to write about .NET (C#). Huh!! I started reading C# to know how well MS has tried to clone the C++ and Java. Here are some interesting points I noted to share with you.( I welcome Comments/Answers...)

1. When I come across the point from Tom Archer (The Book I am reading Inside C#) said Java is not pure OO language. He has given the reason that "Java is has no compatibility with Primitive Data Types.

2. C# does not follow Hungarian Notation but there is an exception for Interface declaration.

3. We can have as many main methods in different classes which is saved with single file name we can call explicitly those main methods based on the need/testing purpose. I don't understand why he has given this option.

4. MS again proved that it gives programmer friendly languages by allowing to declare directives and assigning.
Ex: Using console= System.Console;
console.WriteLine();

5. One more included option in C# which is not there in Java (If I am wrong please correct me) is Read-Only fields. This is good to see.

6. I guess: A C# file when complied is converted to MSIL file which is PLATFORM INDEPENDENT and CLR (PLATFORM DEPENDENT) will interpret to give the output in the runtime. --> Correct me if not as I have not read anything about this earlier...

These are just basic outlines I found during my 100 pages visits of that book. I am about to start Garbage Collection.

2003-07-19T09:26:00.000-07:00

this is my first blog...how is it looking ? a one liner ?