0

In my JUnit tests, I need to override some public method behavior from class A (module M1). For that, I am doing something similar to that (in JUnit module M2):

package com.acme;

public class B extends A{
   @Override
   public String methodToOverride(){
       return "TestDataHere";
   }
}

How Java 9 JPMS recommended to override some package in 3rd party module or your module? How to properly configure to JPMS to use modules M1 and M2 with the same package names?

Konstantin Pupkov
  • 93
  • 5
  • When `A` and `B` are in different modules, they should be in different packages. That’s it. `B` doesn’t need to be in `A`’s package to override a `public` method. – Holger Sep 28 '18 at 16:44
  • @Holger I think it's "must" and not "should", otherwise it would not work, an exception would be thrown – Eugene Sep 28 '18 at 19:04
  • Are you trying to the path the content of one module with another using the same package name? How exactly are you running the tests? Can you share the module-info for these modules as well please? – Naman Sep 29 '18 at 02:55
  • 2
    If you want A and B to be in the same run-time package then they need to be in the same module, meaning you'll test with M1 patched to include com.acme.B. – Alan Bateman Sep 29 '18 at 06:41
  • @Holger - that is existing code. Your proposal is to change packages for thousand lines of code? I assumed, Java should be able to handle that somehow without package renaming. I agree, some action is required, but renaming is a bad solution, I believe. I separated out the code to a different module [modulename="patch"], compile it with "requires M1" and run test for module M1 with "--patch-module" "M1=patch.jar". Looks like working. – Konstantin Pupkov Sep 29 '18 at 17:18
  • @KonstantinPupkov Where is the problem? The production code should never reference the unit tests, so moving the unit tests into different package should not affect it at all. And any reasonable IDE can change the package and adapt all references within seconds. Besides that, I'm just messenger. Java modules do not support splitting packages between modules. What you did, is creating only one module split between multiple jar files. You can do it and fight the module system for the rest of your life or just tell your IDE to change the package once and be done. – Holger Sep 30 '18 at 10:26
  • @Holger I see your point. I should try your solution as well. I'll spend some time to try a simple rename package in JUnit source code. However, I doubt for new a package I need to "add-exports" to my production package, right? Sounds like "rename package in tests + '--add-exports'" will end up with the same result as "keep same package name, but new a module +'--patch-package'", right? – Konstantin Pupkov Oct 01 '18 at 22:14
  • 1
    I suggest that detailed comments be converted to a full-fledged answer to help the readers. It seems that few respondents are able to answer about such new features. Even so a little extra effort to formulate an answer will surely help. – Mohan Radhakrishnan Nov 01 '18 at 09:15
  • The solution proposed by Holger works better. Few reasons: no need to have an extra module (also no need to use --patch-module). Disadvantage: all packages/subpackages which is part of JUnit, but not part of business code will be invisible. I took me some time to figure out why on runtime I am getting error class not found. After moving all classes from mismatched packages to align with business code packages all JUnits passed. – Konstantin Pupkov Nov 08 '18 at 13:20

0 Answers0