Aneesha Singh

And also as M. Beck says, since a lot of teh code has been written, and uses a lot of objects everywhere, I dont want to sort out which need to be cloned and which dont ... The 'final' clone method is not the issue though ...

Well, Peter .. you are right when you say that its going too far (in terms of the cost of serializing and deserializing instead of writing a clone method) but in my case that doesnt really matter and this is why:

1. Most of the application objects that I am using have already been written without using cloneable/clone. So its a fair bit of work to introduce cloning support and re-test the entire codebase.
2. I am not using the serializing/deserializing for production code but to automate testing data loading to make testing the application easier and faster and make it easier to setup tests.

Keeping these 2 things in mind, it was best to stick with an expensive (in terms of performance time) solution which involved minimum work and minimum tampering with existing code. :-D

Many thanks Yacoob, Jeroen and Ram for your help! I have solved the problem by doing what Ram suggested: implementing his solution (using serialization) with a few tweaks to the code he kindly pasted. Works like a charm!! Thanks again!

BTW, there is an article on JavaWorld with this solution's drawbacks and merits thats worth a look - if performance is not a real issue, its a great way to get around having to clone every single class in your application.

Cheers!

Hi there,

I have a hashmap and my requirement is that I need to retrieve an object from it (using a key I have) and then make some changes to that (retrieved) object and store it back into the hashmap with a different key. The original object in the hashmap must remain unaffected.

The problem is (as expected) that the original object that I retrieve also gets changed and this is something that I dont want :-(.

The object that I need to retrieve and change does not implement cloneable but implements serializable.

Could anyone please help :-)

Many Thanks!

Gratefully,
Aneesha.

Originally posted by Michael Imhof:


I thought, a labelled break is working like a "goto". So after calling
"break lab" it breaks the loop and returns to the label.

If you modify the code to check if it goes into the outer loop after teh break lab statement as follows:
lab: for(int i = 0; i< 10; i++) { System.out.println( "in lab"); for (int j = 0; j< 10; j++) { if ( i+ j > 10 ) break lab; } System.out.println( "hello"); }

You will get the following output:

in lab
hello
in lab
hello
in lab

which shows that the outer loop exits after the labelled break. You are right its 'LIKE' a goto but the difference is that it will goto the label and break the loop that has the label ... I hope that gives it a bit of clarity! :-)

Originally posted by anindam bhattacharaya:
G'day

I have a problem getting to understand this code.
public class TestClass { public static void main(String[] args) { lab : for(int i = 0; i< 10; i++) { for (int j = 0; j< 10; j++) { if ( i+ j > 10 ) break lab; } System.out.println( "hello"); } } }

I am failing to understand why is this printing
"hello" only twice.


( tags added)

[ November 29, 2004: Message edited by: Barry Gaunt ]

The first time the code runs fine, goes through the inner for loop 10 times and never reaches inside the if condition (because i+j is always less than 10).

On coming out of the inner loop it prints hello.

Then i is incremented to 1 AND the above repeats.

Then i is incremented to 2, and in the last iteration of the inner loop it enters the if condition because i+j becomes greater than 10. It goes to statement 'break lab'. lab is the label for the outer loop and the program execution comes out of the outer loop (labelled lab) and the program finishes. Thats the reason hello is printed just once.

in the 1st iteration, i=0,j=0 and i+j not > than 10. print hello
in the 2nd iteration, i=0,j=1 and i+j not > than 10. print hello
in the 3rd iteration, i=0,j=2 and i+j not > than 10. print hello
etc.

Thats because hello is printed in the outer loop after the inner loop is executed. Its not inside teh inner loop. Please note where you have placed your brackets.

Hope that helps :-).

Hi there,

Besides applicability and the like, while reading the GoF patterns most times, I keep thinking that some of them are so alike and if some comparisons between the patterns are given (when to use which, etc .. scenarios, differences, similarities ), it would be great ...
I like the HF representation anyway .. helps to remember things better !!

Thanks for the great books you've done previously!! Really helped!

Aneesha

Because, I think, in the line:

System.out.println(t1);

NULL is returned, throwing a runtime exception.

I thought that in case of NotSupported, the acknowledgement depends on if the method completed properly or threw an exception.

I think it may be because Stateful session beans are associated with an EJBObject at the time of create whereas Stateless beans have no associations and are just lying around in the pool, so they are not allowed.

Originally posted by JayaSiji Gopal:
public class Test {
static int total = 10;
public static void main (String args []) {

At this point, you created an instance of teh class Test. This action invoked the constructor. So when you refer to this in the constructor, you refer to teh class created here. So the 3rd option is indeed correct.
Hope that helps.

new Test();
}
public Test () {
System.out.println("In test");
System.out.println(this);
int temp = this.total;
if (temp > 5) {
System.out.println(temp);
}}}

The compiler reports an error at line 2
The class will not compile
The value 10 is one of the elements printed to the standard output
The compiler reports an error at line 9
The class compiles but generates a runtime error

i answered the 4th option,but the correct answer is 3.
i answered 4th, bcos static variables cannot have a this reference.

plz correct me, wht is wrong?

Originally posted by siva kumar:
What are the differences bw RequestProcessor and ActionServlet.

The advantages of RequestProcessor over ActionServlet.

Well, I think, the answer is in the extensible behaviour. You can have the same ActionServlet and inherit the RequestProcessor in your own class to modify the behaviour to what your application requires.
I think thats the reason for separating teh functionality of RequestProcessor and ActionServlet.

Originally posted by manish ahuja:
What I intended to ask from my post was Cant we have caching without resorting to Singleton
Say I use the caching part of the code mentioned in the original post in Scenario1 & force it on scenario2.

Wont I be able to still use caching

In short do we have to have singleton to enable caching or I can have caching even without being a Singleton class

Well!
The thing is that the reason for using a singleton is to provide a single cache. Otherwise you could have multiple instances of the caching class and that would kind of defeat the purpose.
Why dont you want to use a singleton ... is there any particular reason?

Originally posted by manish ahuja:
Hi All

I was going through Sun BluePrints where they show 2 types of service locators

quoting from the blue prints
***************************************
The Java Pet Store sample application, v1.3.1 has two service locators: a Web-tier class ServiceLocator , and an Enterprise JavaBeansTM (EJB) tier class, also called ServiceLocator . Both classes manage lookup and caching of enterprise bean home interfaces, JMS and database connection factories, and environment entries within their respective tiers. The only difference between them is that the Web-tier class is a singleton, and it caches the objects it looks up. The EJB-tier class is not a singleton, and does not cache.
****************************************
Here are the links to the code piece

1) the 1 that looks up as well as caches
http://java.sun.com/blueprints/code/jps131/src/com/sun/j2ee/blueprints/servicelocator/web/ServiceLocator.java.html

This is synchronized. My question is does it have to be that way. In the above code for caching was Singleton necessary

2) the 2nd one looks up but does not cache and is neither a Singleton

http://java.sun.com/blueprints/code/jps131/src/com/sun/j2ee/blueprints/servicelocator/ejb/ServiceLocator.java.html

Do post your viewpoints on the same

Rgrds
Manish

For the first option, it may be preferable to cache the handle rather than the object. Also, one thing to note is that singletons may be unpredictable in a clustered environment.
[ November 18, 2004: Message edited by: Aneesha Singh ]

I agree with Jim. Its declared. How can it be considered 'redeclared' if the class is not even aware of it? The subclass declaring the method is not aware of the superclass method, so it declares it, I would argue .