Programmering

Kildekodeanalyse ved bruk av Java 6 APIer

av Seema Richard, Deepa Sobhana

Har du noen gang tenkt på hvordan verktøy som Checkstyle eller FindBugs utfører en statisk kodeanalyse, eller hvordan Integrated Development Environments (IDEer) som NetBeans eller Eclipse utfører raske kodefikser eller finner de nøyaktige referansene til et felt som er deklarert i koden din? I mange tilfeller har IDEs egne APIer for å analysere kildekoden og generere en standard trestruktur, kalt et Abstract Syntax Tree (AST) eller "parse tree", som kan brukes til dypere analyse av kildeelementene. Den gode nyheten er at det nå er mulig å utføre nevnte oppgaver pluss mye mer ved hjelp av tre nye APIer introdusert i Java som en del av Java Standard Edition 6-utgivelsen. API-ene som kan være av interesse for utviklere av Java-applikasjoner som trenger å utføre kildekodeanalyse, er Java Compiler API (JSR 199), Pluggable Annotation Processing API (JSR 269) og Compiler Tree API.

I denne artikkelen utforsker vi funksjonene til hver av disse API-ene og fortsetter med å utvikle et enkelt demoprogram som verifiserer visse Java-kodingsregler på et sett med kildekodefiler som leveres som inndata. Dette verktøyet viser også kodemeldingsbruddene, samt plasseringen til krenket kildekode som utdata. Vurder en enkel Java-klasse som overstyrer lik () -metoden til Object-klassen. Koderegelen som skal bekreftes, er at hver klasse som implementerer metoden equals (), også bør overstyre hashcode () -metoden med riktig signatur. Du kan se at TestClass-klassen nedenfor ikke definerer hashcode () -metoden, selv om den har lik () -metoden.

offentlig klasse TestClass implementerer Serializable {int num; @Override public boolean equals (Object obj)} 

La oss fortsette og analysere denne klassen som en del av byggeprosessen ved hjelp av disse tre API-ene.

Påkalle kompilatoren fra kode: Java Compiler API

Vi bruker alle javac kommandolinjeverktøy for å kompilere Java-kildefiler til klassefiler. Så hvorfor trenger vi et API for å kompilere Java-filer? Svaret er ganske enkelt: som navnet beskriver, lar denne nye standard APIen oss påkalle kompilatoren fra våre egne Java-applikasjoner; dvs. du kan programmatisk samhandle med kompilatoren og derved gjøre kompilering til en del av applikasjonsnivå-tjenester. Noen typiske bruksområder for denne API-en er oppført nedenfor.

  • Compiler API hjelper applikasjonsservere med å minimere tiden det tar å distribuere applikasjoner, for eksempel ved å unngå overhead for å bruke en ekstern kompilator for å kompilere servletkildene generert fra JSP-sidene.

  • Utviklerverktøy som IDEer og kodeanalysatorer kan påkalle kompilatoren fra editoren eller bygge verktøy som reduserer kompileringstiden betydelig.

Java-kompilatorklassene er pakket under javax.tools pakke. De ToolProvider klasse av denne pakken gir en metode som kalles getSystemJavaCompiler () som returnerer en forekomst av en klasse som implementerer JavaCompiler grensesnitt. Denne kompilatorforekomsten kan brukes til å lage en kompilasjonsoppgave som utfører selve kompilasjonen. Java-kildefilene som skal kompileres vil deretter sendes til kompileringsoppgaven. For dette gir kompilator-APIen en filadministrasjonsabstraksjon kalt JavaFileManager, som gjør det mulig å hente Java-filer fra forskjellige kilder, for eksempel filsystemet, databaser, minne og så videre. I dette eksemplet bruker vi StandardFileManager, en filbehandling basert på java.io. fil. Standard filbehandling kan anskaffes ved å ringe getStandardFileManager () metoden for JavaCompiler forekomst. Kodebiten for trinnene ovenfor er vist nedenfor:

// Få en forekomst av Java-kompilator JavaCompiler-kompilator = ToolProvider.getSystemJavaCompiler (); // Få en ny forekomst av standard filbehandling implementering StandardJavaFileManager fileManager = kompilator. getStandardFileManager (null, null, null); // Få listen over java-filobjekter, i dette tilfellet har vi bare // en fil, TestClass.java Iterable compilationUnits1 = fileManager.getJavaFileObjectsFromFiles ("TestClass.java"); 

En diagnostisk lytter kan valgfritt sendes til getStandardFileManager () metode for å produsere diagnostiske rapporter om eventuelle ikke-fatale problemer. I dette kodebiten passerer vi null verdier, siden vi ikke samler inn diagnostikken fra verktøyet. For detaljer om de andre parametrene som sendes til disse metodene, se Java 6 API. De getJavaFileObjectsfromFiles () metoden for StandardJavaFileManager returnerer alle JavaFileObject tilfeller som tilsvarer de medfølgende Java-kildefilene.

Les resten av denne artikkelen

Denne historien, "Source Code Analysis Using Java 6 APIs" ble opprinnelig utgitt av JavaWorld.

$config[zx-auto] not found$config[zx-overlay] not found