VCard Avatars vs. the Java Type System

[Georg_Lukas]

So, following a random thread on operators@, I tried to fetch the VCard avatar of the named server.

Unfortunately, Smack prevents me from doing so:

System.err: java.lang.IllegalStateException: The JID 'jabber.tcpreset.net' can not be converted to EntityBareJid
System.err: 	at org.jxmpp.jid.impl.AbstractJid.throwIse(AbstractJid.java:236)
System.err: 	at org.jxmpp.jid.impl.AbstractJid.asEntityBareJidOrThrow(AbstractJid.java:102)
System.err: 	at org.yaxim.androidclient.list.EntityViewLoader$override.loadJid(EntityViewLoader.java:58)
System.err: 	at org.yaxim.androidclient.list.EntityViewLoader$override.access$dispatch(EntityViewLoader.java)
System.err: 	at org.yaxim.androidclient.list.EntityViewLoader.loadJid(EntityViewLoader.java)
System.err: 	at java.lang.reflect.Method.invoke(Native Method)
System.err: 	at com.android.tools.ir.runtime.AndroidInstantRuntime.invokeProtectedMethod(AndroidInstantRuntime.java:143)
System.err: 	at org.yaxim.androidclient.list.EntityViewLoader$override.doInBackground(EntityViewLoader.java:82)
System.err: 	at org.yaxim.androidclient.list.EntityViewLoader$override.access$dispatch(EntityViewLoader.java)
System.err: 	at org.yaxim.androidclient.list.EntityViewLoader.doInBackground(EntityViewLoader.java)
System.err: 	at org.yaxim.androidclient.list.EntityViewLoader.doInBackground(EntityViewLoader.java:24)
System.err: 	at android.os.AsyncTask$2.call(AsyncTask.java:305)
System.err: 	at java.util.concurrent.FutureTask.run(FutureTask.java:237)
System.err: 	at android.os.AsyncTask$SerialExecutor$1.run(AsyncTask.java:243)
System.err: 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1133)
System.err: 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:607)
System.err: 	at java.lang.Thread.run(Thread.java:761)

Similar to MUCs running on a domain JID and Bookmarks not restricted to contain entity JIDs, this is a place where the Smack-imposed type system restrictions prevent client implementations from doing things that are not forbidden by the XEPs.

BTW, the above might be a rather obscure use case, but fetching Avatars from MUC occupants actually requires performing the VCard request on full JIDs.

Therefore, I propose changing the JID type signatures of all Smack APIs and data structures to Jid.

[Flow]

@Georg_Lukas

Therefore, I propose changing the JID type signatures of all Smack APIs and data structures to Jid .

We can certainly change the type in the method signatures where it is sensible. But unconditionally using Jid on all signatures as you suggest would defeat the purpose and re-introduce the bugs where Smack code attempted to parse a Resourcepart from a string, unconditionally assume that the Resourcepart would exists and then do all kind of things if that assumption did not hold.

[Georg_Lukas]

@Flow

unconditionally using Jid on all signatures as you suggest would defeat the purpose

What is the purpose, again? You can’t use the type system to enforce correctness of data incoming from remote systems, and you can not use the type system to force other people to set up their systems in a way that corresponds to the most-obvious but not exclusively-correct reading of a specification.

@Flow

the bugs where Smack code attempted to parse a Resourcepart from a string, unconditionally assume that the Resourcepart would exists and then do all kind of things if that assumption did not hold.

I haven’t followed all of those bugs, but I would assume that the bug is in the unconditionally-doing-things part and not in the parsing-a-JID part. In many cases, an empty resource-part is a valid interpretation as well.