IntelliJ Idea: Декомпиляция, компиляция, алмаштыруу (же башка адамдардын катасын кантип оңдоо керек)

"Дөңгөлөктү кайра ойлоп таппа" - бул ийгorктүү жана натыйжалуу иштөөнүн негизги эрежелеринин бири. Бирок өзүңүздүн дөңгөлөкүңүздү кайра ойлоп тапкыңыз келбей, бирок башка бирөөнүн рулу кыйшык болуп, дөңгөлөктөр төрт бурчтуу болуп калганда эмне кылуу керек? Бул карап чыгуу башка адамдардын китепканаларын "акыркы чара катары" оңдоо ыкмасына мүмкүн болушунча кыскача киришүү жана бул маселени сиздин компьютериңизден тышкары кантип кеңейтүү үчүн арналган.

Киришүү

Биз баарыбыз тигил же бул куралды колдонобуз. Бирок кээде куралдар толугу менен ылайыктуу эмес же каталар бар. Java тorнин өзгөчөлүктөрүнүн аркасында биз керектүү жерде куралдардын жүрүм-турумун оңдой алабыз. Биз долбоорлорго салым кошконубуз жана тартуу өтүнүчтөрүн жөнөткөнүбүз жакшы (кеңири бул жерден окуй аласыз: “ GitHub - Долбоорлорго салым кошуу ”). Бирок алар дароо эле кабыл алынбашы мүмкүн, жада калса кабыл алынбай калышы да мүмкүн. Бирок долбоордун муктаждыктары үчүн азыр керек. Бул жерде, мен ишенем, бул макалада иштеп чыгуучулар катары бизге жеткorктүү куралдар көрсөтүлөт. Биз сүйлөшө турган төмөнкү кадамдарды жасашыбыз керек:

• Мисалы, сыноо тиркемесин даярдаңыз (Hibernate долбоорунун мисалын колдонуу менен)
• Өзгөрүүчү жерди табуу
• өзгөртүү киргизүү
• Репозиторийди жайылтуу

Төмөндөгү бардык кадамдар Windows OS үчүн берилген, бирок nix системалары үчүн аналогдору бар. Ошентип, зарыл болсо, аларды кайталай аласыз.

Предметти даярдоо

