Torsten Curdt ha scritto:
Am I totally wrong or they are issues in the test suite?
Will have a closer look when I am back from vacation. About to walk out
the door. Back online in two weeks.
So you should be back, or you should do soon.. Hope you are relaxed
because I prepared some work for you ;-)
Should I open a JIRA for this and attach a patch?
Sounds good :)
Here we are:
- https://issues.apache.org/jira/browse/SANDBOX-253
Fix pom dependencies (update asm to latest 2.x and fix jci to a
non-snapshot)
- https://issues.apache.org/jira/browse/SANDBOX-254
wrong expectations in failing junit tests (SimpleTestCase)
- https://issues.apache.org/jira/browse/SANDBOX-255
synchronized(obj) support is missing (locks are not released when
suspending resulting in IllegalMonitorExceptions)
AFAICT the try/catch test works fine once the testsuite assertions
have been corrected, the only failure is on the synchronized-test.
Hm
Please, have a look at SANDBOX-254. I hope I understood enough of
javaflow and that the patch is good!
About the synchronized block and the illegal monitor i'm not sure I
understand how it should work.. should javaflow keep the lock open
during the suspension or tracking the locked objects and try to lock
them again on resume?
No. The lock needs to be released.
Done in SANDBOX-255. Please review.
I had to introduce a new Frame extension "MonitoringFrame" that also
take care of tracking monitorenter/monitorexit so in any given frame it
knows what local variables are locked.
The test included in javaflow and a more advanced test I wrote for it
seems to work, but I'm sure you can think of better tests that can prove
limits for this approach.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
