Develop Reference

How can I disable a specific type of missing comment warning in Javadoc?

I'm using javadoc through Gradle and since upgrading to Java 18, javadoc reports following warning:
warning: use of default constructor, which does not provide a comment
I would like this warning message to be disabled so that I can check for the completeness of javadoc comments in my project by looking at the number of reported warnings. In general, missing doc comments can be disabled with the -Xdoclint:all,-missing argument but this is too coarse as in my understanding it disables all missing comment warnings. Warnings that comments are missing on default constructors are not interesting or helpful to me so I would like to disable them specifically.
Further information: The JDK commit that introduced the checking of missing comments on default constructors specifies the missing-type dc.default.constructor but I haven't been able to find a way of using this.

Unfortunately, this is not possible. -Xdoclint only provides the missing key, with no more fine-grained control.
If you want more fine-grained control, you can use the require-javadoc program instead of -Xdoclint:missing. require-javadoc never requires comments on a default constructor, which does not appear in source code. Its configuration includes the following command-line options:
--exclude=<regex> - Don't check files or directories whose pathname matches the regex
--dont-require=<regex> - Don't report problems in Java elements whose name matches the regex
--dont-require-private=<boolean> - Don't report problems in elements with private access [default: false]
--dont-require-noarg-constructor=<boolean> - Don't report problems in constructors with zero formal params [default: false]
--dont-require-trivial-properties=<boolean> - Don't report problems about trivial getters and setters [default: false]
--dont-require-type=<boolean> - Don't report problems in type declarations [default: false]
--dont-require-field=<boolean> - Don't report problems in fields [default: false]
--dont-require-method=<boolean> - Don't report problems in methods and constructors [default: false]
--require-package-info=<boolean> - Require package-info.java file to exist [default: false]
--relative=<boolean> - Report relative rather than absolute filenames [default: false]
--verbose=<boolean> - Print diagnostic information [default: false]
Note, however, that require-javadoc never warns about missing Javadoc tags such as #param and #return.

Why is ANTLR not printing set of tokens correctly?

