Closed leventov closed 8 years ago
Unfortunately it does not support such advanced features. Compare to the original implementation it offers a more open API that lets you access most fields and modify or retrieve them, so that you have better control when creating code. I think in general the API is suitable, but this is surely not an easy task to achieve. Any contributions are welcome :)
I will try to investigate this.
:+1:
In addition to field reads, array element reads and method calls, casts and divisions should be eliminated, bacause Java compilers are probably also not allowed to optimize them in certain cases, to throw ClassCastException
, NullPointerException
(on casts of null
to primitive type) or ArithmeticException
(on division by zero) at the "right" moment.
Great work so far. Unfortunately I cannot help you much with this, because this is absolutely not my expertise and I'm busy with tons of other things. But keep up the good work, and I'm happy to merge new updates!
@phax I haven't abandoned this because I will actually use this, but also very busy. Probably I will finish this at some moment within next couple of months.
Any update on this one???
@phax unfortunately no, for two reasons:
Thanks for the update. That means I could potentially revert your changes :)
All the best for your projects!
Does the CodeModel project or particularly this fork contain any functionality like code analysis and performing simple optimizations, for exampe common subexpression elimination? If not, how do you think how difficult it could be to implement this and how friendly for such analysis/transformations the current API/library design/impl is?