+1 to use unique mocking framework as possible.

regards,

François
[email protected]

Le 11/05/2020 à 11:29, Benjamin Marwell a écrit :
> PowerMock has the goal to make final classes mockable (which will stop
> working in future java versions and is an antipattern).
> This means they have different goals and cannot be userd interchangeably.
>
> But +1 to remove PowerMock at this point and use EasyMock as long as
> it serves us well.
>
> Am Mo., 11. Mai 2020 um 11:14 Uhr schrieb Jean-Baptiste Onofre
> <[email protected]>:
>> Something helpful would be to use an unique mocking framework. So maybe 
>> removing powermock to use easymock only.
>>
>> Thoughts ?
>>
>> Regards
>> JB
>>
>>> Le 11 mai 2020 à 11:12, Benjamin Marwell <[email protected]> a écrit :
>>>
>>> As EasyMock is used throughout the code, I changed my mind about this
>>> topic and would like to keep it.
>>> I see no imminent reason to change existing (test) code.
>>> However, I am open whether to use Mockito for new tests or not, see
>>> maven link and rationale from the first e-mail.
>>>
>>> At the moment, there is only one powermock test left as far as I can
>>> tell: 
>>> https://github.com/apache/shiro/search?q=powermock&unscoped_q=powermock
>>> One test had to be rewritten because of a illegal access issue on jdk11 and 
>>> 14.
>>>
>>> Because of this, I would like to remove PowerMock until we need it again.
>>>
>>>
>>> Am Fr., 8. Mai 2020 um 19:01 Uhr schrieb Benjamin Marwell 
>>> <[email protected]>:
>>>> Using PowerMock will result in IllegalReflectiveAccess violations. [1]
>>>> That is the whole reason the Maven team will stop using PowerMock in
>>>> the future, design principles aside.
>>>> With more recent java versions, you just cannot Mock static or final
>>>> methods/classes anymore. PowerMock *will* cease working at some point.
>>>> The flag --illegal-access=warn will not be available forever.
>>>> Mockito will cover 100% of the rest afaik.
>>>>
>>>>> but we can start producing module-info's
>>>> +1
>>>>
>>>>> This makes releases depend on Java 11 (or similar) but that isn't a bad 
>>>>> thing)
>>>> Only the release build will need a JDK9+, but I am fine with this.
>>>> It doesn't change the runtime requirements, java 8 will just ignore
>>>> any module-info.class files in the root.
>>>>
>>>>> Worst case we should add a `Automatic-Module-Name` to the manifest (if we 
>>>>> haven't already)
>>>> +1, this is a good fallback to "reserve" the name.
>>>>
>>>>
>>>> [1] https://github.com/powermock/powermock/issues/969
>>>>
>>>> Am Fr., 8. Mai 2020 um 16:33 Uhr schrieb Brian Demers 
>>>> <[email protected]>:
>>>>> I'm +0.9 on Mockito, I'd pick it over EasyMock any time and I've ported a
>>>>> couple of projects from EasyMock to Mockito in the past.
>>>>> We might still end up with PowerMockito for some things (so I'm not sure 
>>>>> it
>>>>> completely fixes resolves the issues without some additional refactoring)
>>>>>
>>>>> +1 for sticking with Java 8, but we can start producing module-info's
>>>>> (where the source is compiled to target 8 and the module-info to 9) using
>>>>> this technique [1]
>>>>> This makes releases depend on Java 11 (or similar) but that isn't a bad
>>>>> thing)
>>>>> Worst case we should add a `Automatic-Module-Name` to the manifest (if we
>>>>> haven't already)
>>>>>
>>>>> For the OSGi folks on the list, is there any tooling that can generate 
>>>>> OSGi
>>>>> and JPMS metadata from the same source?
>>>>>
>>>>> [1]
>>>>> https://maven.apache.org/plugins/maven-compiler-plugin/examples/module-info.html
>>>>>
>>>>> On Fri, May 8, 2020 at 8:50 AM Francois Papon 
>>>>> <[email protected]>
>>>>> wrote:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> I have no objection to move to Mockito.
>>>>>>
>>>>>> I created jdk14 jobs on Jenkins, however for the openJ9 build, we don't
>>>>>> have them on the Apache Jenkins workspace. May be we could use Github
>>>>>> actions or Travis for this.
>>>>>>
>>>>>> We are a lot of users that using Java 8 so I'm not sure that switching
>>>>>> to Java 11 baseline is a good thing.
>>>>>>
>>>>>> A lot of company are still using Java 8 and are not planning to upgrade
>>>>>> soon.
>>>>>>
>>>>>> regards,
>>>>>>
>>>>>> François
>>>>>> [email protected]
>>>>>>
>>>>>> Le 08/05/2020 à 08:39, Benjamin Marwell a écrit :
>>>>>>> Hello everyone,
>>>>>>>
>>>>>>> I would like to discuss moving away from mocking frameworks like
>>>>>>> PowerMock, EasyMock etc., replacing them with Mockito where feasible.
>>>>>>> [1] [2]
>>>>>>>
>>>>>>> Rationale:
>>>>>>> The Apache Maven project is going to do the same switch, because
>>>>>>> Mockito seems to have superior support for the module system
>>>>>>> introduced in Java 9. It was also the first to have a
>>>>>>> module-compatible release.
>>>>>>> PowerMock cannot be used anymore because of illegal reflection access.
>>>>>>> In Java 9 and above, opening final methods or classes is not allowed
>>>>>>> anymore. Instead, better class design is needed anyway. Some tests are
>>>>>>> already failing on JDK11, like the EnvironmentLoaderServiceTest when
>>>>>>> used in conjunction with JDK11 (I use openj9 11.0-6 from
>>>>>>> adoptopenjdk.net), However, this does not seem to be the case in our
>>>>>>> Jenkins with a hotspot JVM. [3]
>>>>>>>
>>>>>>> Benefits:
>>>>>>> If new tests were written in Mockito only, it is easier to navigate the
>>>>>> code.
>>>>>>> Replacing PowerMock with Mockito will have the benefit of forced good
>>>>>>> class design and not breaking the tests in future JDK releases.
>>>>>>>
>>>>>>> Additional thoughts:
>>>>>>> I would like to add a build job with an openj9 JDK (both Java 8 and 11).
>>>>>>>
>>>>>>> Non-Goals:
>>>>>>> Switching the baseline JDK requirement to 9 or even 11.
>>>>>>> Rewrite every test.
>>>>>>>
>>>>>>> I am looking forward to hearing your opinions on this topic!
>>>>>>>
>>>>>>> Ben
>>>>>>>
>>>>>>> [1] https://github.com/apache/maven-site/pull/158/files
>>>>>>> [2]
>>>>>> https://lists.apache.org/thread.html/r5fd75d1a769d1f8b25f1342789d253cda362d675a9825f6d4bf664f5%40%3Cdev.maven.apache.org%3E
>>>>>>> [3]
>>>>>> https://builds.apache.org/view/S-Z/view/Shiro/job/Shiro-master-jdk11/
>>>>>>

Reply via email to