Демек, бизге сыноо долбоору керек. Күтүү режими биз үчүн идеалдуу, анткени... бул "стильдүү, модалуу, заманбап". Мен майда-чүйдөсүнө чейин айтпай эле коёюн, анткени... Макала Күтүү режими жөнүндө эмес. Биз бардыгын тез жана так аткарабыз. Жана биз, туура иштеп чыгуучулар сыяктуу, куруу системасын колдонобуз. Мисалы, Gradle биз үчүн да ылайыктуу, бул макала үчүн орнотулушу керек ( https://gradle.org/install/ ). Биринчиден, биз долбоор түзүү керек. Maven бул үчүн архетиптерге ээ жана Gradle бул үчүн атайын плагинге ээ: Gradle Init . Ошентип, буйрук сабын сизге белгилүү болгон жол менен ачыңыз. Долбоор үчүн каталог түзүп, ага барып, буйрукту аткарыңыз:

mkdir javarush 
cd javarush 
gradle init --type java-application

Долбоорду импорттоодон мурун, келгиле, кантип курууну сүрөттөгөн файлга бир аз өзгөртүүлөрдү киргизели. Бул файл куруу скрипти деп аталат жана build.gradle деп аталат. Ал биз gradle init аткарган каталогдо жайгашкан. Ошондуктан, биз аны жөн гана ачабыз (мисалы, Windowsта start build.gradle буйругу менен). Биз ал жерден " көз карандылык " блогун табабыз, б.а. көз карандылыктар. Биз колдоно турган бардык үчүнчү жактын банкалары бул жерде сүрөттөлгөн. Эми бул жерде эмнени сүрөттөш керектигин түшүнүшүбүз керек. Күтүү веб-сайтына баралы ( http://hibernate.org/ ). Бизди Hibernate ORM кызыктырат . Бизге акыркы релиз керек. Сол жактагы менюда "Чыгаруулар" бөлүмчөсү бар. "Акыркы туруктуу" тандоо. Төмөн сыдырып, "Негизги ишке ашыруу (JPA камтыйт)" табыңыз. Мурда JPA колдоосун өзүнчө туташтыруу керек болчу, бирок азыр баары жөнөкөй болуп, бир гана көз карандылык жетиштүү. Биз ошондой эле Hibernate аркылуу маалымат базасы менен иштешибиз керек болот. Бул үчүн, эң жөнөкөй вариантты алалы - H2 Database . Тандоо жасалды, бул жерде биздин көз карандылыктарыбыз:

dependencies {
    // Базовая зависимость для Hibernate (новые версии включают и JPA)
    compile 'org.hibernate:hibernate-core:5.2.17.Final'
    // База данных, к которой мы будем подключаться
    compile 'com.h2database:h2:1.4.197'
    // Use JUnit test framework
    testCompile 'junit:junit:4.12'
}

Сонун, кийинкиси эмне болот? Биз күтүү режимин конфигурациялашыбыз керек. Hibernate режиминде " Баштоо колдонмосу " бар, бирок ал акылсыз жана жардамга караганда көбүрөөк тоскоолдук жаратат. Ошондуктан, келгиле, туура адамдар сыяктуу түз эле " Колдонуучунун колдонмосуна " баралы. Мазмундун tableсында биз бөлүмдү көрөбүз " Bootstrap ", ал "Bootstrapping" деп которулат. Сизге эмне керек. Ал жерде көптөгөн акылдуу сөздөр жазылган, бирок кептин баары класс жолунда META-INF каталогу жана persistence.xml файлы болушу керек. Стандартка ылайык, класс жолунда "ресурстар" каталогу бар. Ошондуктан, биз көрсөтүлгөн каталогду түзөбүз: mkdir src\main\resources\META-INF Ал жерде persistence.xml файлын түзүп, аны ачыңыз. Документте "Мисал 268. META-INF/persistence.xml конфигурация файлы" үлгүсү бар, андан биз мазмунду алып, аны persistence.xml файлына киргизебиз. Андан кийин, IDEди ишке киргизип, ага биздин түзүлгөн долбоорду импорттоо. Эми биз маалымат базасына бир нерсени сактоо керек. Бул субъект деп аталган нерсе. Объекттер домен моделинен бир нерсени билдирет. Ал эми мазмундун tableсында, мына, биз “ 2. Домен моделин ” көрөбүз. Биз текстти ылдый карайбыз жана "2.1. Картага түшүрүү түрлөрү" бөлүмүндө an objectтин жөнөкөй мисалын көрөбүз. Аны бир аз кыскартып, өзүбүзгө алалы:

package entity;

import javax.persistence.Entity;
import javax.persistence.GeneratedValue;
import javax.persistence.Id;

@Entity(name = "Contact")
public class Contact {

    @Id
    @GeneratedValue
    private Integer id;

    private String name;

    public Contact(String name) {
        this.name = name;
    }
}

Эми бизде an objectти билдирген класс бар. Келгиле, кайра persistence.xml сайтына кайрылып, ал жерде бир жерди оңдойлу: Көрсөтүлгөн жерде classбиз классыбызды көрсөтөбүз entity.Contact. Жакшы, болгону ишке киргизүү калды. Bootstrap бөлүмүнө кайрылып көрөлү . Бизде атайын EE чөйрөсүн камсыз кыла турган тиркеме serverибиз жок болгондуктан (б.а., биз үчүн белгилүү бир системанын жүрүм-турумун ишке ашырган чөйрө), биз SE чөйрөсүндө иштейбиз. Бул үчүн, бизге "Мисал 269. Колдонмо жүктөгөн EntityManagerFactory" үлгүсү гана ылайыктуу. Мисалы, муну кылалы:

public class App {
    public static void main(String[] args) {
        EntityManagerFactory emf = Persistence.createEntityManagerFactory("CRM");
        EntityManager em = emf.createEntityManager();
        em.getTransaction().begin();
        Contact contact = new Contact("Vasya");
        em.persist(contact);
        em.getTransaction().commit();
        Query sqlQuery = em.createNativeQuery("select count(*) from contact");
        BigInteger count = (BigInteger) sqlQuery.getSingleResult();
        emf.close();
        System.out.println("Entiries count: " + count);
    }
}

Урра, биздин тема даяр. Мен бул бөлүгүн калтыргым келген жок , анткени... Кийинки бөлүмдөрдө биздин тема кантип пайда болгонун түшүнүү максатка ылайык.

Өзгөртүлүүчү жүрүм-турумду табуу

Келгиле, BigInteger түрүндөгү эсептөө талаасынын инициализацияланган ордун алалы жана ал жерде үзгүлтүккө учураган чекиттерди орнотобуз ( BreakPoint ). Керектүү линияга киргизгенден кийин, бул Ctrl+F8 же меню аркылуу аткарылышы мүмкүн Run -> Toggle Line Breakpoint. Андан кийин биз негизги ыкмабызды мүчүлүштүктөрдү оңдоодо иштетебиз (Run -> Debug): Бир аз олдоксон мисал, бирок биз баштоодо суроо мейкиндиктеринин санын өзгөрткүбүз келет дейли. Көрүнүп тургандай, биздин sqlQuery бул NativeQueryImpl. чыкылдатып Ctrl+N, класстын атын жазып, ага өтүңүз. Ошентип, биз класска барганда, биз бул класс жайгашкан жерге которулуп, автосыдырууну күйгүзөбүз: Дароо белгилеп кетели, Idea учурда программанын баштапкы codeун (башкы code, башкача айтканда) кайдан табаарын билбейт. Ошондуктан, ал биз үчүн класстык файлдын мазмунун боорукердик менен чечмелеп берди: IntelliJ Idea терезесинин аталышында Gradle артефактты биз үчүн сактаган жери жазылганын да эске алыңыз. Эми, келгиле, биздин артефакт жайгашкан жолду карайлы: Келгиле, буйрукту колдонуп, буйрук сабындагы бул каталогго баралы cd way to каталогу. Мен дароо эскертем: эгер булактан долбоор куруу мүмкүн болсо, булактан куруу жакшы. Мисалы, Hibernate булак codeу расмий сайтында бар. Аны каалаган versionга алып, ошол жерде бардык өзгөртүүлөрдү киргизип, долбоордо көрсөтүлгөн куруу скрипттерин колдонуп чогултканыңыз жакшы. Мен макалада эң коркунучтуу вариантты сунуштайм - банка бар, бирок баштапкы codeу жок. Ал эми №2 эскертүү: Gradle плагиндер аркылуу баштапкы codeду ала алат. Чоо-жайын билүү үчүн Gradle аркылуу jar үчүн javadocs жана булактарды кантип жүктөө керек экенин караңыз .

өзгөртүү киргизүү

Биз өзгөртүп жаткан класс кайсы пакетке ылайык каталог түзүмүн кайра түзүшүбүз керек. Бул учурда: mkdir org\hibernate\query\internal, андан кийин биз бул каталогдо файлды түзөбүз NativeQueryImpl.java. Эми биз бул файлды ачып, класстын бардык мазмунун ошол жердеги IDEден көчүрөбүз (Идеа биз үчүн декомпиляция кылган). Керектүү саптарды өзгөртүү. Мисалы: Эми файлды компиляция кылалы. Биз жасайбыз: javac org\hibernate\query\internal\NativeQueryImpl.java. Wow, сиз аны жөн эле алып, катасыз түзө албайсыз. Символду табуу мүмкүн эмес бир топ каталарды алдык, анткени... өзгөрүлүүчү класс башка класстарга байланган, аларды IntelliJ Idea адатта биз үчүн класс жолуна кошот. Биздин IDEлердин бардык пайдалуулугун сезесизби? =) Мейли, өзүбүз кошуп алалы, биздин да колубуздан келет. Келгиле, жолдорду көчүрөлү:

• [1] - hibernate-core-5.2.17.Final.jar
• [2] - hibernate-jpa-2.1-api-1.0.0.Final.jar

Биз кылгандай: "Тышкы китепканалардагы" "Долбоор" көрүнүшүндө биз керектүү банканы таап, басыңыз Ctrl+Shift+C. Эми төмөнкү буйрукту түзүп, аткаралы: javac -cp [1];[2] org\hibernate\query\internal\NativeQueryImpl.java Натыйжада, java файлынын жанында жаңы класс файлдары пайда болот, аларды jar файлында жаңыртуу керек: Уррай, эми сиз банканы жаңырта аласыз. Биз расмий материалдарды жетекчorкке алабыз : jar uf hibernate-core-5.2.17.Final.jar org\hibernate\query\internal\*.class Open IntelliJ Idea файлдарды өзгөртүүгө мүмкүндүк бербейт. Ошондуктан, банканы жаңыртуудан мурун, сиз Ideaны жаап, жаңыртылгандан кийин аны ачышыңыз керек болот. Андан кийин, сиз IDEди кайра ачып, кайра дубагды иштете аласыз. Break Points IDE кайра баштоонун ортосунда баштапкы абалга келтирилбейт. Демек, программанын аткарылышы мурда болгон жерде токтойт. Voila, биз өзгөртүүлөрүбүздүн кантип иштээрин көрүп жатабыз: Абдан жакшы. Бирок бул жерде суроо туулат - эмнеден улам? Жөн гана gradle долбоорду куруп жатканда, ал көз карандылыкты жана репозиторийлер блогун талдайт. Gradle белгилүү бир жерде жайгашкан белгилүү бир куруу кэшине ээ (караңыз “ Gradle кэштин ордун кантип коюу керек? ” Эгер кэште көз карандылык жок болсо, Gradle аны репозиторийден жүктөп алат. Биз банканы өзгөрткөндүктөн кэштин өзү болсо, анда Градл китепкана кэште жана эч нерсени сордурbyte деп ойлойт.Бирок кэштин ар кандай тазалануусу биздин өзгөртүүлөрүбүздүн жоголуп кетишине алып келет.Мындан тышкары, бизден башка эч ким барып, аларды ала алbyte. Канчалык ыңгайсыздык ?

Репозиторийди жайылтуу

Репозиторийиңизди жайгаштыруу үчүн ар кандай акысыз чечимдер бар: алардын бири - Artifactory , экинчиси - Apache Archive . Artifactory модалуу, стилдүү, заманбап көрүнөт, бирок мен аны менен кыйынчылыктарга туш болдум, мен артефакттарды туура жайгаштыргым келген жок жана ката maven метадайындарын түздүм. Ошондуктан, мен үчүн күтүлбөгөн жерден Apache versionсы мен үчүн иштеген. Бул анчалык кооз эмес болуп чыкты, бирок ал ишенимдүү иштейт. Жүктөп алуу барагынан өз алдынча versionсын издеп, аны таңгактан чыгарыңыз. Алардын өздөрүнүн " Тез баштоо " бар. Ишке киргизгенден кийин, даректи күтүшүңүз керек http://127.0.0.1:8080/#repositorylist. Андан кийин, "Артефактты жүктөө" тандаңыз: "Жүктөөнү баштоо" баскычын чыкылдатып, андан кийин "Файлдарды сактоо" баскычын чыкылдатыңыз. Андан кийин, жашыл ийгorк билдирүү пайда болот жана артефакт "Көрүү" бөлүмүндө жеткorктүү болот. Бул jar жана pom файлдары үчүн жасалышы керек: Бул пом файлында кошумча күтүү көз карандылыгы көрсөтүлгөндүгүнө байланыштуу. Ал эми бизде болгону 1 кадам калды - куруу скриптибизде репозиторийди көрсөтүңүз:

repositories {
    jcenter()
    maven {
        url "http://127.0.0.1:8080/repository/internal/"
    }
}

Жана, ошого жараша, биздин гибернация versionсы болуп калат: compile 'org.hibernate:hibernate-core:5.2.17.Final-JAVARUSH'. Болду, эми биздин долбоор түпнуска эмес, биз оңдогон versionны колдонот.

Корутунду

Таанышып калдык окшойт. Мен бул кызыктуу болду деп үмүттөнөм. Мындай "трюктар" сейрек жасалат, бирок күтүлбөгөн жерден бизнес талаптарыңыз сиз колдонгон китепканалар канааттандыра албаган шарттарды коюп калса, эмне кылуу керектигин билесиз. Ооба, бул жерде ушул жол менен оңдоого боло турган бир нече мисалдар бар:

• Undertow деген веб-server бар. Бир нече убакытка чейин проксиди колдонууда акыркы колдонуучунун IP дарегин аныктоого мүмкүндүк бербеген ката бар болчу.
• Азырынча, WildFly JPA белгилүү бир жол менен бир көз ирмемди спецификацияда эске албагандыктан, өзгөчөлүктөр ташталган. Жана ал конфигурацияланган эмес.

#Вячеслав