Java >> Java tutorial >  >> Tag >> switch

Er der behov for at skifte til moduler ved migrering til Java 9+/Java 11?

switch

Nej.

Der er ingen grund til at skifte til moduler.

Der har aldrig været behov for at skifte til moduler.

Java 9 og senere udgivelser understøtter traditionelle JAR-filer på den traditionelle klassesti via konceptet med det unavngivne modul, og vil sandsynligvis gøre det indtil universets varmedød.

Om du vil begynde at bruge moduler er helt op til dig.

Hvis du vedligeholder et stort arveprojekt, der ikke ændrer sig ret meget, så er det sandsynligvis ikke besværet værd.

Hvis du arbejder på et stort projekt, som er blevet vanskeligt at vedligeholde i årenes løb, kan den klarhed og disciplin, som modularisering bringer, være gavnlig, men det kan også være en masse arbejde, så tænk dig godt om, før du begynder.

Hvis du starter et nyt projekt, så anbefaler jeg stærkt at starte med moduler, hvis du kan. Mange populære biblioteker er efterhånden blevet opgraderet til at være moduler, så der er en god chance for, at alle de afhængigheder, du har brug for, allerede er tilgængelige i modulær form.

Hvis du vedligeholder et bibliotek, anbefaler jeg stærkt, at du opgraderer det til et modul, hvis du ikke allerede har gjort det, og hvis alle dit biblioteks afhængigheder er blevet konverteret.

Alt dette betyder ikke, at du ikke vil støde på et par snublesten, når du går forbi Java 8. Dem, du støder på, vil dog sandsynligvis ikke have noget at gøre med moduler per se . De mest almindelige migrationsproblemer, som vi har hørt om, siden vi udgav Java 9 i 2017, har at gøre med ændringer i syntaksen for versionsstrengen og fjernelse eller indkapsling af interne API'er (f.eks. , sun.misc.Base64Decoder ) for hvilke offentlige, understøttede udskiftninger har været tilgængelige i årevis.


Jeg kan kun fortælle dig min organisations mening om sagen. Vi er i gang med at flytte til moduler, for hvert enkelt projekt, vi arbejder på. Det, vi bygger, er grundlæggende mikrotjenester + nogle klientbiblioteker. For mikrotjenester er overgangen til modules er på en eller anden måde en lavere prioritet:koden der er allerede på en eller anden måde isoleret i docker-containeren, så det virker ikke (for os) særlig vigtigt at "tilføje" moduler der. Dette arbejde tages langsomt op, men det har lav prioritet.

På den anden side er klientbiblioteker en helt anden historie. Jeg kan ikke fortælle dig det rod, vi har nogle gange. Jeg vil forklare et punkt, som jeg hadede før jigsaw . Du eksponerer en grænseflade for klienter, som alle kan bruge. Automatisk at interface er public - udsat for verden. Normalt, hvad jeg gør, er at have nogle package-private klasser, der ikke er eksponeret for de klienter, der bruger denne grænseflade. Jeg vil ikke have, at kunderne bruger det, det er internt. Lyder godt? Forkert.

Det første problem er, at når disse package-private klasser vokser, og du vil have flere klasser, den eneste måde at holde alt skjult på er at oprette klasser i det samme pakke:

  package abc:
        -- /* non-public */ Usage.java
        -- /* non-public */ HelperUsage.java
        -- /* non-public */ FactoryUsage.java
        ....

Når det vokser (i vores tilfælde gør det det), er disse pakker alt for store. Flytter du til en separat pakke siger du? Selvfølgelig, men så den HelperUsage og FactoryUsage vil være public og det forsøgte vi at undgå fra begyndelsen.

Problem nummer to:enhver bruger/opkalder af vores kunder kan oprette den samme pakke navngive og udvide disse skjulte klasser. Det er allerede sket et par gange for os, sjove tider.

modules løser dette problem på en smuk måde:public er ikke rigtig public længere; Jeg kan have friend adgang via exports to direktiv. Dette gør vores kodelivscyklus og administration meget nemmere. Og vi kommer væk fra klassestiens helvede. Selvfølgelig maven/gradle håndtere det primært for os, men når der er et problem, vil smerten være meget reel. Der kunne også være mange andre eksempler.

Når det er sagt, er overgang (stadig) ikke let. Først og fremmest skal alle på holdet være på linje; for det andet er der forhindringer. De to største, jeg stadig ser, er:hvordan adskiller man hvert modul, baseret på hvad, specifikt? Jeg har ikke et entydigt svar endnu. Den anden er split-packages , åh den smukke "samme klasse eksporteres af forskellige moduler". Hvis dette sker med dine biblioteker, er der måder at afbøde; men hvis disse er eksterne biblioteker... ikke det let.

Hvis du er afhængig af jarA og jarB (separate moduler), men de eksporterer begge abc.def.Util , du venter på dig en overraskelse. Der er dog måder at løse dette på. På en eller anden måde smertefuldt, men løseligt.

Alt i alt, siden vi migrerede til moduler (og stadig gør), er vores kode blevet meget renere. Og hvis din virksomhed er "kode-først" virksomhed, er det vigtigt. På den anden side har jeg været involveret i virksomheder, hvor dette blev set som "for dyrt", "ingen reel fordel" af seniorarkitekter.


Java tag