On Thu, 30 Nov 2017 09:29:31 +0100 Jan Lahoda <lah...@gmail.com> wrote: > > This is a little bit surprising to me. AFAIK in JDK 8 it worked like > this: for: > $ javac -processorpath <jars> <sources>
Interesting, maybe that is the solution. Presently just using classpath and passing sources. I am setting the --source-path now. https://github.com/Obsidian-StudiosInc/os-xtoo/blob/master/eclass/java-netbeans.eclass#L249 I had to have that for it to find resources for the static annotation processor as I mentioned in another post. I did not think about it finding processors. But I guess I need to set the entire classpath to the source path or something. I am pretty sure I tried removing the -processor and it didn't find them. I some what have current proof. As I just packaged the org.netbeans.html stuff, or some. net-java-html packages. One of them had a Model Annnotation processor. It did not find it on the classpath. It was already compiled, but I needed it for templatesui. https://github.com/Obsidian-StudiosInc/os-xtoo/blob/master/eclass/java-netbeans.eclass#L158 https://github.com/Obsidian-StudiosInc/os-xtoo/blob/master/dev-java/netbeans-templatesui/netbeans-templatesui-9999.ebuild > roughly, javac looked into the jars, searched for > META-INF/services/javax.annotation.processing.Processor files, and > used processors registered by these files. I.e. processors in jars > were used in sources. Hmm, maybe some are missing that. But I tested that out when I added those files and resolved another issue with the unknown protocol nbres. Along with that file there was one for the annotation process. The net-java-html-json Model processor jar has that but it was not detected. # unzip -l /usr/share/net-java-html-json/lib/net-java-html-json.jar | grep javax META-INF/services/javax.annotation.processing.Processor # unzip -l /usr/share/netbeans-core-startup-9/lib/netbeans-core-startup.jar | grep java META-INF/namedservices/URLStreamHandler/nbresloc/java.net.URLStreamHandler META-INF/namedservices/URLStreamHandler/nbres/jav .net.URLStreamHandler META-INF/services/javax.annotation.processing.Processor META-INF/services/java.net.URLStreamHandlerFactory The URLStreamHandler stuff resolved my nbres issue. It did not see to help with any annotation. I still had to pass them. Which I do not mind. That seems to work well. > Then this: > $ javac -classpath <jars> <sources> > > Is mostly a shorthand for: > $ javac -classpath <jars> -processorpath <jars> <sources> Interesting, but seems redundant to be including things on the classpath for compile, and then maybe the same again for annotations. For ones that are just dependencies for annotation processors that might make sense. Just seems like lots of bloat and duplication. > In JDK 9, there is a new option, "--processor-module-path", which > works over JDK/Jigsaw modules (and disables the autosearch from > classpath/processorpath), but unless it is used, I don't offhand > recall a change that would disable the old classpath/processorpath > approach. I may need to repeat my tests, but I did come across what your talking about. That annotation processors should be found etc. Thus far it does not seem to be the case. I can test again tomorrow with source path. Though I was not adding classpath jars, so maybe that was my mistake. That would simplify things a bit. But for the most part I have the processors thing down now. > So if there is a particular commandline that did the > autosearch on 8 and does not on 9, then there may be a javac bug. Not sure if its a bug or not. I was wondering about the processor-module-path. The whole annotation processing in this manner is new to me. I am used to asm doing it but not within Java. I missed that feature of 1.8 or when ever it was added :P Obviously :) -- William L. Thomson Jr.
pgpeNV9qvKQ9B.pgp
Description: OpenPGP digital signature
