blob: 80ee72abcc396a2db06e37a982a7268f7dbeca1e [file] [log] [blame]
<!--
Copyright (c) 2011, 2018 Oracle and/or its affiliates. All rights reserved.
This program and the accompanying materials are made available under the
terms of the Eclipse Public License v. 2.0, which is available at
http://www.eclipse.org/legal/epl-2.0.
This Source Code may also be made available under the following Secondary
Licenses when the conditions for such availability set forth in the
Eclipse Public License v. 2.0 are satisfied: GNU General Public License,
version 2 with the GNU Classpath Exception, which is available at
https://www.gnu.org/software/classpath/license.html.
SPDX-License-Identifier: EPL-2.0 OR GPL-2.0 WITH Classpath-exception-2.0
-->
<FindBugsFilter>
<!--
From Tim Quinn:
The current structure of the code makes it complicated to arrange a
series of method returns back to the main method return to accomplish
the same as invoking System.exit. If the user ran "appclient -help"
then we're not going to even try to run the ACC, just display the
help, so exit seems OK here.
-->
<Match>
<Class name="org.glassfish.appclient.client.AppClientFacade"/>
<Method name="help"/>
<Bug pattern="DM_EXIT"/>
</Match>
<!--
From Tim Quinn:
The only (supported) way that JWSAppClientContainerMain's main method
is invoked is during a Java Web Start launch of a client, in which
case the usage method in question would be invoked only if there was
an error in how GF prepared the URL and/or the JNLP document. A user
could cause GF to add the equivalent of the -usage option to the JNLP
but there's no good reason to do that and exiting in that case is fine
as far as I'm concerned.
-->
<Match>
<Class name="org.glassfish.appclient.client.AppClientFacade"/>
<Method name="usage"/>
<Bug pattern="DM_EXIT"/>
</Match>
<!--
From Tim Quinn:
This call to exit supports a seldom-used feature of the Java Web Start
support for app clients in which the caller can ask that the ACC exit
right away after returning from the client. (Normally we'll wait
until the event dispatcher thread runs down.) This has been useful,
at least in the past, when oddities in the vendor's Java Web Start
implementation caused the VM to hang around when the client is a non-
GUI client (as in our devtests). This primarily affected Apple's VM a
few releases ago, IIRC.
-->
<Match>
<Class name="org.glassfish.appclient.client.jws.boot.JWSACCMain$1"/>
<Method name="run"/>
<Bug pattern="DM_EXIT"/>
</Match>
<!--
From Tim Quinn:
Refactoring is possible, but at the cost of greater complexity. Plus
I think FindBugs has missed something. It is correct that the "this"
of the containing class is used only during construction, but part of
what the constructor does is to instantiate other inner classes of the
same common containing object and those constructors use the implicit
"this" argument. Changing the UserVMArgs inner class to be static
would force refactoring of several other inner classes. That seems to
me to be a fair amount of work and added complexity to suppress this
FindBugs notification.
-->
<Match>
<Class name="org.glassfish.appclient.client.CLIBootstrap$UserVMArgs"/>
<Bug pattern="SIC_INNER_SHOULD_BE_STATIC_NEEDS_THIS"/>
</Match>
</FindBugsFilter>