Brendon McCullum

Hi Paul,

Thanks that cleared my doubts.

Hello all, I'm going through Item 25, Effective Java in which the author quotes:

   static <E> E reduce(List<E> list, Function<E> f, E initVal) {        E[] snapshot = (E[]) list.toArray();        E result = initVal;        for (E e: snapshot) {            result = f.apply(result, e);        }        return result;    }    interface Function<T> {        T apply(T arg1, T arg2);    }

The runtime type of snapshot is Object[] hence it is said that casting it to E[] is dangerous. The author also says that with minor modifications, this program could throw a ClassCastException at runtime. But since the list contains only objects of 'E' type, there's no possibility of array containing objects of any other type. Hence, the cast should work in all cases, and suppressing the warning should work as we can see this is type-safe. Can someone explain, how the above program can throw exception at runtime with little modifications or what's the issue in this snippet of code.

@Campbell thanks for your reply. I second your point regarding not needing atomic references if all methods are locked. This is an interview question to be specific, so I just needed to know whether the above requirements will be fulfilled with above design. getBalance() and getLast5Txn() are required to be non-blocking hence even though the behaviour might not be consistent considering there's no order of threads execution, but they should just be non-blocking.

You can deposit $1,000,000 in thread 0 and withdraw $1,000,000 in thread 1 simultaneously; sometimes the withdrawal will work and sometimes it will throw an exception because the deposit isn't completed yet

That's correct, but the requirement is just to ensure there's thread safety so that there's no dirty read-write.
Again, I think I should have specified this is an interview question, so even though the above design might have some flaws, it should just satisfy the requirements.

Nevertheless, your inputs will help me make it a better design.

Thanks for your reply @Campbell @Salil.
1. Using AtomicReference makes sense so that the write operations are atomic and there's no dirty value.
2. Using reentrant lock is a good idea so that existing thread isn't stuck trying to call another synchronized method from the existing synchronized method. I understand your point, just want to confirm that in case all synchronized methods are totally independent (not invoking each other at all), is there any other benefit that Reentrant lock would provide?

Thanks.

I was going through a question, in which it is required to design some basic operations for bank system. The specific methods asked are:
1. debit()
2. credit()
3. getBalance()
4. last5txn()

getBalance() and last5Txn() should be designed such a way that it is non-blocking (even if they provide dirty balance). Debit and credit must be blocking though (to mitigate dirty-read write)

I have designed a basic system, the code for which is as follows:

