[JCBC-228] a no-args constructor and an init method are needed Created: 31/Jan/13  Updated: 15/Sep/14  Resolved: 15/Sep/14

Status: Resolved
Project: Couchbase Java Client
Component/s: Core
Affects Version/s: 1.1.0, 1.1.1
Fix Version/s: 2.0.0
Security Level: Public

Type: New Feature Priority: Major
Reporter: Matt Ingenthron Assignee: Michael Nitschinger
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
Currently, the CouchbaseClient does a number of things that are not so pretty, like spinning up a thread from it's ctor. It would be better to add an additional, optional no-args constructor which expects an init method to be called with the other params needed, start thread, etc.

 Comments   
Comment by Michael Nitschinger [ 31/Jan/13 ]
Assigning towards 1.1.2 but we can defer it to 1.1.3 as well.
Comment by Michael Nitschinger [ 19/Dec/13 ]
We'll have something like this in 2.0
Comment by Matt Ingenthron [ 11/Sep/14 ]
Sergey, I think this is true now in 2.0, can you verify and close this if so?
Comment by Sergey Avseyev [ 12/Sep/14 ]
Yes, we have static method create() which does not have any arguments, but it is just provides defaults to full constructor, which does blocking connection anyway.

We might extract connect() method to the public interface, and modify static constructors somehow they will allow to do at least asynchronous connection. I did some sketch here (it just extracts connect() method, but still call it from constructor) http://review.couchbase.org/41397

The patch is not meant to merged, just demonstrate my question.

Matt, could you expand a little bit what we need to achieve?

Does it spawn thread in constructor? No
Does it do blocking connection? Yes
Comment by Matt Ingenthron [ 12/Sep/14 ]
Assigning this to Michael as he's the architecture owner here.

The reason I filed this way back at -228 was that in general, a recommendation with Java is to not do anything requiring IO or threads in the ctor and separate out the actions of setting things up in a separate method. This is often helpful in some frameworks with DI, etc. Imagine for a moment that you throw an IOException from the ctor(). Chances are whatever created that object inline isn't ready to handle that exception right there. However, calling .init() on it and seeing an explicit throws IOException gives the app developer a cleaner way of abstracting the set up of the things and the initializing of the things.

http://www.javapractices.com/topic/TopicAction.do?Id=254

All of these things change over time though, so I trust Michael to pick a solution he can live with.
Comment by Sergey Avseyev [ 12/Sep/14 ]
Michael, I also think that current implementation is good. Abandoned my patch. Please resolve the ticket, or reassign back to me
Comment by Michael Nitschinger [ 15/Sep/14 ]
Yes, we have static factory methods now and should be good on that.

This was actually a relict out of changing the 1.* SDK when we didn't know that 2.0 was a breaking change. So I'm going to close this out.
Comment by Michael Nitschinger [ 15/Sep/14 ]
Requirements have changed since 2.0 is a complete rewrite its not needed anymore
Generated at Wed Nov 26 21:33:07 CST 2014 using JIRA 5.2.4#845-sha1:c9f4cc41abe72fb236945343a1f485c2c844dac9.