<div dir="ltr">I can't tell exactly how many native usages there are, because not everything we potentially need to integrate with I'm aware of. However, I still have a decent idea on what I can reasonably expect, and my assessment tells me that there would be at least 2 (though one of them is split into many parts, but probably could be merged together, but that is something I would need to do most likely knowing its maintainers), and maybe 3, I can't really see more. Though I have to admit that I have been surprised in this regard that some libraries are using native for nonsensical reasons. Anyway, the main issue is political. If I push other people for modularization, then I will have to battle a lot where every extra reason just makes it more likely that I can't push through with modules (especially if it can be argued that - in theory - you can never be sure that your otherwise perfect (lol) application will not break under rare circumstances).<br><div><br></div><div>I have no problem building the JDK at home and I do have experience with its codebase (I did implement string interpolation for myself in it before templated strings were proposed to play with the code), but I can't do that on these internal projects.</div><div><br></div><div>And yes, probably properly structuring the code (which in part is legacy) is more effort than messing around with flags, but given my experience how arguments go, this will be just put into an additional independent issue category giving it a lot more weight, and if it ever breaks something for someone, I'm 100% that I will be hated for it, and I'm not a JDK developer to be so used to be hated on :)</div><div><br></div><div>As for additional module benefits: I am anxiously waiting for something that would move the world towards being modular, because so far modules are barely used (even for new projects). One thing the JDK could improve in this area is if it provided benefits for big libraries, because currently it offers very little, since a library (who has no control over its users) cannot have any trust in "exports" at all (and it must expect to be on the CP in general), even though libraries would greatly benefit from "exports". It would be nice, if the library could choose to mark itself as requiring to be used as a module even if put into the classpath (in which case it would be moved out from the unnamed module). Then maybe large libraries would start to take it more seriously which could even give a push to better tooling support (at least to avoid duplicating redundant information between the build and module-info).</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Ron Pressler <<a href="mailto:ron.pressler@oracle.com">ron.pressler@oracle.com</a>> ezt írta (időpont: 2023. szept. 4., H, 19:15):<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
<br>
> On 4 Sep 2023, at 17:07, Attila Kelemen <<a href="mailto:attila.kelemen85@gmail.com" target="_blank">attila.kelemen85@gmail.com</a>> wrote:<br>
> <br>
> So, the problem is that these people are unlikely to be very keen to modularize their app in the first place, and giving them an extra thing to point at (and people are very quick to find excuses), and my experience is that such an excuse potential will make my goal of convincing people a *lot* more difficult.<br>
<br>
Let’s make this more concrete, then. How many JNI libraries are used by the application? (We may be able to offer a source repo soon with the change that you can try, if you don’t mind building the JDK, and test the experience).<br>
<br>
The benefits from modules, most of which — maintainability and the possibility for robust security — stem from the integrity offered by strong encapsulation, are very powerful, but I admit they’re not easy for many to see. While writing a new modularised application is quite easy, modularising an existing large codebase is often not an easy task at all. Before the application can be modularised, its architecture has to be made modular — i.e. it must not make use of split packages and it must not have circular dependencies —and many codebases aren’t (the JDK wasn’t). The work required can easily dwarf the JNI flag to the point of making it insignificant. In such situations, maybe the codebase reaches a point where people realise they cannot easily move forward without modules (as the JDK had realised) or people understand the benefits they gain, which, admittedly, is not always easy because the benefits all involve future evolution or unknown vulnerabilities. But in other situations, modularising a large, existing, codebase may or may not be worth it. When you write new code, we suggest that you might as well modularise (even if you don’t understand the benefits) because it costs very little, and you may thank yourself for doing that later. Similarly, if you have a straightforward library, as that’s not hard, and will make life easier for you and your future users. But we’re not telling people that they should work to modularise all of their old applications, certainly not if they’re not happy to do it. The feature is there for new code and for those who really want it; in the future modularised applications may even enjoy other benefits. Modularising the JDK has helped the Java ecosystem a lot, but for old, large, complex applications your mileage may vary. In other words, we can’t and don’t tell people that the work required to modularised a large old application is always worth it.<br>
<br>
— Ron<br>
<br>
<br>
</blockquote></div>