On Java modules and strong encapsulation in JUnit

[jgarci40]

Hi JUnit5 team. I know this is an unusual place to ask this question, but it seems to be about as good as any other place I can find. My name is Joshua (Josh) Garcia (https://jgarcia.ics.uci.edu/), and I am an assistant professor in software engineering at the University of California, Irvine. My students and I have spent a significant amount of time studying JUnit5 lately and JEPs related to Java strong encapsulation, JPMS modules, FFMI, and Java integrity by default. Our research goal is to study the design, decay, and repair/prevention of software decay in JPMS modules. As a result, we've been producing preliminary results, and coming up with ideas regarding our research goal based on JUnit, especially JUnit5. To help JUnit and the Java community with the aforementioned Java platform issues, we're looking to see if anyone on the JUnit5 team may be willing to discuss collaboration on those issues, with a particular focus on JUnit. It seems @sormuras has a particular interest in JPMS modules, but my research team and I would be excited to discuss with anyone else on the team to help guide our research so that it helps the JUnit and Java communities. We are further working hard to seek funding opportunities to support our research, and we think it would be great to have JUnit developers as collaborators. Thank you very much for your time and consideration!

[sormuras]

Hi Josh, I moved this thread to the discussion board - as it is not a bug or feature request.

Let's start by using this discussion board to (let me) find out what "decay, and repair/prevention of software decay" is.

Cheers,
Christian

PS: https://twitter.com/mreinhold/status/994669659029999616

Please stop calling it “JPMS,” which sounds like an unpleasant medical condition. It’s just “the Java module system.”

[jgarci40]

Thanks for responding and moving my post to the right place, @sormuras! By decay, I really mean the software architecture terms architectural drift and erosion, where critical design decisions are added to the system beyond those originally intended, some of which violate those original design decisions. To put it more crudely, the kinds of decay we're interested in are the ones driving Java toward strong encapsulation and the Java module system (I'll resist the urge to call it JPMS 😊), such as undoing its ball-of-mud architecture. Beyond that, decay for us includes significant issues involving maintainability and security, like the ones described in the OpenJDK JEPs.

As for repair, we'd like to help automate the support of transforming Java projects so that they are well-modularized using the Java module system (e.g., they follow good software design principles) and use safer, supported, and powerful APIs, like MethodHandles.Lookup and FFMI, rather than the dangerous, unsupported, and powerful APIs developers have become probably too used to using like sun.misc.Unsafe. Regarding prevention, we have prediction models that can predict decay (e.g., defects, architectural smells, and poor coupling and cohesion), before it happens, and we'd like to use them to prevent that decay from happening. We think Java modules are an opportunity to study decay at a scale and with high-level abstractions that have long been recommended by software experts and researchers, but have not had much traction until they were encoded in a popular programming language, like Java.

More specifically, my research group and I are looking to build collaborations with open-source developers of widely-used Java projects using the Java module system, especially using explicit modules, to help us study how to best design them and maintain them. We'll be sending proposals to the US National Science Foundation (NSF) to attempt to obtain the needed funding to conduct the research, and having Java developers of widely-used systems support that effort, e.g., by trying out our detection, repair, and prevention tools, and even guiding us as to ensure we are detecting the right kinds of decay and automatically fixing in ways that really help developers like you.

If you're still interested, my research group and I have drafted a version of the proposal, and we'd be happy to share it (e.g., over email), and we're open to suggestions on how to improve or even redirect the work for the benefit of the Java and JUnit communities.

Thanks for reading this long post!

[jgarci40]

One more point I forgot to include is that, in the proposal, you'd find that we discussed JUnit5 and used it for preliminary results often. I think you and the JUnit5 team may find the results particularly interesting. @sormuras

[nipafx]

I'm no member of the JUnit 5 team, but I do co-maintain JUnit Pioneer, a JUnit 5/Jupiter extension pack, and am very interested in modules, so I'm very curios to see where this research goes and maybe support it if I can. 😃

[jgarci40]

Hi @nipafx . It's exciting to have you chime in. We've read your IEEE Software interview on Java modules, and we've been studying your book on them, which has inspired our research ideas and direction. My response to @sormuras , hopefully, clarifies what we're aiming for. I'd be happy to share the detailed funding proposal we've created with you (e.g., over email). You'll find that we've referenced your book a good number of times in it.

[jgarci40]

Hi @sormuras and @nipafx. Have you had a chance to consider this further? I'd like to ensure that the Java ecosystem can have improved maintenance and security, and I think our proposed project would help with that substantially. Thank you again for your time and consideration!

Sincerely,
Josh