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/ >>>>
