Replies: 2 comments
-
I don't understand the Java module system and I don't like it at all because so far it created only trouble without any practical benefit. I will dodge it as long as possible. I have accepted your PR simply because it does not disturb and looked reasonable. a) someone used the module system, then set the information as provided |
Beta Was this translation helpful? Give feedback.
-
I just thought the module name should be called out if anyone is using the default name. You might want to stick with the old name or use the preferred one. I don't think it causes any real issues either, but I just wanted another opinion. With respect to using the module system, that's a probably different discussion entirely, and there's no strong reason to use it. I'm not advocating that jsqlparser uses it any time soon. However, the primary benefit of modules is that it separates internal APIs from exported APIs. A large project is typcially broken up into several packages, and dependencies between these packages must be defined as public, even if they're only to be used internally. I've been burned in the past when someone depended on internal code that I modified because I didn't expect anyone to use it in the first place. Modules provides a much stronger contract regarding what is truly part of the public API and what is not. |
Beta Was this translation helpful? Give feedback.
-
A few days ago I created a PR which set up an automatic module name of "net.sf.jsqlparser", which should be called out in specifically in the next release. The reason being that some projects might already be using an automatic module name which is derived from the jar file name, and it's not considered to be stable. Based on the current jar name, the module name is just "jsqlparser". When a project which is using this name upgrades to the new version, the module-info.java file will need to be updated too.
I searched GitHub and found only four module-info.java files which referenced jsqlparser, and only one of those appears to be in an active project. It depends on an old version of jsqlparser (3.2), and so upgrading will cause more issues than just the module-info file.
I expect that there are other projects out there (closed source) which might be affected by the change, so it should be mentioned in the release notes. One option is to make the automatic module name be "jsqlparser" for compatibility, but a short name like that is considered bad form. At some point, the project should fully switch to the module system, and so defining a clean name sooner rather than later seems like the best option.
What do you think?
Beta Was this translation helpful? Give feedback.
All reactions