@Inline feature proposal

[publicocean0]

Hi i m working in java projects where performace is important.
it is would be very usefull to jave annotation permitting to convert function and custom lambda structure to inline code.

I hope strongly you will do because i need it really in my code. I wont convert all my project in kotlin for doing it. I decided to continue do work with java ... eventually if lombok will not implement it i will develop my plugin... but i think inside lombok could make it more complete.

[FilipMalczak]

What about synchronized methods? What about stack traces?

This idea seems very un-lombok-y, it doesn't try to reduce boilerplate and automatize common task, but rather changes how the language works.

[randakar]

Not just that. Inlining should be a compiler task. Only the compiler knows exactly where and when methods are used and therefore make correct decisions. The only reason javac can't do that properly right now is because classes are too exposed without modularity to hide their methods from external classes, so javac does not have all the information. Once module use starts being commonplace inlining will become easier. Op 18 mrt. 2018 16:47 schreef "Filip" <notifications@github.com>:

…

What about synchronized methods? What about stack traces? This idea seems very un-lombok-y, it doesn't try to reduce boilerplate and automatize common task, but rather changes how the language works. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#1534 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAKCRZQywW7o3wby3KsRbDPznsvQq1xDks5tfoGjgaJpZM4Q9fJM> .

[Maaartinus]

@randakar I don't think javac can do any useful inlining. Ever.

Given separate compilation, some static inlining is impossible. What's worse, inlining is limited as it leads to a code bloat. You'd better only inline small methods which actually get called often. And that's what JIT does pretty well (not sure about lambdas). Moreover, it can inline methods, which must not be inlined statically (as they're virtual and may be overridden somewhere - JIT can do it and undo it later, if needed).

Currently, javac does no optimizations at all (string concatenation IMHO doesn't count). That's a good thing, as they'd make JIT optimizations more complicated.

Anyway, Lombok couldn't do much inlining as it'd require resolution.

[randakar]

Fair. JIT is in an even better position to do this. That's just compilation in a different place ;-) (My C background shines through a little here, I suppose) Point stands though - doing inlining on the library level is doing it in entirely the wrong place.

…

On Mon, Mar 19, 2018 at 4:33 AM, Maaartinus ***@***.***> wrote: @randakar <https://github.com/randakar> I don't think javac can do any useful inlining. Ever. Given separate compilation, some static inlining is impossible. What's worse, inlining is limited as it leads to a code bloat. You'd better only inline small methods which actually get called often. And that's what JIT does pretty well (not sure about lambdas). Moreover, it can inline methods, which must not be inlined statically (as they're virtual and may be overridden *somewhere* - JIT can do it and undo it later, if needed). Currently, javac does no optimizations at all (string concatenation IMHO doesn't count). That's a good thing, as they'd make JIT optimizations more complicated. Anyway, Lombok couldn't do much inlining as it'd require resolution. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1534 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAKCRaqg-S3-7bMRlWW5cyL3cCMgEIUoks5tfycLgaJpZM4Q9fJM> .

-- "Don't only practice your art, but force your way into it's secrets, for it and knowledge can raise men to the divine." -- Ludwig von Beethoven