Counterintuitive behaviour when sending LinkedBulkRead request with custom classes?

I've noticed the following (pseudo-)code does not work, it's related to sending a LinkedBulkRead request with a custom class for the linked information (I've added a rather short incremental id for the Accounts entries):

       SugarRestRequest request = new SugarRestRequest(
                RequestType.LinkedBulkRead);
        Map<Object, List<String>> linkedListInfo = new HashMap<Object, List<String>>();
        List<String> selectAccountFields = new ArrayList<String>();
        selectAccountFields.add("id_incr");
        linkedListInfo.put(CustomAccount.class, selectAccountFields);
        request.setModuleName("Contacts");
        request.getOptions().setLinkedModules(linkedListInfo);
        SugarRestResponse response = client.execute(request);

The CustomAccount class is a class with the following declaration (first line :):
public class CustomAccount extends Accounts {

and it includes a id_incr field.

Now, the (a bit) confusing thing was that instead of
linkedListInfo.put(CustomAccount.class, selectAccountFields);

I had to use
linkedListInfo.put(Accounts.class, selectAccountFields);

in the request. So I had to use the super class of CustomAccount and then it seemed to work fine. Eventually this problem is due to the code at

SugarOnRest/sugaronrest/src/main/java/com/sugaronrest/restapicalls/ModuleInfo.java

Line 150 in 667aa10

    
           Class moduleClass = Class.forName(PackageName + "." + className, false, classLoader);

, it tried to find the class "com.sugaronrest.modules.CustomAccount" which of course does not exist. I'm not sure if this can be fixed in an easy way, but I think it would be better when in the linkedModules list also custom classes could be used directly.

Thanks for spotting that. The class type used must always be the base class for custom classes.
Will change that soon.

BTW: I think you need this change Frankst2@4cb1744#diff-21e232aab8561b47fd87b2c1f4f2346f and this change Frankst2@4cb1744#diff-4ed644722cd943f9b8827f320583ddeb (so Module and ModuleInfo) to fix this problem (I fixed the problem as part of my work on issue #5). The change to Module is important so that custom classes will inherit the @module annotation from the original class. Otherwise the client code won't find the module info.

Fixed by pull request #7.