kirjoittanut Seema Richard, Deepa Sobhana
Oletko koskaan ajatellut, kuinka Checkstylen tai FindBugin kaltaiset työkalut suorittavat staattisen koodianalyysin, tai kuinka integroidut kehitysympäristöt (IDE), kuten NetBeans tai Eclipse, suorittavat koodin pikakorjauksia tai löytävät koodissasi ilmoitetun kentän tarkat viitteet? Monissa tapauksissa IDE: llä on omat sovellusliittymät lähdekoodin jäsentämiseksi ja tavallisen puurakenteen muodostamiseksi, nimeltään Abstract Syntax Tree (AST) tai "jäsennyspuuksi", jota voidaan käyttää lähde-elementtien syvempään analysointiin. Hyvä uutinen on, että nyt on mahdollista suorittaa mainitut tehtävät ja paljon muuta kolmen uuden sovellusliittymän avulla, jotka on otettu käyttöön Javaissa osana Java Standard Edition 6 -julkaisua. Sovellusliittymät, jotka saattavat kiinnostaa lähdekoodianalyysin suorittavien Java-sovellusten kehittäjiä, ovat Java Compiler API (JSR 199), Pluggable Annotation Processing API (JSR 269) ja Compiler Tree API.
Tässä artikkelissa tutkitaan kunkin näiden sovellusliittymien ominaisuuksia ja kehitetään yksinkertainen esittelysovellus, joka tarkistaa tietyt Java-koodaussäännöt syötekoodina toimitetuista lähdekooditiedostoista. Tämä apuohjelma näyttää myös koodausrikkomusviestit sekä rikkotun lähdekoodin sijainnin ulostulona. Tarkastellaan yksinkertaista Java-luokkaa, joka ohittaa Object-luokan equals () -menetelmän. Tarkistettava koodaussääntö on, että jokaisen equals () -menetelmän toteuttavan luokan tulisi myös ohittaa hashcode () -menetelmä oikealla allekirjoituksella. Voit nähdä, että alla oleva TestClass-luokka ei määritä hashcode () -menetelmää, vaikka sillä on equals () -menetelmä.
julkinen luokka TestClass toteuttaa Serializable {int num; @Override public boolean equals (Object obj)} Jatketaan ja analysoidaan tätä luokkaa osana rakennusprosessia näiden kolmen API: n avulla.
Kääntäjän kutsuminen koodista: Java Compiler -sovellusliittymä
Me kaikki käytämme javac komentorivityökalu Java-lähdetiedostojen kokoamiseksi luokkatiedostoiksi. Miksi sitten tarvitsemme API: n Java-tiedostojen kokoamiseen? No, vastaus on melko yksinkertainen: kuten nimi kuvaa, tämä uusi standardi-sovellusliittymä antaa meille mahdollisuuden kääntää kääntäjää omista Java-sovelluksistamme; ts. voit olla ohjelmallisesti vuorovaikutuksessa kääntäjän kanssa ja tehdä siten käännöksestä osa sovellustason palveluita. Joitakin tämän sovellusliittymän tyypillisiä käyttötapoja on lueteltu alla.
Kääntäjä-sovellusliittymä auttaa sovelluspalvelimia minimoimaan sovellusten käyttöönottoon tarvittavan ajan, esimerkiksi välttämällä ulkoisen kääntäjän käytön kustannuksia JSP-sivuilta tuotettujen servlet-lähteiden kokoamisessa.
Kehittäjien työkalut, kuten IDE: t ja koodianalysaattorit, voivat kutsua kääntäjän muokkausohjelmassa tai luoda työkaluja, jotka lyhentävät merkittävästi kääntöaikaa.
Java-kääntäjän luokat on pakattu javax.tools paketti. ToolProvider Tämän paketin luokka tarjoaa kutsutun menetelmän getSystemJavaCompiler () joka palauttaa jonkin luokan ilmentymän, joka toteuttaa JavaCompiler käyttöliittymä. Tätä kääntäjän esiintymää voidaan käyttää luomaan kokoamistehtävä, joka suorittaa varsinaisen kokoamisen. Käännettävät Java-lähdetiedostot siirretään sitten kääntötehtävään. Tätä varten kääntäjän sovellusliittymä tarjoaa tiedostonhallinnan abstraktion, jota kutsutaan JavaFileManager, jonka avulla Java-tiedostot voidaan hakea useista lähteistä, kuten tiedostojärjestelmästä, tietokannoista, muistista ja niin edelleen. Tässä näytteessä käytämme StandardFileManager, tiedostojen hallinta java.io.File. Vakiotiedostonhallinta voidaan hankkia soittamalla getStandardFileManager () menetelmä JavaCompiler ilmentymä. Edellä mainittujen vaiheiden koodinpätkä näkyy alla:
// Hanki Java-kääntäjän ilmentymä JavaCompiler compiler = ToolProvider.getSystemJavaCompiler (); // Hanki uusi tiedostohallinnan vakiomallinnuksen uusi ilmentymä StandardJavaFileManager fileManager = kääntäjä. getStandardFileManager (null, null, null); // Hae luettelo java-tiedostoobjekteista, tässä tapauksessa meillä on vain // yksi tiedosto, TestClass.java Iterable compilationUnits1 = fileManager.getJavaFileObjectsFromFiles ("TestClass.java"); Diagnostinen kuuntelija voidaan valinnaisesti siirtää getStandardFileManager () menetelmä diagnoosiraporttien tuottamiseksi kaikista muista kuin kuolemaan johtavista ongelmista. Tässä koodinpätkässä ohitamme tyhjä arvoja, koska emme kerää diagnostiikkaa työkalusta. Lisätietoja muista näille menetelmille välitetyistä parametreista on Java 6 -sovellusliittymässä. getJavaFileObjectsfromFiles () menetelmä VakioJavaFileManager palauttaa kaikki JavaFileObject esiintymiä, jotka vastaavat toimitettuja Java-lähdetiedostoja.
Lue loput tästä artikkelista
Tämän tarinan "Lähdekoodianalyysi Java 6 -sovellusliittymien avulla" julkaisi alun perin JavaWorld.
