One little thing - the string that's running out of space here is the signature of the interface, not the signature of the method. You could use that fact together with method scoped type parameters to get a few more, if it weren't for the fact the descriptor would blow up too soon already.
Since it's not mentioned in the article - the signature of a method is the description containing generic information. The descriptor is the erased signature, which, because A strips to Ljava/lang/Object; will likely be a fair bit longer.
An aside - you can (mostly) still get away with corrupting signatures, if you want to obfuscate code.
I think it's pretty cool that the result emerges, as the author points out, not from the implementation details of any particular JVM, but from well-defined parts of the Java specs intersecting in a fully determined way.
Doubtful. I'd guess it's a general utility library like Guava, where they're doing something with heterogeneous type "vararg" methods. Often they'll have a number of overloads to give the most type help, before reverting to less helpful vararg types.
Anything that's heterogeneous, with dynamic arity to the library but known static types to the caller would be a good candidate. Like NTuple type implementations.
this reminds me of that one table with more than 255 columns which hibernate converted into a class that could not be compiled since the constructor had too many parameters. we split it up using the component mapping to realize some of these column as if they were composition.
Ah, reminds me of something I had to do only two years ago.
Business side would send an excel file with thousands of lines and some columns with some definitions. These we would export to csv and turn into a huge enum using some generator. One definition per line in the excel document, on the form Rule67_Oslo(245, 167, NO_TRANSFER). One day it failed, as the byte count was too big. Managed to strip down the definitions some, but a few weeks later it was impossible to add new rules again. No idea why someone would make that design in the first place, old legacy system. But it was hard to refactor as well, as those constants were littered everywhere in the code as well. I switched teams before it was solved, but I think the fix was mainly that business had to find one rule to remove every time they wanted to add a new one..
maybe because I was fresh out of academia then but neither xml defined behavior nor the ejb looked like something that really removed work, moreover I've always been biased against things I can't put a break-point and debug in the event of having issues (which is also why I skipped on angular, for example).
> Nonetheless, if I was king, I'd consider explicitly banning any class or method from having more than 255 type parameters.
As he says there is probably no use case where you need so many and the additional overhead of time to implement this is (in my eyes) a bit wasted. But he can be actually the king by contributing to the openJDK project.
Readit News
Since it's not mentioned in the article - the signature of a method is the description containing generic information. The descriptor is the erased signature, which, because A strips to Ljava/lang/Object; will likely be a fair bit longer.
An aside - you can (mostly) still get away with corrupting signatures, if you want to obfuscate code.
(eg https://github.com/ItzSomebody/StopDecompilingMyJava/blob/ma... )
(yes, I used to blow up on one of these in https://www.benf.org/other/cfr - (my java decompiler), but it's all good now).
- longest method name
- longest class name
- deepest inheritance tree
Anything that's heterogeneous, with dynamic arity to the library but known static types to the caller would be a good candidate. Like NTuple type implementations.
the early '00 were a lawless wasteland.
Business side would send an excel file with thousands of lines and some columns with some definitions. These we would export to csv and turn into a huge enum using some generator. One definition per line in the excel document, on the form Rule67_Oslo(245, 167, NO_TRANSFER). One day it failed, as the byte count was too big. Managed to strip down the definitions some, but a few weeks later it was impossible to add new rules again. No idea why someone would make that design in the first place, old legacy system. But it was hard to refactor as well, as those constants were littered everywhere in the code as well. I switched teams before it was solved, but I think the fix was mainly that business had to find one rule to remove every time they wanted to add a new one..
As he says there is probably no use case where you need so many and the additional overhead of time to implement this is (in my eyes) a bit wasted. But he can be actually the king by contributing to the openJDK project.