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.

Alternative for AnyLogic deprecated method getJComponent()?

I recently updated to AnyLogic PLE 8.4.0 and Java SE 12 on my Windows 10 laptop. And now an AnyLogic model that used to work earlier stops with the error "The method getJComponent() is undefined for the type ShapeTextField." I looked it up in AnyLogic/Help and I notice that getJComponent is identified as "Deprecated" and no alternative is identified. It appears to me that some mismatch happened between AnyLogic and Java updates that resulted in this error. I would appreciate any workarounds to get the model working.
Tried replacing getJComponent() with the following:
by getX() - gave error "cannot cast from double to Jtextfield"
by getPresentable() - gave error "cannot cast from Presentable to Jtextfield"
by getClass() - gave error "Description: Cannot cast from Class to JTextField."
by getComponentGraphics() - gave error "Description: The method getComponentGraphics() is undefined for the type ShapeTextField."
by equals - gave error "Description: The method equals(Object) in the type Object is not applicable for the arguments ()."
The code is:
((JTextField)(editbox.getJComponent())).setHorizontalAlignment(JTextField.LEFT);
This is defined in Simulation - Simulation Experiment / Java Actions/ Initial Experiment Setup field
Expected result: No error message. And the model should proceed to run window.

Thanks to the inputs from #Benjamin and #Felipe the following worked:
I replaced the editbox and buttons with corresponding artifacts from
AL8.4 palette. I copied the code from the earlier artifacts to
corresponding fields in the new artifacts. I deleted the artifacts
that were from AL7.
I commented out the line that was meant to align the editbox since
that capability is not available anymore.
With the above two changes I didn't get the error message about undefined method. The editbox and buttons worked and allowed me to enter XML filename and reading it with an XML parser routine. I have now run into issue with JAXB integration with AL8.4 and haven't been able to get past that yet. I will be posting that as a separate question.

Using toUpperCase with Correct Locale

I'm trying to fix errors which are reported by forbiddenapis. I had that line:
paramMap.put(Config.TITLEBOOST.toUpperCase(), titleBoost);
So, its been reported as error as usual. I've tried that:
paramMap.put(Config.TITLEBOOST.toUpperCase(Locale.getDefault()), titleBoost);
and that:
paramMap.put(Config.TITLEBOOST.toUpperCase(Locale.ROOT), titleBoost);
also that:
paramMap.put(Config.TITLEBOOST.toUpperCase(Locale.ENGLISH), titleBoost);
However none of them fixed the error:
[forbiddenapis] Forbidden method invocation:
java.lang.String#toUpperCase() [Uses default locale]
What I miss?

Double-check that the bytecode you are analyzing is actually your most recent build output, and that you're looking at the same line forbiddenapis is :) . This looks to me like your source/bytecode/analysis are falling out of sync — the relevant rule shouldn't flag an error on String.toUpperCase(Locale).
Disclaimer: I haven't used forbiddenapis myself --- I wrote this answer based on the repo and on a blog post I found.

JAVA SQLException error message sometimes not parsed

I am new to JDBC, and I found something strange when I use:
catch (SQLException e) {
System.out.println("Error STATE: " + e.getSQLState());
System.out.println("With the following message: " + e.getMessage() );
}
Sometimes the message is parsed, but sometimes not.
Like:
First:
Second:
One is parsed, while the other is not, but I can get the error message through googling the corresponding error code.
I don't know what's going on.. And I have tried googling it but with no similar question posted. Does it mean my java.sql.* library is incomplete?
All help would be appreciated.

It means your operating system settings don't support the symbols for the error message in the language being used. The ORA-01017 message is coming before the database applies your language setting so in in English, and more importantly in Western script. Once you've connected the Java locale is honoured.
For example, I can see both these from the same code run with java -Duser.language=zh -Duser.country=CN; the first has incorrect credentials supplied, the second is trying to create an existing table:
java.sql.SQLException: ORA-01017: invalid username/password; logon denied
java.sql.SQLSyntaxErrorException: ORA-00955: 名称已由现有对象使用
I'm seeing ten symbols, where you are seeing ten question marks. My operating system session (Linux in this case) has LANG=en_US.UTF-8. If I change that to something which has fewer symbols defined, e.g. export LANG="en_US.ASCII", I still see the first message but now I get the same as you for the second one:
java.sql.SQLException: ORA-01017: invalid username/password; logon denied
java.sql.SQLSyntaxErrorException: ORA-00955: ??????????
The Chinese symbols can now no longer be rendered by my operating system session.
So set your operating system locale to something that can represent the symbols of the language you're using, preferably UTF8. For example, if Java is running with a Chinese locale, you could do this to be consistent under Linux:
export LANG="zh_CN.UTF-8"
java -Duser.language=zh -Duser.country=CN
ORA-00955: 名称已由现有对象使用
Or change your Java locale to English-language if you want to see all the messages in English:
export LANG="en_CN.UTF-8"
java -Duser.language=en -Duser.country=CN -
ORA-00955: name is already used by an existing object
(Although Java should pick up the language from your locale by default anyway, so maybe don't supply the language or country explicitly in the java call at all; just setting LANG properly would then be enough)

Disable logging in Java Xerces ("[Fatal Error] :1:1: Content is not allowed in prolog.")

My application expects that it will sometimes try to parse invalid XML documents. I currently catch the "SAXParseException: Content is not allowed in prolog." exception, which works fine. However, Xerces still feels the need to print it's own message to the console:
[Fatal Error] :1:1: Content is not allowed in prolog.
Is there any way to disable this?

I just recently came across the same need. Setting the ErrorHandler to null suppresses the Fatal Error print line.
parser.setErrorHandler(null);

I believe it is printing to System.out or System.err by default. There is an ErrorHandler interface you can set on the Parser if you're interacting with the Xerces classes directly.
Otherwise, you can try setting the property org.apache.xerces.impl.Constants.ERROR_REPORTER_PROPERTY on the SAXParser with an instance of XMLErrorReporter

The equivalent when using org.w3c.dom.ls.LSParser is
parser.getDomConfig().setParameter("error-handler", null);
I had this problem today and it turned out to be a standard configuration parameter that I found only after reading your answers here. Thanks.