As to why your current solution works.
A static initializer is not magic. The compiler creates a java static method for that. If you decompile the class file you would see a static method with a weird name.
Initializing your labels involves a static initializer. The compiler creates on of those to initialize the labels.
If the class has many static initializer blocks the compiler can create many methods or just one. I would guess that in your original case that it was creating one (combining the blocks from initializing labels along with your explicit block.) And so you reached the limit.
Your super class solution works because now there are two classes and thus two static initializer blocks. Continuing to add more labels means that problem could occur again.
The only longer term solution without changing the idiom would involve
- The labels must not be final (the size of the labels is not the problem it is the assignment itself so tricks will not help.)
- The label would need to be loaded dynamically and it would require reflection.
ironically, one more thing he can do that might help prolong his misery is to make the code more unreadable by switching to shorter names for labels and other identifiers, and possibly reducing whitespace. Shorter names make for shorter code, which means you're going to take longer to hit the 64K barrier.
Less whitespace might do the same (not sure that's counted, but I think I noticed it was years ago).
Of course eventually his entire house of cards will come crashing down around him but by then he might already have moved on and someone else have to clean up the mess he leaves behind.
Wouldn't be at all atypical if it's someone like us having to make sense of it all in a year or so.
I already ran a small test case to actually see when do my "house of cards will comes down crashing", since I also anticipated that. To my surprise, I only ran into "Code too large" again, after I have added 9.5K more entries, which is equivalent to what we have today.
Coming to the "personal comment" you made about me. So you don't even know me and passed such a remark, what do you call that person. Please choose yourself whatever is appropriate, you seem to be good at that.
I already ran a small test case to actually see when do my "house of cards will comes down crashing", since I also anticipated that.
Your 'house of cards' is just an empty shell.
You seem to be so focused on the solution you want to use for your 'unstated' problem that you just aren't grasping what people are trying to tell you.
1. You are defining PUBLIC, non-final variables.
2. They are INSTANCE variables, not class variables. EVERY INSTANCE will have a copy of those - a total waste of resources
3. You are doing a ONE TIME loading of the map
4. That 'static' method of loading 'hard-coded' values does not scale - in order to change the source code has to be modified and recompiled rather than making a simple change to a properties file.
5. The value of ANY of those variables might change at any time because they are NOT final.
6. The value of ANY of those variables might be different for different instances because they are NOT class variables.
7. Any value in the map may, therefore, be different than values in the actual instances.
8. Your method does NOT use best practices.
You have the absolute WRONG solution for whatever problem you are trying to solve.
The above is just PART of what everyone has been trying to tell you. Please wake up and smell the coffee!
Oh my God.
Let me make it simple. I don't own that piece of module. I heard about this problem, which was completely new. And then this gets fixed. Since, I did not understand the solution I thought of seeking some guidance from Experts, for purely academic purpose.
Is it really that difficult to let it go.
PS: I may not be responding to this thread any further, and request you to do the same.
you added 9500 entries you just said, so it IS your code. That you don't understand it is clear, that you don't want to find a better solution is equally clear.
Difficult to let it go? No, such a mess is very easy to flush down the toilet and replace with something that does work, a concept of which I presented in my very first reply but was ignored by you.
> switching to shorter names.
I have no idea how that would impact it.
Variable names themselves do not impact the method code size. String values, if that is what you meant, wouldn't impact it either.
One solution is to break the one file into other files into categories. If the code growth rate is slow enough and the new usage is promoted then it might be sufficient when the limit would have been reached. Or find an different solution to the problem.
I believe some of the responders are reading more or less in the posts which the OP made.
Far as I can tell the OP is fixing a problem in existing code. The solution that he came up with was to fix that existing code which has grown over time.
And given the nature of what was suggested by usage a real fix would be a major refactor for a substantial amount code.
Given that this is existing code and that it would require a major refactor most of the comments as to why it is not an ideal solutions are irrelevant because they approach it as though this was a new solution with no existing usage.