Microsoft msgraph sdk java problems addressed by odata client

As mentioned in this project README.md I found progress very slow in the development of the capability and usability of the msgraph-sdk-java library.

Below is a quick summary of the problems in msgraph-sdk-java that are solved by odata-client-msgraph. Let me first mention that odata-client-msgraph is so far a one person product that works really well for the use cases at my workplace but that its functionality hasn't been comprehensively tested. I'm happy to support odata-client in a low-key spare time way. I hope odata-client-msgraph can be used as the basis for a future rewrite of the generator for msgraph-sdk-java (after all, Microsoft is well placed to support their own client!).

• inheritance is not modelled in the generated code in msgraph-sdk-java so to get an Attachment as an ItemAttachment requires an extra call to the api. With odata-client-msgraph you just cast the returned object.
• paging through collections is awful! A collection request should return an Iterable with a convenience .stream() method so that paging is not a user concern!
• patch of an object requires reload with just changing field mentioned in .select option or nulling of other fields (how do you null a field in a patch!). With odata-client-msgraph: object.withName("fred").patch()
• All domain objects in msgraph-sdk-java API are mutable and offer field access only (no setters or getters). The clunkiness of patch is a consequence (you can't use immutability to record what has changed exactly). Note that using field access also prevents implementing inheritance.
• The domain objects could have been immutable (for the well-known advantages). Domain objects in odata-client-msgraph are immutable.
• A beta client is not available on Maven Central yet (odata-client generates from any odata metadata service (not all features supported of course) and so only a small amount of extra work was required to support the beta endpoint as well (odata-client-msgraph-beta)).
• Overuse of interfaces in odata-client-msgraph. Twice as many classes as there should be and terrible to follow. The notion of supporting custom sub-classes of existing classes to enable addition of new functionality could be replaced by keeping the library up to date with the latest API.
• EntitySet not supported so some paths not available
• Templating in the generator (LINK here) gets in the way of type-safe code reuse and makes dev much slower. Development is way faster without it. Of course the generator used by msgraph-sdk-java does have to support many languages so there was a tradeoff here that they pay a dear price for. In my opinion the generated code should have been made really good in all aspects in one language before going down the templating route.
• Authentication should be much easier, should support concurrency, and should auto-refresh tokens
• Standard metadata options should not require String parameters. For example there should be a .metadataFull() method rather than the hard to discover .metadata("full")
• The generated code should use modern java.util.time classes
• Null checks should be present when non-null defined by the service metadata
• memory use is higher that it should be because every object created by deserialization retains the JSON it was deserialized from.
• OData metadata enumerations should be represented as java enums but are Strings!
• Generated domain classes have a lot of unused imports. Browsing code with star imports is a horrible experience (unless you are using an IDE which is not all the time).
• odata-client-msgraph is half the size of the msgraph-sdk-java jar because of cleaner design
• use of unit testing is woeful in msgraph-sdk-java. Every interaction with the api can be thought of as an HTTP verb, json or bytes payload, request headers, response payload and response headers. This can be unit tested using a special testing http client implementation to get coverage of the varying types of interaction (GET, PUT, POST, PATCH, streams, returning typed objects, etc.) but no testing of this kind exists.
• Releases of msgraph-sdk-java are infrequent despite very frequent updates to the service metadata. This is a trivial process for odata-client-msgraph and releases are made with a single command line.