Coremodding, and bytecode instrumentation in general, are said to leads to compatibility issues with other instrumenters. This I agree with and try to avoid it as much as possible.

However, one could argue that, if they follow the principle above, no modder should ever tinker with my own code. That would mean that I am free to tinker with it without any compatibility issues.

Uses that come into mind are dynamically generated register/init methods, custom run-time methods for debugging purposes, late removal of debug statements, and a few more.

Some of these can be accomplished with other safer, albeit slower, techniques (eg. reflection), so my question is: Is the efficiency worth it?

Alright. Is there somewhere in gradle I can put a source processor that would strip debug lines, etc? Kinda like the conditional compiling in C#

So I looked at a few popular mods' build script's and found this, which looks like it might do what I wanted:
https://github.com/SleepyTrousers/EnderIO/blob/1.10/build.gradle#L132-L141

I do/did something similar:

https://github.com/Draco18s/ReasonableRealism/blob/master/build.gradle#L49

Scroll all the way to the right, that line is a list of find-replace pairs: the last one is a comment called "uncomment" that when removed enables a section of code.  I had to do this with Reika's API because it would crash Eclipse because it wasn't properly set up to be in the dev environment.  But it compiled and ran in live code just fine.  You could do the same thing with your debug statements, only in reverse.

Oh yeah, that thing. Used it for replacing stuff in my Reference class, didn't think about introducing/removing comments with it. The only issue is that I limit the scope with replaceIn() so that it doesn't go wild on other classes, and I have no idea if two replace scopes are possible with that functionality.

Just have to make sure the thing you're find/replacing isn't generic. "{uncomment}" isn't something that would ever appear anywhere else in my code,

Sorry for reviving an old thread.

 

But isn't this what aspect-oriented programming (AspectJ in Java) is all about? And it looks useful, from what I've read about it, and quite well maintainable.