Amond Adams

Ranch Hand
+ Follow
since Nov 28, 2000
Merit badge: grant badges
For More
Cows and Likes
Total received
In last 30 days
Total given
Total received
Received in last 30 days
Total given
Given in last 30 days
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Amond Adams

Hey Dudes,
Lets say stmt.setFetchSize(100) is executed and then ResultSet forms as a reult of a executeQuery() not if the query only returned 10 or 20 rows, whats the cleanist way to determine the actual number of rows present in the ResultSet at any valid instance.
Love and Peace.
Well GRASP are too basic, and its true that most of the patterns are derivations of the following;
High Cohesion
Low Coupling
Model View Separation
But they serve as very very basic patterns. Good to learn and perhaps good to implement in one variation to the other. Yet what are the 9 Patterns a Designer can never do without?
Any dudes in these area want to collaborate for SCJD.
Can any dude enlighten us by naming/briefing the 9 Basic Patterns.
Hey Rita,
Thanks for ur reply. Uh well what u describe is the lexical point of view. And as it goes in A/D lexicality in some instances doesn't make sense.
The thing is cohesion is actually functional cohesion; when applied a single general task is decomposed (functionlly) into many small units which are cohesive because they altogather represent a single general task. Though the above definition should not be considered concrete as it depends upon your problem view.
But you are right about the coupling thing - two disparate seperate atomic entities coupling to provide a result just like using a StringBuffer, internally, to represent JTextField's content.
Yet the utility example corelates more towards Singleton (global accessability).
Now for my original question - what you say about the thin line low coupling and high cohesion share when implementing concrete classes?
Love and Peace
P.S I am so lonely - any one in Ellicott City MD wanna talk java over a cup of java and pool. What u say people.
Hey All,
whats your word - what should be the rule of thumb for considering roles as concepts.
Also will appreciate if someone could explain the thin line btw High Cohesion and Low Coupling.
How does HttpSession now internally implement without explicitly utilizing getSessionID()(deprecated in 2.1)?
23 years ago
Thanks Chap.. I appreciate it.
Thanks guys for your input, I really appreciate it...

[This message has been edited by Amond Adams (edited December 04, 2000).]
Truthfully whats the maximum score anybody got at his/her attempt(s) in Khalid's exam?
Can any one indicate web address for Khalid's mock exam.
And Thanks all for their efforts to learn and teach.
Your new code performs as expected, perhaps you missed the point that interrupt(), interrupted and loosely isInterrupted() are all about internal thread flags, native implementations in C.
When you say interrupt() the thread, you will not kick its state with brute force, all you do is that you set a flag in the internal mechanism of that thread to interrupt. Now if that thread is in sleep or wait or join pool it will try to awake up while throwing an IOException, however if it i'snt in its sleepish mood nothing will happen as it is already in the running or ready state. Now point to remember is that the flag once set to interrupt will stay as flaged strictly unless one of the following happen:
interrupted() is called, the thread itself dies, or IOException is caught. Which means that if you executed interrupt() in running state and then if none of the above occured and that the thread went into sleep/wait/join it is gona get interrupt the second it enters into its sleepish mood, because the flag to interrupt was already set...... Thats what is with your code above........
Simply to understand it better
shuffle you run code as follows:
for(int i=1; i<5; i++){<br /> System.out.print( i + " ");<br /> if(i>2) interrupt();
}catch(InterruptedException e){
and then change again as follows:
for(int i=1; i<5; i++){<br /> System.out.print( i + " ");<br /> if(i>2) interrupt();
}catch(InterruptedException e){
Try and learn well.......
Also it will be polite and humane for one to atleast thank another for his or her efforts....

[This message has been edited by Amond Adams (edited December 04, 2000).]
All objects ever assigned to tmp, will be elligible for gc.
String tmp is declared and only accessable in the "for" loop. Once you move ahead of that loop you loose all accessability (which is the major rule for garbage collection that all inaccessable objects may be marked for gc) Therefore they are certainly eligible for gc.
Now as for the given mock answere there are only two possibilities;
1) Integer.toString(int i) returns a String from String pool, which it does'nt, it explicitly creates a new String(...) and returns its reference while not at all keeping one for itself.
2) Given mock exam answere is wrong!!!
You decide and let me know in any case.
These aren't the old Javaranch times, now one even cares to politely thank for one's efforts.....Uhhh global changes don't you see these things everwhere, especially in countries like India or Pakistan.Isnt that true oh resident of one of them?

Anyway I am short of time and back to your question:
Late Binding;
consider the following code:
Interface I{}
class Parent{}
class Child extends Parent implements I{}
class Test{
public static void main(String[] args){
Parent p = new Child();
I i = (I)p; //to consider
Now when you narrow cast p into i, the compiler at compile time has no assurities that p itself implements i, it compiles ok because thinks its possible that any child of p would, ofcourse in our case it is child which implements so its fine at runtime. But the core issue is that if the compiler was not sure of the p implementing i how it could compile a byte code which contained the implemented versions of I. Well the compiler does'nt it compiles the class into byte code such that the if the p does contain a child which implemented I it will be dynamically binded, hence binding of objects and their methods at runtime is called Late Binding. Even without this non-trival example, above:you should know that java deals with instance classes and methods in nearly every case dynamically through this very late binding..... Therefore all inheritence, polymorphism, object creation, remote object loading etc.. all depend on Late Binding a.k.a. Dynamic Binding.....

Daemon Threads:
Our good buddy, another ranchhand, has already put his word down for us, what I can add is that the JVM does not care for Daemon threads if they are the only ones running and no user thread are alive, in that case it simply exits.
Daemon thread are servant threads and only daemon threads can create Daemon threads and Daemon threads are always grouped in Daemon thread group(s).
However if you want to create a Daemon thread just call t1.setDaemon(true) before you execute t1.start() in you code....
Hope this helps..
Happy Ramadan, Or happy fasting month if you perfer.......

Nice piece of code you wrote there, an Interesting issue by all means.
Though in order to solve this riddle you should understand two things;
1) Simply enough, interrupted State is not persistant.
2) It vanishes once either you have called interrupted() or you have caught InterruptedException, its the later because of which when you call isInterrupted() its issues false; rightly as Thread no longer is in Interrupted State.
Now then a valid question aries if due to catching of InterruptedException the state is removed why in the world tm.isInterrupted() in main yields true?
Ummmmmm. Scratch ones head and then..... hey its easy.......
You see the Thread-0 (for which all the noise is for), not the main one, was sleeping and when you interrupted it; who says it ran immediately.... It has to go to the ready state, be scheduled and then run..Yes... So meanwhile the main thread executes tm.isInterrupted() as thread has yet to catch(IE) that thread is in interrupted state the main's tm.isInterrupted() answeres true, the Thread-0 catches IE clears itself of the interrupted state and then when you say isInterrupted() in Thread-0; there is no way it can say true, as no longer it is in interrupted state.
Now you wanna verify this theory.....
Just insert
}catch(InterruptedException e){
after you call tm.interrupt() in main, before the main's tm.isInterrupted(). Without doubt you'll reach the same conclusion as above........