{"action":"created","issue":{"url":"https://api.github.com/repos/jmockit/jmockit1/issues/292","repository_url":"https://api.github.com/repos/jmockit/jmockit1","labels_url":"https://api.github.com/repos/jmockit/jmockit1/issues/292/labels{/name}","comments_url":"https://api.github.com/repos/jmockit/jmockit1/issues/292/comments","events_url":"https://api.github.com/repos/jmockit/jmockit1/issues/292/events","html_url":"https://github.com/jmockit/jmockit1/issues/292","id":159993320,"number":292,"title":"Expectations with matchers in varargs methods do not work properly","user":{"login":"Vampire","id":325196,"avatar_url":"https://avatars1.githubusercontent.com/u/325196?v=3","gravatar_id":"","url":"https://api.github.com/users/Vampire","html_url":"https://github.com/Vampire","followers_url":"https://api.github.com/users/Vampire/followers","following_url":"https://api.github.com/users/Vampire/following{/other_user}","gists_url":"https://api.github.com/users/Vampire/gists{/gist_id}","starred_url":"https://api.github.com/users/Vampire/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/Vampire/subscriptions","organizations_url":"https://api.github.com/users/Vampire/orgs","repos_url":"https://api.github.com/users/Vampire/repos","events_url":"https://api.github.com/users/Vampire/events{/privacy}","received_events_url":"https://api.github.com/users/Vampire/received_events","type":"User","site_admin":false},"labels":[{"id":112393986,"url":"https://api.github.com/repos/jmockit/jmockit1/labels/enhancement","name":"enhancement","color":"84b6eb","default":true}],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":6,"created_at":"2016-06-13T16:36:51Z","updated_at":"2017-05-11T13:11:53Z","closed_at":null,"body":"I spent the day to find out that my problem actually is the following JMockit bug:\n\nIf I have a method signature like the following\n\n```\nFacesMessage getMessage(Severity severity, String msgKey, Object... msgObjects)\n```\n\nthen it does not work to write in an Expectations block\n\n```\nmessageFactory.getMessage(SEVERITY_ERROR, \"myKey\", \"a,23\", anyString, anyString);\n```\n\nor\n\n```\nmessageFactory.getMessage(SEVERITY_ERROR, anyString, \"a,23\", anyString, anyString);\n```\n\nor\n\n```\nmessageFactory.getMessage(withArgThat(isA(Severity.class)), \"myKey\", \"a,23\", anyString, anyString);\n```\n\nBut it does work if I write either \n\n```\nmessageFactory.getMessage(withArgThat(isA(Severity.class)), withEqual(\"myKey\"), withArgThat(is(\"a,23\")), anyString, anyString);\n```\n\nor also if I write\n\n```\nmessageFactory.getMessage(SEVERITY_ERROR, \"myKey\", \"a,23\", \"foo\", \"bar\");\n```\n\nThe problem as far as I have seen through debugging JMockit code is, that no call to `mockit.internal.expectations.transformation.ActiveInvocations#moveArgMatcher` is generated during instrumentation, because of the matcher being \"hidden\" inside the `Object[]`.\n\nIf no matchers are present at all like in my last example, `mockit.internal.expectations.invocation.ArgumentValuesAndMatchersWithVarargs#isMatch` just compares all values literally with the `LenientEqualityMatcher`, but if there is at least one matcher and it is in the var-args range, then the `matchers` array in `ArgumentValuesAndMatchersWithVarargs` cannot be used as is.\n\nTaken my first example `messageFactory.getMessage(SEVERITY_ERROR, \"myKey\", \"a,23\", anyString, anyString);`, the `matchers` array would have the two `anyString` matchers at indices `0` and `1` instead of `3` and `4` as would be necessary for the current matching algorithm.\n\nSo I guess you either have to somehow make the `moveArgMatcher` calls get generated correctly for varargs method calls, or change the matching algorithm, or maybe transform non-special arguments to calls to `withEquals()` in the `InvocationBlockModifier`, like `any*` that are transformed to the respective method calls.\n"},"comment":{"url":"https://api.github.com/repos/jmockit/jmockit1/issues/comments/300784605","html_url":"https://github.com/jmockit/jmockit1/issues/292#issuecomment-300784605","issue_url":"https://api.github.com/repos/jmockit/jmockit1/issues/292","id":300784605,"user":{"login":"westonlast","id":9781580,"avatar_url":"https://avatars0.githubusercontent.com/u/9781580?v=3","gravatar_id":"","url":"https://api.github.com/users/westonlast","html_url":"https://github.com/westonlast","followers_url":"https://api.github.com/users/westonlast/followers","following_url":"https://api.github.com/users/westonlast/following{/other_user}","gists_url":"https://api.github.com/users/westonlast/gists{/gist_id}","starred_url":"https://api.github.com/users/westonlast/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/westonlast/subscriptions","organizations_url":"https://api.github.com/users/westonlast/orgs","repos_url":"https://api.github.com/users/westonlast/repos","events_url":"https://api.github.com/users/westonlast/events{/privacy}","received_events_url":"https://api.github.com/users/westonlast/received_events","type":"User","site_admin":false},"created_at":"2017-05-11T13:11:53Z","updated_at":"2017-05-11T13:11:53Z","body":"JMockit is extremely narrow-minded in what it considers correct and incorrect behavior, as evidenced by the countless issues that are knee-jerk-ed-ly closed.  For example, here's a simple one: https://github.com/jmockit/jmockit1/issues/417\r\n\r\nDon't expect logic from JMockit's oversold behavior, even after you've studied the documentation.  All you get is a skewed, illogical \"system\" of values.  Hyper tunnel vision."}}
{"actor":{"display_login":"westonlast"}}