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.
Wow -- that is some ugly code. Why couldn't they use a single varargs method declaration? Does this code need to support older Java versions that lack varargs support?
It may be a performance hack. Varargs results in an array being allocated. I've seen this trick in the past, but they usually stopped at a handful of arguments and let the rest be handled by varargs.
Groovy is chock-full of absurd little microoptimizations that will forever fail to make even the tiniest dent in the general overhead relative to java. For several years there was even an "assume equality of hashes match" shortcut hidden in certain set operation code paths.
When compiled statically groovy has almost zero overhead relative to Java. I appreciate how much effort they have made to keep the overhead low and reduce the bloat as much as they can.
The Java methods with up to 70 arguments are highlighted. This code defines methods with up to 250 arguments. I wonder why the Apache Groovy people didn't choose a number like 256, which is more compatible with other magic numbers in the JVM.
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.
Looks like the type tells you which HTTP status codes are possible from a given route, so that e.g. a route that can return only 200 or 403 is a different type from a route that could return 302. Which makes a lot of sense, because certain transformations / routing directives that you might want to do only make sense for particular HTTP status codes.
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.
I read it a few years ago, when I wanted to know how many methods can there be in a Java class. (count: 2 bytes, but compiler fails to compile such a class a long before that).
Many of the concepts such as structure of class files should still be relevant (fact that all classes start with hex code CAFEBABE etc).
Garbage collection, security should be more or less relevant.
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).