public class Account {    private String accountNo = "1234";    private double balance = 10000; // dummy balance    private int transactionCount = 0;    private List<AccountTransaction> transactions = new ArrayList<>();    public synchronized void debit(double amount) {        if (amount > balance) {            throw new IllegalStateException("Not enough balance");        }        transactionCount++;        AccountTransaction transaction = new AccountTransaction(amount, "debit", System.currentTimeMillis(), "INR", accountNo);        transactions.add(transaction);        balance -= amount;    }    public synchronized void credit(double amount) {        if (amount <= 0) {            throw new IllegalStateException("Amount must be greater than 0");        }        transactionCount++;        AccountTransaction transaction = new AccountTransaction(amount, "credit", System.currentTimeMillis(), "INR", accountNo);        transactions.add(transaction);        balance += amount;    }    public double getBalance() {        return balance;    }    public String getLast5Txn() {        StringBuilder result = new StringBuilder();        if (transactions.size() == 0) {            return "No transactions to show";        }        for (int i = transactions.size() - 1; i >= 0 && i > transactions.size() - 5; i--) {            result.append("Transaction " + (transactions.size() - i + 1) + " :");            result.append(transactions.get(i).toString() + "\n");        }        return result.toString();    } } // Account transaction class class AccountTransaction {    final double amount;    final String mode;    final long timestamp;    final String currency;    final String accountNo;    AccountTransaction(double amount, String mode, long timestamp, String currency, String accountNo) {        this.amount = amount;        this.mode = mode;        this.timestamp = timestamp;        this.currency = currency;        this.accountNo = accountNo;    }    @Override    public String toString() {        return currency + " " + amount + " " + mode + " \n"                + " Account No: " + accountNo + " \n"                + " Time: " + new Date(timestamp);    } }

I need some suggestions regarding following:
1. Will the above design work for a multithreaded system (Since the question is primarily focused on multithreading)
2. Secondary question - How can the design aspect for this be improved.

Will appreciate help from you folks.
Regards.

Hi Stephan (sorry for the typo earlier).

How are you going to unit test your service for different configurations? What if somebody introduces a piece of code that beats your client to the punch in initializing the service? There are so many opportunities for this code to break or introduce unexpected side effects. It's a really REALLY bad idea to do this.

This is actually a requirement. It is a SDK where in the clients will set some configuration parameters at initialization time, and there could be different values passed to the SDK depending on different clients. And the values will remain constant (once set at initialization) over the lifetime of the SDK. So I really don't have any control over it. In case you have a better approach to tackle this problem, please let me know, but the requirement cannot be changed. Else I will be making the builder public as you suggested.

All other things are well defined, as you suggested I'll be doing synchronization using a static lock. Thanks for your reply.

Hi Stephen,

I don't insist on using the singleton pattern, the motto is just to limit the instance count to 1. Though your solution seems good, but I don't get how the client will be able to pass required properties to Service class, since builder constructor is private. Can you please let me know about that?
Also, I just needed to provide synchronization, so there's no reason that I can't use anything other than double checking. I will use the initialization-on demand holder as you suggested. Thanks.

Hi Junilu,

Thanks for your reply.
1. You're right that singleton has to be a single instance. But the point is that the instance can be created by multiple ways, the client may give optParam1 or optParam2, or may not give any optParam. That was the reason behind using builder, as I don't want to have many constructors for initializing different set of parameters.

2. The synchronization mechanism, as you said is broken. I will fix it using volatile. I wasn't even aware that double checked locking is broken.

3. Regarding parameter names, they are just temporary names. The actual implementation won't have optParam1 and optParam2. It was just to illustrate the problem here. So that's not a problem.

I would want your suggestions for point 1. In case I have 9 parameters out of which 6 or 7 are optional and different clients of the SDK may set 1,2.. or more parameters, how should I handle it. I don't think passing all of them in a single method call would be a good solution. So, please help me there with maybe a little bit code. Thanks a lot for your time and suggestions.

I'm designing a SDK in Java, and for initialization, have a SDK application level class. The clients must provide some parameter while initializing while some other parameters are optional. Also, these parameters are to be used throughout the SDK (across different classes in different packages) so it gives me a feeling of making it a singleton. However, the optional parameters point to a builder being a good choice for preparing the object. The code looks like below:

public class SDKClass {  private final String mJson;  private Context mContext;  private final SDKCallbackListener mSDKCallbackListener;  private static volatile SDKClass singleton;  private boolean mIsDebuggable;  private boolean mIsLoginRequired;  private String mOptParam1;  private String mOptParam2;  private boolean mOptParam3;  public boolean isOptParam3() {    return mOptParam3;  }  public Context getContext() {    return mContext;  }  public String getOptParam1() {    return mOptParam1;  }  public String getOptParam2() {    return mOptParam2;  }  private SDKClass(SDKBuilder builder) {    if (builder == null) {      throw new IllegalArgumentException("Builder cannot be null");    }    if (builder.mJson == null) {      throw new IllegalArgumentException("json is null");    }    if (builder.mSDKCallbackListener == null) {      throw new IllegalArgumentException("Callback listener cannot be null");    }    mJson = builder.mJson;    mSDKCallbackListener = builder.mSDKCallbackListener;    // Optional params    mOptParam1 = builder.mOptParam1;    mOptParam2 = builder.mOptParam2;    mOptParam3 = builder.mOptParam3;  }  public static class SDKBuilder {    private final String mJson;    private String mOptParam1;    private String mOptParam2;    private boolean mOptParam3;    private SDKCallbackListener mSDKCallbackListener;    SDKBuilder(String json, CallbackListener sdkCallbacksListener) {      this.mJson = json;      mSDKCallbackListener = sdkCallbacksListener;    }    SDKBuilder optParam1(String optParam1) {      this.mOptParam1 = optParam1;      return this;    }    SDKBuilder optParam2(String optParam2) {      this.mOptParam2 = optParam2;      return this;    }    SDKBuilder optParam3(boolean optParam3) {      this.mOptParam3 = optParam3;      return this;    }    public SDKClass build() throws IllegalArgumentException {      return prepareInstance(this);    }  }  /** Prepares instance using builder. **/  private static SDKClass prepareInstance(SDKBuilder sdkBuilder) {    if (singleton == null) {      synchronized(SDKClass.class) {        if (singleton == null) {          singleton = new SDKClass(sdkBuilder);        }      }    }    return singleton;  }  /** This is for getting instance of SDK throughout different classes. **/  public static SDKClass getInstance() {    return singleton;  } }

I expect the client to create a builder object with necessary as well as optional parameters (if needed), and then get an instance of singleton SDKClass. Also, all these parameters are to be used in different classes of SDK. I'm not really sure if this is the right approach, and would appreciate some help.

I'm studying design patterns from Head First book, and presently on chapter-4 of the book. Here the author has introduced simple factory for creation of objects using composition/ delegation. A few pages later though, Factory method is introduced, and the only difference I see between the two is the way they allow object creation. The former uses composition/delegation for creating objects using simple factories, while the latter defers the object creation using sub-classing. Though even the author has tried to describe the difference between the two in more detail, it's not clear to me. Factory method is indeed displayed as more favorable than simple factory, though the earlier relies on inheritance which is unfavorable over composition/delegation. Can anyone help clearing the differences between the two, and why the factory method is favorable? Also, please don't mix this up with Abstract factory pattern, as I haven't yet studied it.

I'm stuck on the same problem. I know this is a way old thread, but can someone clear the differences between the 2 patterns here?

@Stephen : Thanks for clearing it out.

@Stephen : I agree on all points that you mentioned, and the example also makes sense. I have a doubt though. In your example, you change the isbn of the book, but the object remains the same (as reference is same), but what about in case I change isbn to final (just like String class). How'd it violate the contract then? Thanks.

Hello all, I'm studying the contract between hashcode and equals, and thinking of possible problems that may occur in case only one is overriden. So there are two cases :
1. Override equals only.
2. Override hashcode only.

For the first one, I'm quite clear that overriding equals only will break the contract since logically equal objects will have different hashcodes.
But the second part is a bit confusing. If I only override hashcode (though I know this won't benefit me at all in any scenario), I don't think it violates any of the 3 points mentioned in the contract. Please correct me if I'm wrong.

Does each Java application has separate String pool or all apps share a common pool? To further elaborate, if I have
String str1 = "Brendon" in program 1
String str2 = "Brendon" in program 2
Then will str2 get the same string as that was in str1?