Use more pattern matching in Marshalling class

[BrandonSchmitt]

While this is mostly just syntactic sugar, there is a slight difference in the deSerializeParameters method. Before, if the first type was a subclass of Tuple, the method fetched its type name to then look up the class for that name. However, the class was already loaded and present. So, looking it up again should be a no-op. Reusing the existing clz variable here also prevents a problem in situations with multiple class loaders (e.g. OSGi) where it's not guaranteed that the class can be found by its name.

Btw. I found some more opportunities to do small maintenance work that I would be happy to do, e.g. using val instanceof Collection instead of Collection.class.isInstance(val), removing some unused local variables, or simplifying some if conditions. I would not touch the architecture. Is that something that you would appreciate or would you rather me not messing around too much?

[hypfvieh]

Thanks for your PR.

Regarding your question:
I'm always open to PRs when they add value to the project.

With "add value" I mean something like:

• Improves readability / reduces complexity or helps in understanding the code
• Adds features
• Improves performance
• Adds examples, tests or documentation
• Makes use of new Java features (dependening on the targeted JDK, dbus-java 5.x should comply to JDK 17 while 6.x can use JDK 21 features)

The only PRs I will refuse, are those which only change things for the sake of changing. Also PRs which are just fixing random typos in documentation without adding anything new and helpful might be refused.

So if you have some point you think you can improve - go ahead and provide a PR 😁