Mike. J. Thompson

I'm not white sure what you mean by your question, could you clarify? What is it you're trying to do and what error do you get?

However, a few things I do notice:

* Are you sure that is EasyMock? It looks identical to Mockito to me.

* Your scheduler() method is not easily testable. It takes no parameters and creates its own variables. You can't mock the Runnable it is using because you aren't using dependency injection.

* The scheduler() creates an infinite loop that does nothing but repeatedly call the scheduler() method. What is there to test?

Personally I would say to leave the final modifiers there unless you actually need to mutate the field, especially after going to the effort to add them in

Out of interest, why don't you like instance initializer blocks Campbell?

No, that is perfectly ok. If it wasn't allowed for a class to access its own private members from public or protected methods then private members would be completely useless.

The subclass is not directly accessing the private variable. In fact it isn't even aware it exists. It simply calls the method and lets it do it's thing.

Andres Delrotti wrote:
What if this case happens:


SomeSingletonClass ssc = SomeSingletonClass.getInstance(); //at this point, some other thread acessed the singleton class and changed the value of someParameter //(lets say current value is "val1" and some other thread changed // it to "val2" AT A POINT IN TIME EXACTLY AFTER LINE1 EXECUTES AND BEFORE LINE7 EXECUTES) String someParameter = ssc.getSomeParameter(); //[b]this line will still return "val1" when it should be "val2", unless you do another getInstance()[/b].

The part that I have emboldened doesn't make sense to me. Thread safety issues aside, getInstance() will always return the same object because you've said it's a singleton. Why would calling getInstance() again change anything?

Obviously if the singleton instance is not threadsafe then mutating it from multiple threads will lead to very confusing, non-deterministic behaviour as others have pointed out. And again as others have pointed out singletons are often a bad idea, especially used in the fashion you describe.

Are you aware of how to make an object thread safe?

Edit: Ok, it seems the markup doesn't work in the quotes! I've left it in so you can see which part I had intended to make bold though.

I've read the code, and the incomplete code snippet does not make it clear where the delay method is defined. I don't know if that is meant to be pseudo code or if there really is a delay method in their library, but I don't think you'll find it in any standard Java classes.

A likely implementation (if its a real method) will be to call Thread.sleep(long).

And what do you mean by outside of any class code? You can't write code outside of classes in Java.

Can you post the code or a link to where you saw it? There isn't enough information there to tell you what it is.

Have you got a class called BoysInfo?

One of the things I would like in Java is something similar to named parameters that Python has. This would go some way to solving this issue since the calling sites of the method would be able to specify which parameter each argument was being assigned to. If the parameters have useful names then the code will be clear.

One thing you might want to consider is using the Builder pattern. This is particularly useful for making constructor calls clear, but I also saw someone at Devoxx who adapted this pattern to implement something similar to named parameters for method calls. That is probably overkill in most situations, but could potentially make some code easier to read.

The synchronized keyword locks on the current object (so effectively on this). This means that when one thread enters any of those methods it will acquire the lock before it enters it. No other thread will be able to enter any of those methods while that thread has the lock. But the other threads will still be running, and on modern CPU's that have multiple cores those threads can literally be running at the same time. So when you start multiple threads that all want to run those methods in the same order you are going to end up with a situation where multiple threads try to run one of the methods at the same time.

When that happens, one of them will win and be allowed into the method. The other threads will block at the start of the method, waiting until they can get the lock. When the thread that won finishes the method it will release the lock and go back to the run() method to continue with the next instruction. At that point any of the waiting threads blocked on the method can acquire the lock and go execute the method. It isn't deterministic which thread will get the lock, so you can't have any idea exactly what will happen each time you run the code.

What you have here is called a race condition. You want the code to always increment the variable once and then decrement the variable once, but your synchronization does not guarantee that that will happen. All you have done is ensured that only one thread can be in any of the methods at once, but you haven't ensured that that thread will then run the following methods before another thread gets a go.

You will need to synchronize all three method calls (in the run() method) if you want to ensure that all three methods are called in order by each thread before any other thread can execute.

Stevens Miller wrote:

Stephan van Hulst wrote:
What I'm actually working on is an implementation of the pipes-and-filters pattern. I have three classes: Source, Filter, and Sink. Every Source can generate data, and must have a Sink to send it to. Every Sink must have a Source, from which it will get data.

This doesn't make sense to me, it sounds like the Source and the Sink do not fit together properly because their interfaces are in direct contradiction to each other.

1) The Source has-a Sink and sends data to it. This implies that the Source is in charge of the interaction, and the Sink is passive.

2) The Sink has-a Source and gets data from it. This implies that the Sink is in charge, and the Source is passive.

Obviously both of these situations can't be true, so I don't see why a Source has a Sink and a Sink has a Source. Only one of them needs to know about the other.

There is another option (that Stephan alluded to earlier). You could implement it such that the Source and Sink are not aware of each other at all and both act passively. This would require a driving class that reads from the Source, passes to each filter, and then passes to the Sink at the end.

Stevens Miller wrote:

Stephan van Hulst wrote:The fact that AbstractInOut internally uses an In and an Out object to implement its interface is an implementation detail

I'm really not following you there, Stephan. They have to be the same instance, because I have objects that are going to be called on to implement both interfaces. Having two objects isn't an option, because the behavior of an object when accessed via the Out interface may depend on state that was set previously when it was accessed via the In interface.

The MyInOut IS-A In and it IS-A Out. It is the MyInOut instance that is passed around when you have an object that needs to satisfy both the In and the Out interfaces, not the internal In and Out objects (which are just implementation details that it uses to satisfy its obligations under those interfaces, by delegating to them).

The MyInOut class controls the implementation of the operations that are performed on it. Don't view it as two separate objects, that is just an implementation detail. It is a single object that can be used wherever an In is required, or wherever an Out is required, or wherever an InOut is required.

Are you saying that the In and Out instances aren't really independent of each other and need to know each others internal state? If so then its probably time to reassess the design.

Welcome to the ranch Farhan.

Farhan Karim wrote:can someone tell me how it's solved or provide code for it please

That isn't how it works here. How about you provide your attempt at a solution and ask us specific questions about things you don't understand, and we'll help you from there.

Start by writing down the steps you would take when solving that problem manually.

Stephan's post above is exactly what I'd attempted to describe originally, but it's much clearer with the code explaining it.

From the information you've posted I think that is the best solution.