New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Regression caused by new threadsafe API and defaults #27

Closed
henri-tremblay opened this Issue Jun 3, 2015 · 0 comments

Comments

Projects
None yet
1 participant
@henri-tremblay
Contributor

henri-tremblay commented Jun 3, 2015

Migrated from: CodeHaus issue EASYMOCK-16
Original reporter: Henri Tremblay


EasyMock 2.4 introduced a new threadsafe mode, but kept mocks non-threadsafe by default for performance reasons and due to "unknown side effects" [1].

The problem is that non-threadsafe mocks which are used by multiple threads now cause exceptions to be thrown, whereas in 2.3 and earlier there was no exception thrown. This change in default behavior will especially affect testing of Swing apps, which often need to deal with multiple threads (EDT, etc).

As things stand, the cost of upgrading to EasyMock 2.4 and going through all of our tests and changing the code to make all mocks threadsafe is prohibitive.

The possible fixes (as I see them) are:

  1. Change the behavior of MocksBehavior#checkCurrentThreadSameAsLastThread() so that it just logs a warning, rather than throwing an exception.
  2. Remove MocksBehavior#checkCurrentThreadSameAsLastThread(), so that non-threadsafe use matches version 2.3 and prior (no exception is thrown).
  3. Make all mocks threadsafe by default.
  4. Provide an easy way to set the default threadsafe value globally, rather than having to do it mock-by-mock or MocksControl-by-MocksControl.

Personally I think #3 is the best option, especially with the new JVMs that don't incur the synchronization cost unless necessary [2], but if that's completely out of the question, my order of preference after #3 would be #2, #1 and finally #4 (which would just barely be acceptable).

Looking forward to feedback,

Daniel

[1] http://tech.groups.yahoo.com/group/easymock/message/1205

[2] http://java.sun.com/performance/reference/whitepapers/6_performance.html#2.1

@henri-tremblay henri-tremblay self-assigned this Jun 3, 2015

@henri-tremblay henri-tremblay added this to the 2.5 milestone Jun 3, 2015

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment