-
Notifications
You must be signed in to change notification settings - Fork 2.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
I would like to strictly name the module #451
Comments
https://github.com/BGehrels/JSON-java holds the packaging for maven releases. Please peruse there and offer any merge requests at that location. |
Also, strictly speaking, this project must support back to Java6 still until @stleary mentions otherwise. So any module-info changes must not cause an issue with java6 runtimes. |
It will still support JDK 6 so long as
This will produce the 1.6 output with the module-info correctly placed, Thanks for considering it!, Hope you pull it in! |
You can view the build log and the output here (Guest user is enabled) Thanks! |
Will existing developers have to change their build process to use the new build? |
Hi, I have created a fork that adds modules, but I build it using gradle. I could contribute the module-info.java files. I would be happy to help to get module-info into trunk. [UPDATE] Seems I did not yet push my changes to my fork. I will look into this. |
I see you've moved the classes to a higher version of Java, Thanks! To be honest, I do prefer my method, it keeps the libraries perfectly in tact without any code changes of any kind, or bumping of JDK's. If worst comes to worst, on all these projects that require the push forward into JPMS, I'll be placing them onto the com.jwebmp maven group, and utilizing all the updates from there :) P.S. Gradle is the android native build tool. You shouldn't actually be using it for Java. While Maven Gradle Ivy and Grunt can all build Java, and they can all build android native, each was designed and built specifically with a purpose in mind. You should be using the build tool built for Java to enable advanced functions that are required post JDK 7 like annotation processor paths, annotation arguments, processing updates and manipulation, pretty much anything in the "advanced" category of Java building, and etc |
@GedMarc: Sorry, but I think I only understand half of what you try to say. I think adding the module-info.class files will probably break things for some developpers. That's also the reason why I did not try to contribute back. I have to research because it's been some time, but I remember these issues: While module-info.class files should be ignored when used with older Java versions, at least some tools choked on this, IIRC these were among others
Another solution would be Multi-release Jar files, but with more or less the same issues. If you don't want to abandon Java 6 compatibility (a version that has been unsupported by Oracle for several years now), you should probably not force your users to use the newest versions of these softwares (I don't even know if all problems have been solved in the meantime). So, at least some developpers will have to change their build process or dependencies. And I also doubt all those new versions will still be compatible with Java 6. IMHO it would be great to have a truly modularized version in trunk, but I think you have to make a compromise. You cannot have it and still be compatible with JDK 6 and the tools used to maintain Java 6 based software. Concerning your comment about Gradle: Maven is not the build tool for Java. If there's a tool that deserves that name, it should still be Ant. Just because Gradle has been adopted as Android's standard buid tool doesn't mean it's not suitable for Java. Following your rationale, you shouldn't even use Java for anything other than Android development, right? But I think this really doesn't belong here, and if you want to discuss build tools further, you can rather contact me directly. Gradle was simply the tool I chose because I could reach my goal faster. |
@xzel23 The PR that @GedMarc provided only adds the module.info file in the JAR during the packaging process. It does not add it to this project. See his PR at #451 (comment) |
Also, as a side note, please leave build tool discussions out of this project. They are not relevant. |
@johnjaylward But there's a packaged Jar at mavencentral, linked from the main github page. Won't it add the module-info once this is merged? I think it should, but I also think this could break builds. |
@GedMarc Maybe you could add to the PR description that with automatic modules, you cannot use JDK 9+ |
@xzel23 The idea behind this is that the original packaging/class files are not manipulated at all, and the way that the JVM works, the module-info class file will never be hit in any JVM less than 9 (the hyphen makes the class name invalid) so no incompatibility is ever brought in. Moditect itself actually constructs the class file byte-for-byte and the file never goes through any "compilation", so when the class gets added into the final package, it can contain invalid references that the compiler would normally throw out. This means that all builds using Moditect are unaffected, and are guaranteed to still execute properly, even with the module-info.class file in the JAR regardless of the project version (down to 1.5, 1.4 no compatible but that's a JRE 8 thing) I did not know about JLink restrictions! We always learning lol, I'll need to run some tests, but from what I understand, if you open your base module, JLink will still work with filename/automaticmodule named modules, I haven't tried/tested this, but logically it should work. I may actually use that as a further base for Hibernate and Guice implementations after I've verified that it is indeed the case. You mentioned JUnit 4, but you can't use that for JPMS, please use Jupiter (5) for proper TCK in JPMS, and don't use any junit 4 runners, keep it strictly jupiter. I have had great success going this route, and awful experiences in junit 4 :) The goal as usual in Java, is not require any changes or dependencies code wise for JVM migration, and this solution does solve that properly. |
I went multi-release Jars for my own personals, but that's because I actually want JRE11 byte-code, but it isn't necessary at all, you can keep your packages in tact with no changes other than plumping a module-info into the package post-build ;) Quote : IMHO it would be great to have a truly modularized version in trunk, but I think you have to make a compromise. You cannot have it and still be compatible with JDK 6 and the tools used to maintain Java 6 based software. ^^ This is completely incorrect and none of the above is true in any regard. |
Can you elaborate? Have you tested? All tools? Because I definitely had problems as I have written above. I agree that there should not be any problems, but for example some tools simply cannot handle the non-standard file name containing a dash. That bug has been fixed in the meantime, but the fixed version (3.1.x) is incompatible with Java 6. And I had problems with other tools as well. Maybe there are workarounds, but how can you say it's not true? In my Jar, I only compiled the module-info with JDK 9, the remainder with JDK 8 compatibility (I know, yours is JDK 6). So the resulting Jar should be more or less the same as sneaking in a JDK-9 compiled module-info after the build. I think this should be looked into before releasing a modularized Jar. Can you provide me with a binary Jar so that I can try it against the tools that I had problems with? |
Are you able to just stick the module-info file into a version folder in the jar? Does it have to be root-level? |
answered my own questions: https://openjdk.java.net/jeps/238#Modular-multi-release-JAR-files looks like module-info need to exist both at the top level and in any version folders. Would be nice if you can test it out with it missing at the root level and see if it works in a couple JVMs |
@johnjaylward No, it doesn't have to exist at the top level. from your link:
I have also tested it, and it worked for me. However, IIRC there were problems with other tools. Stephen Colebourne posted a nice writeup on problems with JPMS on his blog some time ago. I will try to compile a list with the relevant PRs here:
I don't do Android development at the moment, so I cannot check on that platform. But for Plain Java, I could re-check if it works with the "tweaked" Jars. |
Ah, I've always like Stephens work. Joda was a go-to for me for years. And I agree with that blog 100%. My company is on Java8 and has almost no plans to move to Java11 because so far in testing with java 9&10 it has been a major undertaking with lots of incompatibilities. It will probably be another year or 2 before we fully make the switch. As for the module-info at root, I must have been reading too quick, I could have sworn it said the exact opposite. Thanks for testing it out. |
@xzel23 It took me a good year before I actually got happy with JPMS, and it still really irritates me that things like the Jlink and those little thing I still don't know or haven't come across.. So i'm using Jupiter 5.2, Selenium 4.1, Google Guice 4.2.3-SNAPSHOT, BTM 2.2, Hibernate 5.3, Hazelcast 3.10.4 and honestly still trying to get a proper JPMS named JMS up and running, RabbitMQ looks to be the most promising. Running the base applications is simple, the automatic and unnamed modules are currently the biggest headache, but as an excersize the clean out the JDK library pool, it is definitely very effective. Downside mostly is the aged/dropped/finalized libraries (aopalliance, javax.inject, etc) have no organizers contactable anymore, and trying to update the maven repository is going to difficult. I think the biggest thing that I struggled with, which seems to be for you as well, is that JPMS is not backwards compatible, it just isn't, that's why there is a specific "classpath mode" to run the older programs. Trying to run builds with advanced functions becomes extremely difficult (try package lombok and the static metamodel together), and because everything is new, all the cool stuff you actually need the newer tools to use it (properly).
Good lord that was long, I am so sorry for destroying the thread xD |
@xzel23 You can grab the binary here https://jwebmp.com/teamcity/viewLog.html?buildId=202127&tab=artifacts&buildTypeId=ThirdPartyBuild_BuildOrgJson |
whoop whoop, JDK 6 finally EOL!!!! JDK 6 EOL = December 2018 |
@johnjaylward 9 and 10 were JPMS Alpha and Beta, and yes I agree were absolutely horrid ;) It looks like 6 and 7 are completely out next year, I'm not sure if you have 2 years to make the switch. JRE 8 looks to have an extended life span. |
Updated: |
Updated: |
I don't think we should drop jdk 1.6 support until the jvm no longer supports running it, |
Sorry, was not clear. Question has been updated, feel free to edit your answers or provide new ones. |
@stleary |
@stleary the PR earlier in this thread has links to a JAR file which was built using the changes @GedMarc made to allow for the module-info within a Java6 JAR. I think we should get a few people to test it on java6-8 JVMs and then make a decision. If the changes @GedMarc made work as-is across older JVMs, then I think we should plan on using it as a measure to support newer JVM features while maintaining our Java6 byte code. I'm not a fan of using multiple packages unless we actually add language/code features for the high versions of supported JVMs (like streams, lambda, Optional, etc). |
@GedMarc feel free to create a pull request to update the readme to offer users the option of downloading your alternate jar. It can appear at the top of the readme. |
Missed that, sorry. The changes should be made to a fork of @BGehrels repo, not the original. Or people can just get the pull request branch. No changes to how JSON-Java releases are packaged should be made at this time. If you don't want to update the readme, I guess people can learn about it from this issue. |
@johnjaylward: Being able to create a redistributable runtime that only contains what's needed for your application to run is a new feature that is enabled by providing strictly named modules. As an example, I have created a markdown-viewer application that is ready to run with 78 MB in size (application + |
Creating a second package (whatever we call it) may give a false impression that newer JVMs are implicitly supported. My main issue is that going forward, JVMs (9+) are not guaranteed to be backwards compatible. Granted we are not using features that are likely to be deprecated/removed and cause compatibility issues, but it's still a valid concern that library maintainers need to take into consideration. Using the approach from @GedMarc seems logical and a small footprint, but as I've stated multiple times, the resulting JAR needs to be tested against multiple JVMs. In JVMs 9+, it would also need to be tested on both the module path and the classpath (as noted in Stephen's blog linked earlier in this thread). It sounds like @stleary does not want to take on that maintenance task at this time. If that's the case and @GedMarc's PR will not be rolled into the main release branch, then going with the README change and linking to the PR branch is probably the best bet at the moment. |
Hmmm, I think I'm going to rather go to my fork and go the lint and rework for jre8, technically JDK6 died off 2 days ago and with 7 falling away in 6 months. Sadly I really do need a named module so I can't use this one anymore. |
Hmm, it's sad that @GedMarc closed this issue, because i consider the discussion highly valuable. I'm also highly irritated by the way motivated contibutor is bounced without even a simple "Thank you for the work you've invested and your efforts to keep our library up to date. We sadly can't merge it but highly appreciate your contribution and input to this discussion". The decision to stick to Java 6 was taken 3 years ago in #156 in order to support Android versions <4.4. While back then, ~50% of the android devices still used <4.4, it's just 3,5 % nowadays - and given the short live of mobile devices nowadays i guess it will be much less in 6 months from now. So maybe it's time to drop this requirement. Spring, for example, dropped support for java 6 and 7 with version 5 in september this year. I wouldn't go that far since Java 8 is not fully supported in Android < 7, which is nowadays still used by ~50 % of the devices. Maybe @snodnipper - who advocated for Java 6 support back then - can contribute a bit of expertise here? While i understand the argument that manually testing against Those benefits will be much easier to leverage if we have the pom, the tests and the code in one place. This raises the question: Which value do we get from splitting the unit tests and the code in two distinct repositories? Which value do we get from maintaing the maven central build in yet another seperate repository with a seperate maintainer? So maybe, instead of draining contributors of their motivation, we should see java 11 as a chance to renew the project and put it on stable, more maintainable feet? |
I agree. I think it's a little premature to close this issue yet. I think we can find a good resolution that will work. I know we have some restrictions on public API changes based on the hands-off from Douglas, but I think merging the test cases back into mainline and possibly Implementing some build tool integration are a great place to go forward. We should highly consider these things going forward. There are multiple times even recently that contributors have had trouble finding tests, or in this case the distribution POM. Consolidating the projects should simplify a lot, both new contributors and even old contributors like myself. |
I closed the PR and issue cause I need something working for the weekend :) I think it's pretty simple and straight forward, there's nothing funny going on, still JDK6 build nothing changed there at all, it's purely just a moditect + module-info in the build (the PR was on the right github repo I think) I've already punched through a large portion of the library so I can't re-open the PR, the group, build method, StringBuffer->StringBuilder, Lint'ing and etc have all already been changed. There's like 160 more lint's to get my branch to an acceptable level for JRE8 (for me) so not going to revert it. @johnjaylward The build and pom structure is a bit weird 👍 |
Would you like me to provide a PR? Thanks for reopening |
@GedMarc, Yes, please add a PR. |
Update please - Why is this not pulled in, Why is there no feedback |
@stleary I've commented on the linked PR, I'm no subject expert on modules, but the changes look like they shouldn't cause any issues with backwards compatibility to me. |
@stleary If you could also provide guidance on if we should do a new package release or not to get the named module support in (as opposed to the auto module naming we have currently), that would be great. I think a new release would be the best course myself just so we can get community feedback if there are any issues. |
@johnjaylward, agreed, I also commented, and thanks for doing the analysis. |
Whoop whoop, we are in 2020, what's going on with this issue? |
See end comments here with maven coordinates https://search.maven.org/artifact/com.guicedee.services/json Although the version is changing (with the encapsulating guicedee project) it is fully in-sync with source |
Comment added to PR 4 |
Please see comments in BGehrels#4. Looks like no further work is planned for this issue. |
Hi There,
I would like to update the pom and build to generate the module-info class file, and strictly name this module.
Currently as an automatic module, you cannot perform a lot of JPMS functions, such as requires transitive, or evade the maven central deploy warning for unnamed modules.
This is purely the raw code, could I get a zip of the build and send back a finished zip for perusal?
The text was updated successfully, but these errors were encountered: