Community
Participate
Working Groups
ecj doesn't yet support these class file attributes - ModulePackages - ModuleMainClass The former needs a full scan of the module. The latter requires additional input / user selection. => Should both be added (only) when exporting as a modular jar file? That would be bug 498983 in JDT/UI Let's use this bug for providing API to generate module-info.class with that additional info provided by the caller.
When can we expect this feature?
Well, generating one or two more attributes shouldn't be difficult. I'm just not sure about the best protocol for this. From a quick scan it looks like this would be consumed in or around org.eclipse.jdt.ui.jarpackager.JarWriter3 ? E.g., addFile(IFile resource, IPath path) could intercept the file "module-info.class", ask JDT/Core to recompile with additional properties, where JDT/Core could answer the byte[] that the packager can insert into the JarOutputStream. Or, the jar packager could trigger compilation with properties up-front, maybe, initially we still have the source file module-info.java? Would be more convenient for JDT/Core. JarFileExportOperation.exportJavaElement(IProgressMonitor, IJavaElement) still knows about JavaElements, which would facilitate interfacing with JDT/Core. Would s.t. like this be OK: byte[] JavaCore.compileWithAttributes(IModuleDescription module, Map<String,String> classFileAttributes) ? Should we be more specific about the attribute names? Should the API accept source & binary modules? (In the binary cause it would be Core's responsibility to map back to the source for recompilation). I'm pretty sure we will not store the modified .class on disk, because we don't want to interfere with the builder etc. Perhaps, JarFileExportOperation does the communication with JDT/Core and prepares a replacement map, that can be passed into JarWriter3?
FWIW, adding these attributes after the fact and with no support from the JDK has been discussed recently on jigsaw-dev: http://mail.openjdk.java.net/pipermail/jigsaw-dev/2017-August/013099.html - not that it would help us, though.
(In reply to Stephan Herrmann from comment #2) > Well, generating one or two more attributes shouldn't be difficult. I'm just > not sure about the best protocol for this. > I will check and get back on this.
API looks ok. byte[] JavaCore.compileWithAttributes(IModuleDescription module, Map<String,String> classFileAttributes) Just to confirm, so the Map classFileAttributes will expect the attribute name ModulePackages and ModuleMainClass as keys and values as null? ? >Should we be more specific about the attribute names? If JDT Core wants to keep the API generic, JDT UI can pass the attribute name. Are you foreseeing other scenarios ? >Should the API accept source & binary modules? (In the binary cause it would be Core's responsibility to map back to the source for recompilation). I am not sure about binary requirement, are you aware any scenario which requires it. >I'm pretty sure we will not store the modified .class on disk, because we don't >want to interfere with the builder etc. Yes, makes sense. >Perhaps, JarFileExportOperation does the communication with JDT/Core and >prepares a replacement map, that can be passed into JarWriter3? Looks doable.
(In reply to Sarika Sinha from comment #5) > API looks ok. > byte[] JavaCore.compileWithAttributes(IModuleDescription module, > Map<String,String> classFileAttributes) > > Just to confirm, so the Map classFileAttributes will expect the attribute > name ModulePackages and ModuleMainClass as keys and values as null? I didn't think about the values, but now that you are asking: - ModulePackages: yes, passing value = null signals to Core: please compute - ModuleMainClass: I'd expect UI to pass this from the wizard (Core doesn't know) Put differently, if we receive name x value, then we simply put it into the class file without thinking twice. If the name is ModulePackages and the value is null, we will compute the packages. To communicate that Core has special knowledge about ModulePackages I will provide a constant for this, for use by clients. > >Should we be more specific about the attribute names? > If JDT Core wants to keep the API generic, JDT UI can pass the attribute > name. Are you foreseeing other scenarios ? I was thinking of future addition of more attributes, as the language evolves. Generic API avoids the necessity to add new API each time. > >Should the API accept source & binary modules? (In the binary cause it would be Core's responsibility to map back to the source for recompilation). > I am not sure about binary requirement, are you aware any scenario which > requires it. Think of a project from binary class folders, which you don't have the sources of (e.g., extracted from a jar), which now you want to repackage just to add the new attributes. Thinking more about it, if you already have module-info.class it's not very likely s.o. still wants to add attributes to it. => Let's not worry about this right now.
Sounds good!!
Now that we have an agreement, I plan to work on this over the weekend.
See also http://openjdk.java.net/projects/jigsaw/spec/issues/#AddExportsInManifest http://openjdk.java.net/projects/jigsaw/spec/issues/#StandardModuleAttributes
New Gerrit change created: https://git.eclipse.org/r/104801
(In reply to Eclipse Genie from comment #10) > New Gerrit change created: https://git.eclipse.org/r/104801 @Sarika, this should do the trick. There are minor modifications in the protocol, please see the javadoc of the new method in JavaCore. Let me know if anything is unclear, or doesn't work for you. For ModuleMainClass I also provided an alternative mechanism: this can now be specified using a classpath attribute on the source folder holding module-info.java. :) In this case every compilation of this module will create the classfile attribute. I thought of this as the cheapest option for making this parameter persistent in the project. Still, the new API can specify the main class, which would overrule the classpath attribute, if set.
Gerrit change https://git.eclipse.org/r/104801 was merged to [BETA_JAVA9]. Commit: http://git.eclipse.org/c/jdt/eclipse.jdt.core.git/commit/?id=6f90d44d90811c036e9a1d93a1138bbc37f8d26b
(In reply to Eclipse Genie from comment #12) > Gerrit change https://git.eclipse.org/r/104801 was merged to [BETA_JAVA9]. > Commit: > http://git.eclipse.org/c/jdt/eclipse.jdt.core.git/commit/?id=6f90d44d90811c036e9a1d93a1138bbc37f8d26b > Released for BETA_JAVA9
