> On 19 Dec 2024, at 14:54, Jochen Theodorou <blackd...@gmx.org> wrote: > > On 18.12.24 16:46, Ron Pressler wrote: > [...] >> The scenario you’ve described is one that effectively disables reliable >> configuration. That is what everything you’ve brought up is predicated on. I >> don’t doubt you have your reasons for not wanting reliable configuration, >> but that only raises the question, why do you want to use the reliable >> configuration feature only to disable reliable configuration? > > reliable configuration in the sense of the module system is not his > target. Wildfly had a module system since before Java had one. And "he" > is trying to emulate the old module system with the new Java system. One > reason to keep the old system surely is inertia. If this is a good idea > or not I don't know.
That’s perfectly okay, but a highly dynamic configuration that may fail at any point during runtime and cannot offer strong encapsulation has always been offered by Java, and is still on offer now. It’s just that those who do want reliable configuration (to reduce runtime errors) and/or strong encapsulation (for maintainability and security) have had no recourse for many years. Those people, for the first time, now have recourse through the modules feature. Whether it’s “good” or not depends on the project, but *if* these are the benefits you want, then modules are the features you can use to get them. > > Of course this is a simplified and potentially slightly wrong picture > about Wildfly. Still I dare to ask: What is now the right architecture > in a modern Java? > Every architecture is a tradeoff, and you may want strong encapsulation and reliable configuration, or you may want their opposite. The interesting question at this juncture is what if you want one and not the other, and, in particular, if you want strong encapsulation without reliable configuration. Modules are meant to offer both at once, and the question of whether the two should be separated is a good one. To know whether it’s worthwhile to separate the two, we must have more information, such as the actual performance cost of the feature as it currently is. As with every Java feature, the magic words that allow us to move forward are, “I’ve tried the feature in the most straightforwardly and here are the details of the problems I’ve encountered.” If these words are uttered, we’re open to any change. If they’re not, the JDK development process makes things more difficult to pursue. The relevant question (if you want to impact the development of the JDK) is, therefore, what is the *recommended* or straightforward way of using this particular feature, namely modules? For dynamic containers it is this: load every unit, i.e. every "user application” as a single module layer. Every performance or flexibility problem encountered when doing that opens the door to further change and accommodation. Maybe the recommended way works well and maybe it doesn't. But before we can take things further, we must know what issues are encountered, in practice rather than in theory, when used in this way. Any other reports amount to, "I wish there were a feature to allow me to do X." Unlike reports of a problem encountered using a feature in the recommended way, such requests are deprioritised. They can still be considered — provided that what you aim to gain is sufficienty motivated (“I want neither reliable configuration nor strong encapsulation” is a negative rather than a positive motivation), but with a lower priority. I believe there may be real problems with the recommended way for using modules, and that’s why I wish we had the information that would allow us to continue addressing them in the short term. But without that information, the JDK process does not allow us to assign it a high priority. It becomes a “future feature suggestion” rather than a fix for a problem encountered when using a feature as intended. The JDK development procedure deprioritises the first. To get something delivered in the JDK in the short term, the best approach is the former rather than the latter. It is because I think we could actually do something to help that I wish we had the information we need to allow us to move forward with the high-priority process. — Ron
