How Many Type Parameters Can a Java Method Have?(justinblank.com)
justinblank.com
How Many Type Parameters Can a Java Method Have?
http://justinblank.com/experiments/howmanytypeparameterscanajavamethodhave.html
46 comments
Thanks for that. I confess I got a bit lazy about checking which string was at issue--I'll try to do an update when I get home, if I can make time.
A fun short article, but if you’re too lazy to read, the summary answer is “way more than you will ever need.”
Or if you need that much, your design is severely broken
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?
Read the code comments. ”The purpose is the reduction of the size of the bytecode.”
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.
You can quite clearly see, though, how many arguments GitHub's code highlighter thinks a Java method should have.
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 tried this with the F# mono REPL - it eventually failed after creating a let binding with 1328 params: http://blog.mclemon.io/f-number-polymorphic-parameter-overfl...
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.
I wonder if it would be feasible to scan, say, GitHub or Apache projects to find the highest parameter count in the wild?
Do you mean type parameters or regular parameters? If it's the former(and Scala is allowed) then I think Rho's Result type is a pretty good bet with it's ~60 type arguments: https://github.com/http4s/rho/blob/989db04e6dd828518770a42fd...
Ugh, why would they do that?
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.
From the other news on the front page, scanning the former should now give you the latter as well :)
I can bet it will be Spring. It was always in Top 3 for thing like:
- longest method name
- longest class name
- deepest inheritance tree
- longest method name
- longest class name
- deepest inheritance tree
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.
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.
the early '00 were a lawless wasteland.
the early '00 were a lawless wasteland.
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..
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..
If you were using Hibernate in 2000 and not caught up in the EJB hype, you were ahead of the game.
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).
I imagine that the limit on the .NET CLR is even lower because there needs to be runtime support for type parameters all the way down to the JIT.
I modified the python script to generate C# and it compiled with 131072 type parameters. It did take 9 minutes though so I didn't continue after that.
In theory, the maximum encodable compressed unsigned integer, as used by GenParamCount in MSIL, is 0x1FFFFFFF.
> 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.
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.
Going to leave it here
Inside the Java Virtual Machine by Bill Venners
https://www.artima.com/insidejvm/ed2/
Inside the Java Virtual Machine by Bill Venners
https://www.artima.com/insidejvm/ed2/
Is it still relevant? If you've read it, what's your review in one sentence (or not just in one if you wish :D)?
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.
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.
i wonder if it's possible to generate type parameters such that computation is done with it at compile time?
Java’s generics are Turing complete, though I don’t think anyone has written a useful program in them yet: https://arxiv.org/pdf/1605.05274.pdf
Theoretically, sure: https://arxiv.org/pdf/1605.05274.pdf
I think it's a good idea to link to abstracts https://arxiv.org/abs/1605.05274 (as ygra does (https://news.ycombinator.com/item?id=19777896 )) rather than directly to PDFs.
There's a Prolog in your Scala: https://www.youtube.com/watch?v=iYCR2wzfdUs
It does compile time computations using generics + implicits
It does compile time computations using generics + implicits
https://arxiv.org/abs/1605.05274 perhaps?
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).