Community
Participate
Working Groups
Created attachment 228867 [details] Source code that demonstrates the problem We ran across the following problem today that we managed to trace down to the aspect J compiler. I have attached the sources that simplify the context, removing as much dependencies as possible. The sources therefore do not exactly represent my actual situation but they do produce the problem. I have an autocloseable resource that does not get closed properly when used in the context of a method that returns "boolean". More specifically, when the method is about to return true. If you run the attached class when compiled with AJC it will produce the following output: Closing autoclosable resources failed Autocloseable resource was closed correctly When run with the standard djavac compiler it produces: Autocloseable resource was closed correctly Autocloseable resource was closed correctly We produced the problem first on a local dev PC (windows 7) but once simplified we can reproduce it on whatever platform.
thanks for the source code, I'll take a look when I get a minute.
Looks to be because AspectJ hasn't picked up some Eclipse compiler fixes. Unfortunately on a quick comparison there is a *lot* of change in the eclipse compiler around this area and I'm having trouble picking out a small set of changes that would address only this issue.
I see the target milestone has been set to 1.7.3 for quite a while now. What I would like to know is the planned release date for that version? Thank you.
Figured out in the meantime that 1.7.3 has been released and is available. However, this bug is not on the list of resolved issues. When you do think this problem is going to get solved?
Hi, I have been toying with upgrading the 1.7 line to the latest JDT to pickup the ability to compile against 1.8 jres (not compile 1.8 code but just compile against the JREs) - unfortunately that is a very large piece of work that I'm having great difficult scheduling at the moment (but this would pick up the jdt fix we need for this issue). In the meantime there were a few important fixes I needed to get out so I pushed out 1.7.3. I also have to repeat a very similar large piece of work to grab the 1.8 compiler for AspectJ 1.8 - this would also fix the problem here. The first 1.8 milestones are due in 3Q, but not sure which will contain the compiler upgrade. Is binary weaving perhaps a workaround where you apply the aspects to something passed through a java compiler that does not have this problem?
unsetting the target field which is currently set for something already released
If binary weaving is done at runtime then no, I need to enable the solution on OSGI and I don't think that OSGi is going to like that my code is being woven after loading. (In reply to comment #5) > Hi, > > I have been toying with upgrading the 1.7 line to the latest JDT to pickup > the ability to compile against 1.8 jres (not compile 1.8 code but just > compile against the JREs) - unfortunately that is a very large piece of work > that I'm having great difficult scheduling at the moment (but this would > pick up the jdt fix we need for this issue). In the meantime there were a > few important fixes I needed to get out so I pushed out 1.7.3. > > I also have to repeat a very similar large piece of work to grab the 1.8 > compiler for AspectJ 1.8 - this would also fix the problem here. The first > 1.8 milestones are due in 3Q, but not sure which will contain the compiler > upgrade. > > Is binary weaving perhaps a workaround where you apply the aspects to > something passed through a java compiler that does not have this problem?
binary weaving doesn't have to be done at runtime/loadtime, it can be done at any time post the initial compile. AspectJ takes in built jars, applies aspects and produces woven jars.