I am testing to see if ANTLR-4.7.1 is working properly by using a sample, provided by my professor, to match these results for the same printed set of tokens:
% java -jar ./antlr-4.7.1-complete.jar HelloExample.g4
% javac -cp antlr-4.7.1-complete.jar HelloExample*.java
% java -cp .:antlr-4.7.1-complete.jar org.antlr.v4.gui.TestRig HelloExample greeting helloworld.greeting -tokens
[#0,0:4='Hello',<1>,1:0]
[#1,6:10='World',<3>,1:6]
[#2,12:12='!',<2>,1:12]
[#3,14:13='<EOF>',<-1>,2:0]
(greeting Hello World !)
However, after getting to the 3rd command, my output was instead:
[#0,0:4='Hello',<'Hello'>,1:0]
[#1,6:10='World',<Name>,1:6]
[#2,12:12='!',<'!'>,1:12]
[#3,13:12='<EOF>',<EOF>,1:13]
In my output, there are no numbers inside < >, which I believe should be defined from the HelloExample.tokens file that contain:
Hello=1
Bang=2
Name=3
WS=4
'Hello'=1
'!'=2
I get no error information and antlr seemed to have generated all the files I needed, so I don't know where I should be looking to resolve this, please help. And I'm not sure if it'll be of use, but my working directory started with helloworld.greeting and HelloExample.g4 and final directory now contains
helloworld.greeting
HelloExample.g4
HelloExample.interp
HelloExample.tokens
HelloExampleBaseListener.class
HelloExampleBaseListener.java
HelloExampleLexer.class
HelloExampleLexer.inerp
HelloExampleLexer.java
HelloExampleLexer.tokens
HelloExampleListener.class
HelloExampleListener.java
HelloExampleParser$GreetingContext.class
HelloExampleParser.class
HelloExampleParser.java

As rici already pointed out in the comments, getting the actual rule names instead of their numbers in the token output is a feature and shouldn't worry you.
In order to get the (greeting Hello World !) output at the end, you'll want to add the -tree flag after -tokens.

How to pass parameters into JMX MBean function from command line

I am trying to remotely invoke an MBean via a commandline. Right now, I am able to list attributes and operations. For example, I can list all the attributes and operations for HotspotDiagnostic using this command:
java -jar cmdline-jmxclient-0.10.3.jar admin:P#sSw0rd 10.11.12.13:1111 com.sun.management:type=HotSpotDiagnostic
Which gives me this list of Attributes and Operations
Attributes:
DiagnosticOptions: DiagnosticOptions (type=[Ljavax.management.openmbean.CompositeData;)
ObjectName: ObjectName (type=javax.management.ObjectName)
Operations:
dumpHeap: dumpHeap
Parameters 2, return type=void
name=p0 type=java.lang.String p0
name=p1 type=boolean p1
getVMOption: getVMOption
Parameters 1, return type=javax.management.openmbean.CompositeData
name=p0 type=java.lang.String p0
setVMOption: setVMOption
Parameters 2, return type=void
name=p0 type=java.lang.String p0
name=p1 type=java.lang.String p1
But now lets say I want to invoke the dumpHeap operation which takes two parameters p0 and p1 of type string and boolean, respectively. How would I pass those arguments in?
I've tried these:
java -jar cmdline-jmxclient-0.10.3.jar admin:P#sSw0rd10.11.12.13:1111 com.sun.management:type=HotSpotDiagnostic dumpHeap p0=aaa p1=true
java -jar cmdline-jmxclient-0.10.3.jar admin:P#sSw0rd10.11.12.13:1111 com.sun.management:type=HotSpotDiagnostic dumpHeap aaa true
But I'm not sure what the syntax is, or even what I'm supposed to pass for the string parameter. This isn't for anything specific btw. Merely want to learn and understand more about how to leverage these operations from the command line. Any docs and assistance much appreciated.
EDIT: I'm naive. Oracle docs indicate the string param is an output file per this link. But still uncertain about how to pass the parameters into my command.

According to the cmdline-jmxclient documentation:
http://crawler.archive.org/cmdline-jmxclient/ you have to use comma-delimited parameters to pass to your operation.
So in your case if would be:
java -jar cmdline-jmxclient-0.10.3.jar admin:P#sSw0rd10.11.12.13:1111 com.sun.management:type=HotSpotDiagnostic dumpHeap test,true
Take note that there is an present bug in the cmdline jar file that doesn't take into account Java primitives(int, booelean, byte, etc.) and will throw a ClassNotFoundException because it can't find by the primitive name.
If you find yourself coming across this issue you can either apply the patch to the jar code that is documented here: https://webarchive.jira.com/browse/HER-1630. Or simply change the type field in the jmx endpoint code from it's primitive type to it's Wrapper object type (int -> Integer)

Run an ABCL code that uses cl-cppre

With reference to my previous question,
Executing a lisp function from Java
I was able to call lisp code from Java using ABCL.
But the problem is, the already existing lisp code uses CL-PPCRE package.
I can not compile the code as it says 'CL-PPCRE not found'.
I have tried different approaches to add that package,
including
1) how does one compile a clisp program which uses cl-ppcre?
2)https://groups.google.com/forum/#!topic/cl-ppcre/juSfOhEDa1k
Doesnot work!
Other thing is, that executing (compile-file aima.asd) works perfectly fine although it does also require cl-pprce
(defpackage #:aima-asd
(:use :cl :asdf))
(in-package :aima-asd)
(defsystem aima
:name "aima"
:version "0.1"
:components ((:file "defpackage")
(:file "main" :depends-on ("defpackage")))
:depends-on (:cl-ppcre))
The final java code is
interpreter.eval("(load \"aima/asdf.lisp\")");
interpreter.eval("(compile-file \"aima/aima.asd\")");
interpreter.eval("(compile-file \"aima/defpackage.lisp\")");
interpreter.eval("(in-package :aima)");
interpreter.eval("(load \"aima/aima.lisp\")");
interpreter.eval("(aima-load 'all)");
The error message is
Error loading C:/Users/Administrator.NUIG-1Z7HN12/workspace/aima/probability/domains/edit-nets.lisp at line 376 (offset 16389)
#<THREAD "main" {3A188AF2}>: Debugger invoked on condition of type READER-ERROR
The package "CL-PPCRE" can't be found.
[1] AIMA(1):
Can anyone help me?

You need to load cl-ppcre before you can use it. You can do that by using (asdf:load-system :aima), provided that you put both aima and cl-ppcre into locations that your ASDF searches.

I used QuickLisp to add cl-ppcre (because nothing else worked for me).
Here is what I did
(load \"~/QuickLisp.lisp\")")
(quicklisp-quickstart:install)
(load "~/quicklisp/setup.lisp")
(ql:quickload :cl-ppcre)
First 2 lines are only a one time things. Once quickLisp is installed you can start from line 3.

meaning of #(#) characters

In documentation code I see some things like this:
/*
* #(#)File.java 1.142 09/04/01
what does characters like #(#) meaning?

#(#) is the character string used by the Unix what command to filter strings from binaries to list the components that were used to build that binary. For instance what java on AIX yields:
java:
23 1.4 src/bos/usr/ccs/lib/libpthreads/init.c, libpth, bos520 8/19/99 12:20:14
61 1.14 src/bos/usr/ccs/lib/libc/__threads_init.c, libcthrd, bos520 7/11/00 12:04:14
src/tools/sov/java.c, tool, asdev, 20081128 1.83.1.36
src/misc/sov/copyrght.c, core, asdev, 20081128 1.8
while `strings java | grep '#(#)' yields:
#(#)23 1.4 src/bos/usr/ccs/lib/libpthreads/init.c, libpth, bos520 8/19/99 12:20:14
#(#)61 1.14 src/bos/usr/ccs/lib/libc/__threads_init.c, libcthrd, bos520 7/11/00 12:04:14
#(#)src/tools/sov/java.c, tool, asdev, 20081128 1.83.1.36
#(#)src/misc/sov/copyrght.c, core, asdev, 20081128 1.8
#(#) was chosen as marker because it would not occur elsewhere, source code controls systems typically add a line containing this marker and the description of the file version on synchronisation, expanding keywords with values reflecting the file contents.
For instance, the comment you list would be the result of expanding the SCCS keywords %Z% %M% %R%.%L% %E% where the %Z% translates into #(#).

From (hazy) memory, that was the tag used by SCCS back in the "good old days". Given that (to my knowledge), BitKeeper uses SCCS underneath, it could be BitKeeper.

It is usually something that is added automatically by the version control system.

That construct has no special meaning in Java. It is just some text in a comment.
It looks like something that's inserted by a version control system.