Utilizando la inyección de constructor de primavera con sonarqube

Victor S:

Tengo una pieza de código con inyecciones de campo que estoy tratando de convertir a utilizar inyecciones constructor en su lugar. El código inicial tiene el siguiente aspecto:

@Autowired
private Environment env;

@Autowired
private YYYAdaptor yyyAdaptor;

@Autowired
private JAXBContext jaxbContext;

Y así es como lo reescribo:

private Environment env;
private YYYAdaptor yyyAdaptor;
private JAXBContext jaxbContext;

@Autowired
public YYYResource(Environment env, YYYAdaptor yyyAdaptor, 
    @Qualifier("YYYYReq") JAXBContext jaxbContext) {

    this.env = env;
    this.yyyAdaptor = yyyAdaptor;
    this.jaxbContext = jaxbContext;
}

Hacer esto me da una vulnerabilidad crítica en la exploración de sonar, con "esta persona", en referencia a cada una de las variables declaradas:

Anotar esta persona con "@Autowired", "@Resource", "@Inject", o "@Valor", o eliminarla

¿Cuál es la mejor manera de que pueda evitar el uso de inyecciones de campo, evitando sonar de un arranque de cólera?

Nikolas:

Salida la regla sonarqube RSPEC-4288: componentes resorte debe usar la inyección de constructor . A pesar de que no explica por qué el finaluso se desencadena como no conformes, hay un ejemplo de código compatible. Inicializar los campos como nullpara que sea compatible con sonarqube:

private Environment env = null;
private YYYAdaptor yyyAdaptor = null;
private JAXBContext jaxbContext = null;

Sin embargo, lo que dice es sonarqube no sagrada y está lleno de un montón de falsos positivos . Estos analizadores estáticos-golpea los temas que son vale la mayor introspección, sin embargo, no es definitiva y en base a las reglas hechas por gente con opiniones.

En lo personal, me gustaría marcar este problema ya que no se va a arreglar y declarar los campos como finalpara hacer que el objeto inmutable:

private final Environment env;
private final YYYAdaptor yyyAdaptor;
private final JAXBContext jaxbContext;