- Samsung Galaxy S26 Ultra - fontossági sorrend
- Samsung Galaxy A52s 5G - jó S-tehetség
- Vivo X200 Pro - a kétszázát!
- Okosóra és okoskiegészítő topik
- Rég várt frissítést kap az Android tárcsázója
- Poco F8 Ultra – forrónaci
- iPhone topik
- Xiaomi 17 Ultra - jó az optikája
- Apple Watch
- Nagy bemutatóra készül az Oppo
Új hozzászólás Aktív témák
-
Nem is biztos a komplex a megfelelő kifejezés, inkább olyanra kell gondolni, ami rendszerszintű feature lenne, ami nem igazán kivitelezhető natív megoldások nélkül. Szóval ha az egész megvalósítható egy böngészőn belül is, akkor sanszosan nem lesz gond. Persze a pontos képhez érdemes megnézni mit támogat a Flutter, mik a célok és az alapján meghozni a döntést. Amit írsz az nem tűnik problémásnak. Persze kis projektnek sem :-)
-
Akkor sanszosan a szokásos fizzbuzz/fibonacci jellegű feladatokra lehet számítani meg ilyen oldd meg iterációval/rekurzióval. Ha esetleg ennél több energiát fektetnének a dologba, akkor valami saját példa, amiből esetleg kiderül, hogy hogyan állsz hozzá egy feladathoz, hogyan gondolkodsz, ilyesmi.
Én annyit tanácsolok, hogy gondolkodj hangosan és ha a feladatnál értelmezhető, akkor kérj egy teszt esetet (bemenet-kimenet). És hajrá
-
-
protected static <T extends AbstractInvoiceEntity> T getInvoiceEntity(AbstractInvoiceEntity originalEntity, Class<T extends AbstractInvoiceEntity> newClass) {T newInvoice = newClass.newInstance();(...)return newInvoice;}
valami ilyesmi vagy átadsz egy factory-t, ami létrehozza a kívánt objektumot"Unexpected bound" a Class<T extends AbstractInvoiceEntity> newClass-re.
#11308 az már részletkérdés lenne
mindegyik 0 paraméteres, szóval elég lenne, de a fenti probléma miatt így se, úgy se jó 
-
protected static <T extends AbstractInvoiceEntity> T getInvoiceEntity(AbstractInvoiceEntity originalEntity, Class<T extends AbstractInvoiceEntity> newClass) {T newInvoice = newClass.newInstance();(...)return newInvoice;}
valami ilyesmi vagy átadsz egy factory-t, ami létrehozza a kívánt objektumot -
"ott sem volt jó egyik dolog sem az EAGER-t leszámítva, amit a google kidob erre a hibára"
aham, mint ez meg ez, amikben kifejezetten azt írják, hogy ne használj eager-t ilyen helyzetben (első 2 találat)
Vlad Mihalcea blogját amúgy tudom ajánlani, ha hibernate és/vagy jpa a témakör.
nem is akarok használni, de a példákban más megoldás nincs, lásd ott a fetch és mégse.
Az elméleletet tudom, meg azt is, hogy az jpa-nál ritkán stimmel a gyakorlattal, ahogy itt se.A gyors megoldás az lett, hogy a service-ben nyomok egy gettert a sub entitykre semmibe vezetett eredménnyel, és utána már jó lesz a servicen kívül is.
De inkább azt választottam, hogy a
@Fetch(value = FetchMode.SUBSELECT)-et átírtam FetchMode.JOIN-ra. Hogy ez most bug, vagy feature, nem tudom, mindenesetre logikát nem látok benne... úgyhogy a bug a valószínűbb.
Azt nem tudom mit csinál, nem is érdekel, ennek a rakás ürülék alkalmazásnak ez a legkisebb gondja
-
"Valami maven wrappert írt, hogy be kell rakni a projektbe, az benn is van."
docker-maven-plugin? hogy néz ki hozzá a konfig a pom.xml-ben?"Igen rákerestem, a java írja, hogy nem jó a jar."
ha rákeresel a hibaüzenetre és hozzácsapod, hogy docker, akkor láthatod, hogy másoknak is volt ilyen problémájuk, a legtöbb esetben az argumentum átadással volt a gond, ami miatt a
JAR_FILEváltozó értéke üres, így a copy nem fut le jól"Megnéztem az argumentumot, de nem találja, mivel a docker linux fájlrendszerében keresi, nem az igaziban."
wut?
-
Ok, azt hiszem értem mi a félreértés. Ezt írtad: "maradjon futva a junit tesztek lefutása után". Ebből én unit testre asszociáltam és erről is beszéltem.
Erősen kétlem, hogy támogatná bármilyen test framework alapból, hogy utána fusson tovább az alkalmazás, ami a tesztek futtatása miatt indult.
A springboot junit test az meg nem csal, hanem azt csinálja, amit "mondasz" neki. Hogyan hívod most a tesztekben a "rest szolgáltatásokat"? Itt egy baeldung a témakörben. Meg egy TestRestTemplate részletesebb.
-
-
Alapból nem kéne külön beállítani, ha tud kapcsolódni, akkor meg tudja határozni. Én első körben arra tippelnék, hogy a kapcsolat se épül fel vagy nincs a db létrehozva, akkor is jöhet ez a hiba. A két db amúgy különböző? Van-e mintakód? Próbáltad-e esetleg valami in-memory db-vel (pl. h2/hsql)?
(#10975) venic
Melyik porton futna? Ha 80-as, akkor a skype esetleg lehet a ludas. De valami hibaüzenet nem ártana -
Alapból nem kéne külön beállítani, ha tud kapcsolódni, akkor meg tudja határozni. Én első körben arra tippelnék, hogy a kapcsolat se épül fel vagy nincs a db létrehozva, akkor is jöhet ez a hiba. A két db amúgy különböző? Van-e mintakód? Próbáltad-e esetleg valami in-memory db-vel (pl. h2/hsql)?
(#10975) venic
Melyik porton futna? Ha 80-as, akkor a skype esetleg lehet a ludas. De valami hibaüzenet nem ártana -
Írnak többmindent is, de ez a válasz, ahol a generált kódot megnézte a válaszoló.
A String osztály java alatt immutable, azaz értékadás után az objektum értéke nem változtatható. E miatt a String összefűzés
String concat = "first" + " " + "last";
4 String objektum létrejöttét jelentené.Erre rakták bele java 8 óta a fordítóba, hogy ahol ilyen található, azt optimalizálja. A String összefűzéseket helyettesíti StringBuilder-rel, ezért nem fog létrejönni annyi String objektum.
Vannak még egyéb String-ekkel kapcsolatos optimalizációk, amiket a fordító/futtató környezet csinál/alkalmaz, pl. a válaszokban említett internal pool, ahol kvázi cache-elve vannak String objektum példányok, java 8-as updattel jött a G1 GC-be, hogy tud deduplikálni String-eket. Java 9-ben pedig jött egy olyan, hogy azokat a szövegeket, amiket lehet, ISO-8859-1/Latin-1 kódolással tárolja a JVM UTF-16 helyett (1 vs 2 byte/karakter).
>javap -c Test Compiled from "Test.java" public java.lang.String makinStrings(); Code: 0: ldc #5; //String Fred 2: astore_1 3: new #6; //class java/lang/StringBuilder 6: dup 7: invokespecial #7; //Method java/lang/StringBuilder."<init>":()V 10: aload_1 11: invokevirtual #8; //Method java/lang/StringBuilder.append: (Ljava/lang/String;)Ljava/lang/StringBuilder; 14: ldc #9; //String 47 16: invokevirtual #8; //Method java/lang/StringBuilder.append:(Ljava/lang/String;)Ljava/lang/StringBuilder; 19: invokevirtual #10; //Method java/lang/StringBuilder.toString:()Ljava/lang/String; 22: astore_1 23: aload_1 24: iconst_2 25: iconst_5 26: invokevirtual #11; //Method java/lang/String.substring:(II)Ljava/lang/String; 29: astore_1 30: aload_1 31: invokevirtual #12; //Method java/lang/String.toUpperCase:()Ljava/lang/String; 34: astore_1 35: aload_1 36: invokevirtual #13; //Method java/lang/String.toString:()Ljava/lang/String; 39: areturn
-
Titeket nem zavar ez a Clean Code tudathasadásos állapot?
Clean Code szabály: ne írjunk kommentet, főleg ne Javadocot.
Erre a 2017-ben megjelent Java9-ről szóló könyvben szerepel a hogyan írjunk metódust leírás:
9 sor metódus, 15 sor magyarázattal előtte mit csinál
-
"Az XML vs Java configgal kapcsolatban az a problémám, hogy a konfiguráció karbantartásához/módosításához kódolás kell, CI pipeline."
Ez a konfiguráció nem ugyanaz, mint az alkalmazáshoz tartozó akár környezetenként változó konfig, pl url-ek. Ha itt kell módosítani bármit - magyarul az alkalmazás context-je változik -, akkor újra kell buildelni az alkalmazást, függetlenül a konfiguráció típusától. Innentől ez nem üzemeltetési kérdés, hanem fejlesztés.
Az átláthatóság szubjektív dolog, láttam már 30-40 xml-ből felépülő Spring konfigot, ami nekem minden volt csak nem átlátható, viszont volt kolléga, aki azt preferálta. Azt hittem ez csak az ő fétise, de akkor vannak még mások is ezen a vonalon :-)
"Lombokot szerintem alapvetően pár olyan dologra érdemes használni, ami fordításkor generál le bojlerplét kódot. Ezen az alapon semmilyen nem Java JVM nyelvet nem lenne szabad használni."
Semmi köze a kettőnek egymáshoz, ne keverd a dolgokat. A lombok által generált kódban nem bíznak sokan, valamint java update esetében okozhat/okozott gondot. Van pár issue-juk is. Ettől függetlenül, ahol lehet én is preferálom a használatát, de ettől még megértem, ha máshogy dönt valaki.Lehet, hogy neked a kontextus neked nem konfiguráció, nekem még mindig az, kezdve a legpitiánerebb dolgokkal, amit változtatni kellene egy production környezetben adott esetben. De ez a jó, hogy különbözőek vagyunk. Amúgy nem fétis, talán észrevetted, hogy egy kombinált megoldást említettem. Szerintem a Java config a típus-fetisiszták fertője
Olvashatóság tekintetében valóban jobb lenne egy JSON vagy YAML context definíció, de amikor kódból maszatol valaki, az agyhalál.A generált kóddal kapcsolatban rettenetesen álszent a hozzáállás. A hibernate és spring által generált 60 tonnányi (cglib, asm, miegymás) kód ok, a lombok @Getter/@Setter nem, hagyjuk már. A kotlin által generált JVM kód megint ok, bár többszörösen megerőszakolja az egész rendszert, de a @NoArgsConstructor/@AllArgsConstructor az csúnyarossz... vicc. Meg lehet nézni, hogy mekkora buglistája van ezeknek a rendszereknek már csak a kódgenerálás okán is, de attól nem félünk
Egy @Builder/@Getter annotáció átláthatatlan az osztály elején, de a húszmillió sornyi extra kód nyilván karbantarthatóbb, ha valami változik... Szerintem az a veszélyes, hogy ezt valaki nem meri használni. Ugyanaz a probléma, mint amikor az 1.5-ös iterációk és enumok tartották rettegésben az említett projektet. -
-
A körkörös függőség tervezési hibának hangzik. Több függőségnél pedig facade vagy egyéb wrapper megoldások is játszhatnak. Ezt is mondhatjuk workaround-nak, de én még mindig úgy vagyok vele, hogy inkább lássam a konstruktornál mi a függősége egy osztálynak, semmint annotációkat nézegetni. Én spring-nél is jobban preferálom az explicit java config-ot, mintsem a package scan-t meg annotációkat (saját kódnál, nem lib-eknél). Ha van egy konkrét config, ami alapján látom, mi lesz a context, mi-mi alapján épül fel, az nekem mindig szimpatikusabb volt.
Használtam már XML és Java configot is, de egy jól megtervezett struktúra és lombok használata mellett nekem: annotáció > XML > Java config. Utóbbi még üzemeltetési szempontból is aggályos
A tervezési hibával kapcsolatban meg lehet, hogy igazad van, bár ezzel szerintem csak akkor lehet hatékonyan megküzdeni, ha zöldmezős cuccról van szó.
(#10501) PeachMan én mindenképpen javasolnám. Nem árt ha mögé látsz, de nem attól leszel jó (junior) fejlesztő, hogy látod a biteket suhanni.
-
DTO: data transfer object
ez lehet bármilyen két komponens közötti kommunikációban szereplőDAO: data access object
ez egy olyan objektum, amin keresztül adatokat érünk el/tudunk manipulálni, általában adatbázissal a túloldalon - az objektum elrejti a DB részleteketrepository:
a DAO-hoz hasonló pattern, inkább domain centrikusabb, az adat objektumokat entity-nek hívjuk ebben az esetben
A rétegek szervezése/szeparálása fontos dolog, nehéz elsőre ráérezni, fog kelleni hozzá némi tapasztalat. Annyit szerintem mindenképp jegyezz meg most, hogy nincs semmi kőbe vésve. Vannak ajánlások, de mindig az adott problémához keressük a megoldást, nem pedig valami "best practice-t" erőszakolunk rá mindenre.Amennyiben egy egyszerű crud a cél, akkor nem is feltétlen szükséges külön entity/dto/pojo-kat készíteni a különböző rétegekhez, mert fölöslegesen kéne transzformálgatni mindent többször is.
Ha a crud-nál tovább lépünk vagy más jellegű a probléma, akkor hasznos lehet különválasztani a rétegeket jobban.Amúgy olvass még kicsit utána funkcionális programozásnak, immutability-nek - java 8 óta java-ban is van hozzá támogatás - szerintem árnyalja majd a képet.
A Spring JavaEE vs sima java témakörben pedig én javaslom a keretrendszer használatát, ha máshoz nem is, de a dependency injection miatt mindenképpen.
Nagyon köszönöm az infokat.
Olvasok a témában. Sokat kell pótolnom, helyretennem. De ez van, meglesz majd.A Spring Boot használata például akkor erősen javasolt, ugye?
Igazság szerint azért akartam eredetileg csak tiszta JavaSE kódot, hogy az alapokkal tisztában legyek. Lássam azokat a feladatokat/megoldásokat amiket egy framework elfed.
Esetemben nem maga a project elkészítése, hanem a Java gyakorlása a cél.A terv első lépésként egy fapados user/account résszel egy webes view-al megszerkesztett crud-ot tudó felület. Valami termék készlet manager. Mondjuk a fentebb említett "car" készlet kezelése.
Csak amolyan tanulásként. -
Aethelstone
addikt
Egyrészt ez nem legál, másrészt semmi köze a java-hoz.
@(#10258) szbalogh
Nekem úgy tűnik, hogy a UI kirajzolása közben történik valami probléma, ami a kód ismerete nélkül elég sokminden lehet. Nem tudom melyik java verzióval fut jelenleg az alkalmazás, de szerintem próbáljátok meg régebbi java verzióval futtatni.Szerintem a régebbi Java verzió nem old meg semmit. Egyszerűen arról van szó, hogy hibás a programlogika. Ráadásul XP-n futtatják, nem sanszos, hogy mostanság Java verziót emeltek
-
"Mert az feltételezem, hogy nem windowsos docker a live.
Akkor inkább már VBox-ban ubuntu/debian és azon docker."Lehet én értem félre, amit írsz, de Windows-ra nincs natív docker. A Docker Toolbox és a Docker for Windows - bár ez próbál natívnak tűnni - is egy virtuális linuxon fut, szóval sok előnye nincs használni egy dedikált linux vm-et, hacsak az embernek nincs szüksége valami linux specifikus eszközre. A local környezet meg soha nem lesz olyan, mint a production, ehhez úgyis illik egy teszt környezet, ami minél jobban közelít a production-höz.
De persze a fejlesztő dolga mit használ.
-
A JavaEE egy specifikáció és API gyűjtemény, ami a Java Community Process alkalmazásával fejlődik. Ezekhez az API-khoz készülnek implementációk a specifikációk alapján. Erről egy kis összefoglaló.
A JavaEE technológiákra rengeteg alkalmazás épül és nagyon sok az érdekelt szereplő. A bejelentés után sok a felmerülő kérdés, így érdemes megvárni ki veszi át az Oracle szerepét, valamint lesznek-e változások a fejlesztési/elbírálási folyamatokban. Olvasd el még ezt a cikket a bejelentésről.
-
Aethelstone
addikt
Kollekciókhoz ezt nézd át, jól összefoglalja a Collections interface-ből származó interface-eket és azok implementációit.
"Ez alatt arra gondolsz, hogy elméletben tanuljam meg először, hogy melyik mit tud, ugye?"
Lényegében, igenSolid-ra találtam egy magyar összefoglalót érthető példákkal.
GRASP (General responsibility assignment software patterns)
Ezek meg beszédesek különösebb magyarázat nélkül is:
Don't Repeat Yourself (ne legyen kódismétlés)
Keep It Stupid Simple (legyen a kód olyan egyszerű, amennyire lehet)
You Ain't Gonna Need It (ne implementálj semmi olyan funkciót/logikát, amire nincs azonnal szükséged, később sanszosan változni fog az irány/struktúra/akármi és úgy is át kell írni)És ne feledkezzünk meg az OMBM-ről sem, mint a legfontosabb patternek egyike
-
Aethelstone
addikt
Egy metódus egy dolgot csináljon. A metódusok legyenek rövidek és legyen nekik minél beszédesebb nevük. Az hogy a YourConsultant osztályodon belül vannak egyéb private metódusok, amik segítenek jobban struktúrálni a logikát, nem jelenti azt, hogy változtatni kéne az interface-t.
A metódusok legyenek rövidek és legyen nekik minél beszédesebb nevük.
Ez a legritkább esetben szokott sikerülni
-
Aethelstone
addikt
A másik diák szerintem pont itt tette fel a kérdést.
-
Java 8 alatt van lehetőség metódus referenciát átadni. Akár az alábbihoz hasonlóan is elindulhatsz:
public class MethodRuntimeChecker {
public static void main(String[] args) {
QuickSorter sorter = new QuickSorter();
int[] array = getNumbers(10_000);
System.out.println(mesureRunTimeNano(sorter::sort, array) + " ns");
System.out.println(mesureRunTimeMilli(sorter::sort, array) + " ms");
}
public static long mesureRunTimeNano(Function<int[], int[]> intSorter, int[] toBeSorted) {
long start = System.nanoTime();
intSorter.apply(toBeSorted);
return System.nanoTime() - start;
}
public static long mesureRunTimeMilli(Function<int[], int[]> intSorter, int[] toBeSorted) {
long start = System.currentTimeMillis();
intSorter.apply(toBeSorted);
return System.currentTimeMillis() - start;
}
private static int[] getNumbers(int count) {
int[] numbers = new int[count];
Random random = new Random();
for (int i = 0; i < count; i++) {
numbers[i] = random.nextInt(count);
}
return numbers;
}
} -
Aethelstone
addikt
Arra céloztam igen
Meg hogy talán +1 akart lenni, hogy a 0-át, mint random számot kizárja. -
Ennyiből ugyan nem látszik mi a hiba, de szerintem az elérési utakkal lehet gond.
Csináltam egy kis minta projectet (maven project), két "kép cserélővel", az egyik a resource mappából szedi a képeket, a másik pedig külső könyvtárból.
Ha nincs jól megadva az elérési út a jelenség az általad is leírttal egyezik. Annyit még változtattam, hogy egységesen kezeljem a két változatot, hogy az ImageIcon-t java.net.URL paraméterrel példányosítom.
Nem tudom, hogy mit befolyásol mert csak 2-3 tanuljuk, de a layoutot null layout-ra állítottam, így rögtön működött.
-
Szerintem egy kicsit bővebben írd le, milyen játék, hol fut (böngésző/applet vagy asztali alkalmazás)? Mit írtál és milyen java console-ba (böngészőnél javascript console elérhető ugyebár)?
Amúgy a gondolatolvasó vénám azt mondatja, hogy Vezérlőpult (nézetnek kis ikonok) -> Java (vagy <java telepítési hely>/javacpl.exe) elindít ott security fül, lentebb állítod a szintet és ha valóban böngészős valamiről van szó, akkor hozzáadod a kivételekhez.
-
Aethelstone
addikt
Persze, mindenképpen. Nem tudom ki illetékes itt ez ügyben.
(#9043) emvy, (#9044) Aethelstone
A környezeti változók állítgatása nem éppen átlagfelhasználói tevékenység, hanem inkább üzemeltetési. Aki ilyen műveleteket akar csinálni, az szerintem nem árt, ha tisztában van a hogyanokkal, különben hamar pórul járhat. Ilyen szinten meg ne akarjon egy telepítő megcsinálni mindent. Vonatkozva jdk-ra és szerintem.Éles környezetben igen, de azért csúf lenne, ha egy Java vagy bármilyen fejlesztő nem lenne tisztában azzal, hogy miként működnek a környezeti változók és fejlesztői környezetben ezek állítgatása fejlesztői feladat. Vonatkoztatva nem csak java-ra
-
Azt nem tudom mi az oka, hogy nem rakják bele a path beállítást a jdk telepítőbe, de az lenne a tippem, hogy azért, mert fölösleges. Egy átlag felhasználónak nincs rá szüksége, egy fejlesztő meg úgy alakítja a saját környezetét, ahogy neki tetszik.
A java_home környezeti változó beállítása amúgy is egy kihagyható lépés, azt azért szokás beállítani, hogy ha frissíti az ember a jdk-t, ne kelljen a Path-ben bogarászni, hanem csak a környezeti változót kelljen átírni. IDE-kben, egyéb helyeken is lehet magára a java_home-ra referálni általában, így könnyebben karbantartható.
-
Mivel nem írod, hogy pontosan mivel is próbálkozol, a lépések nagyvonalakban:
- JDK telepít
- környezeti változónak beállítod a telepítés helyét:
- pl. JAVA_HOME: C:\Program Files\Java\jdk1.8.0_73
- felveszed a Path környezeti változóhoz a binárisokat:
- pl. %JAVA_HOME%\binProgram:
package cli;
public class Hello {
public static void main(String[] args) {
System.out.println("Hello dude");
}
}Parancssorban megnézed jó-e a java beállítás:
- java -version
> java version "1.8.0_101"
> Java(TM) SE Runtime Environment (build 1.8.0_101-b13)
> Java HotSpot(TM) 64-Bit Server VM (build 25.101-b13, mixed mode)Majd compile:
- javac cli\Hello.javaÉs végül a futtatás:
- java cli\Hello
> Hello dudeNem kéne ezt belerakni topic összefoglalóba?
Esetleg mellé tenni pár linket könyvekre / weboldalakra "hogy álljunk neki java-zni" címmel, illetve néhány IDE ajánlás, esetleg felsorolni pár manapság java téren népszerű technológiát (ideértve frameworkot, verziókezelőt, stb.), aminek legalább a nevét célszerű ismerni. Nagyjából úgyis ezek a kérdések szoktak felmerülni, ha nem valami konkrét kérdés van. -
Mivel nem írod, hogy pontosan mivel is próbálkozol, a lépések nagyvonalakban:
- JDK telepít
- környezeti változónak beállítod a telepítés helyét:
- pl. JAVA_HOME: C:\Program Files\Java\jdk1.8.0_73
- felveszed a Path környezeti változóhoz a binárisokat:
- pl. %JAVA_HOME%\binProgram:
package cli;
public class Hello {
public static void main(String[] args) {
System.out.println("Hello dude");
}
}Parancssorban megnézed jó-e a java beállítás:
- java -version
> java version "1.8.0_101"
> Java(TM) SE Runtime Environment (build 1.8.0_101-b13)
> Java HotSpot(TM) 64-Bit Server VM (build 25.101-b13, mixed mode)Majd compile:
- javac cli\Hello.javaÉs végül a futtatás:
- java cli\Hello
> Hello dude -
Mivel nem írod, hogy pontosan mivel is próbálkozol, a lépések nagyvonalakban:
- JDK telepít
- környezeti változónak beállítod a telepítés helyét:
- pl. JAVA_HOME: C:\Program Files\Java\jdk1.8.0_73
- felveszed a Path környezeti változóhoz a binárisokat:
- pl. %JAVA_HOME%\binProgram:
package cli;
public class Hello {
public static void main(String[] args) {
System.out.println("Hello dude");
}
}Parancssorban megnézed jó-e a java beállítás:
- java -version
> java version "1.8.0_101"
> Java(TM) SE Runtime Environment (build 1.8.0_101-b13)
> Java HotSpot(TM) 64-Bit Server VM (build 25.101-b13, mixed mode)Majd compile:
- javac cli\Hello.javaÉs végül a futtatás:
- java cli\Hello
> Hello dudeigen jdk telepités megvolt környezeti változokat átirtam ez idáig ok
java parancs és a java version parancs futása is zajlik
és itt a vége a dolgoknak ezért nem értem magát a programot nem futtatja
a javac parancsot nem érti: a rendszer a megadott parancsot nem ismeri fel se külső se belső rendszerként se futtatható programként.. ezt dobja... -
Lehet csk nekem, de nem egészen egyértelmű. Ez a helper osztály nekem egy service-nek hangzik, aminek van egy vendor dependency-je. A service-nek ezt a dependency-t illene konstruktorban átadni, mivel a funkcionalitásához nélkülözhetetlen (azaz ne is jöjjön létre példány anélkül, hogy működne). Nem tudom milyen az architektúra, de ha Java EE, akkor van context. A service valószínűleg valami singleton bean, amit újra lehet hasznosítani (figyelemmel a szálkezelésre, ha szükséges). Maga a vendor object is egy bean lesz ebben az esetben, amit szintén át lehet adni bárminek, ami igényli.
Ahogy leírtad az igaz, csak ez nem EE. Egy konzolos alkalmazás. Tehát elindul a program, letölti ezt az adatbázist, ha sikerült és nem szál el akkor pedig kipakolja belőle az infót. Ezt a helpert szeretném shared módon elérni - mert több objektum is használná.
Szerk.: most kvázi ez a vendor objektum be van ágyazva a helperembe. Ez lehet így nem lesz jó.
Szerk.: köszi, igazad lesz. Konstruktor.
-
Chesterfield
őstag
Kelleni fog még a jackson-datatype-jsr310 vagy a jackson-datatype-jdk8 modul is a LocalDate-hez.
A json mezőnévnek pedig nincs köze a konstruktor paraméter neveihez, hanem a getterek nevei alapján készülnek. Ha szeretnéd megtartani a getter nevét, viszont más nevet használnál a generált json-ben, akkor használhatod a @JsonProperty annotációt. Arra figyelj, hogy melyik jackson verziót használsz (1.x <-> 2.x).
pl.
public String getSomething()-> mezőnév: something@JsonProperty("somethingelse")-> mezőnév: somethingelse
public String getSomething()
Új hozzászólás Aktív témák
A topicot kiemeltem. Valaki nem akar egy nyitó hsz-t írni?:))
- exHWSW - Értünk mindenhez IS
- Forza sorozat (Horizon/Motorsport)
- Milyen autót vegyek?
- Álláskeresés, interjú, önéletrajz
- AMD K6-III, és minden ami RETRO - Oldschool tuning
- Fejhallgató erősítő és DAC topik
- A Linux megnégyszerezte magát a Steamen — a Microsoft ismét ígérget
- BestBuy topik
- Nintendo Switch 2
- Arc Raiders
- További aktív témák...
- 24 magos AMD Threadripper alapú munkára kiváló félgép, 128GB RAM-mal
- HP ZBook Fury 15 G7 i7-10850H 32GB 512GB SSD Quadro T2000 4GB FHD HUN bill, szép állapotban eladó
- Eladó MacBook Pro 16,1 2019 CTO
- új 0 km es garanciás lenovo loq rtx 5050 8gb
- Eladó teljesen újszerű karcmentes Samsung Galaxy Watch Ultra
- Keresünk Galaxy S23/S23+/S23 Ultra/S23 FE
- Intel Core i7-7700K 4.2GHz (8M Cache, up to 4.50 GHz) LGA1151 Processzor
- BESZÁMÍTÁS! Asus B760M i5 13400F 32GB DDR4 1TB SSD RTX 4060Ti 8GB Sharkoon RGB Slider FSP 650W
- Apple iPad 5. generáció (A1822) 128GB, asztroszürke
- HP EliteBook 745 G6 14" Ryzen 5 pro 3500U - 7 pro 3700U - 16GB RAM, SSD, jó akku, számla, 6 hó gar
Állásajánlatok
Cég: Laptopműhely Bt.
Város: Budapest