You are very correct that this *is* overly complicated ;) What this block of code (or the calling code) is essentially doing is, given some server bean type (say AS7), it gets a list of versions the server bean type declares (7.0, 7.1). It then takes the "full version" of the server (taken from a proper manifest, which may return 7.1.0.CR1, etc) and it tries to match the minor version. So, it will take 7.1.0.CR1 and try to match it to one of the strings declared as proper versions. 

The weakness here is very obvious. If a 6.4 comes out for example (I know it won't, but pretend), the server beans for 6 only declares 6.0 or 6.1. This code (which was already here) will try to match a String like 6.4.0.Final.GA to either "6.0" or "6.1". Clearly this will fail. As a backup, it attempts to match on major version only. 

This code "works", in that so long as our jboss 6 server bean type declares ALL possible current and future version major.minor strings, it will match one. However, in the event of a 6.4, this will simply return "6", which is not terribly useful. 

Furthermore, for "products" which may have their own version strings entirely (jboss-wonka-1.0.0.Final OR jboss-sadpanda-4.2.0.Final), I would have to have the generic as72 product server bean list ALL possible versions of ANYTHING that's EVER possible. Clearly this is a big API failure. However I can't easily remove or reform the original method because to do so would 1) break api, and 2) possibly beak runtime situations. 

You can easily follow that the modifications I made instead attempt to take the location of the second "." in the string, and simply turn x.y.z.Final.CR1.Beta.whatever and return "x.y".  I would obviously prefer if such magic didn't occur, but I simply can't clean it up for a maintenance release. It's very hard to even know the expectation of the original method since the original code was not properly documented.