Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [paho-dev] Java client library

Hi Dwayne,

as the Java client has been released at a mature version level (1.0) we can't break the API unless we move to a new major version number (2.0), which I don't want to do right now. Overloading is fine, but moving the URI is not possible.

In MQTT 3.1, the client identifier really was compulsory. Only in 3.1.1 did sending a zero length client id become an option, and many APIs were designed before the 3.1.1 standard appeared. For APIs still under development, like the Lua one, then we can design them around the 3.1.1 features.

Also, for those APIs that have some form of persistent store (the Paho Java and C clients for example), the clientid is used as a key into that store. You can recreate a client object with the same clientid, and the previous state (inflight messages) will be restored. At least in the C client, this is done at create time; you can then inquire on that state before issuing the connect call.


On 10/07/2014 01:47 PM, Bradley, Dwayne wrote:
With Roger Light's clarification on a previous thread about the Lua client, and my new knowledge that the client identifier not really being required for a MQTT client connection to a broker, I'm wondering if the constructor for the MqttClient class in the Java library should be modified.  Should the MqttClient class constructor be overloaded so we could only pass the URI?  Possibly move the identifier to the MqttClientOptions class since it is truly optional?  Thoughts?

Dwayne Bradley
Technology Development Manager
Emerging Technology Office
Duke Energy

paho-dev mailing list
To change your delivery options, retrieve your password, or unsubscribe from this list, visit

Ian Craggs
icraggs@xxxxxxxxxx                 IBM United Kingdom
Paho Project Lead; Committer on Mosquitto

Back to the top