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