Akkor mondjuk Spring alapon tanuljak/próbálkozzak tovább?

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.

[ Szerkesztve ]

Meg vagyok győzve. Akkor ez lesz.

A lombok jó cucc én is szeretem, de magic bytekód generálás erősen ellenjavallott production környezetben. Pénzügyi szektorban még nem találkoztam olyan ügyféllel, akinél ne lett volna tiltólistán.

"Utóbbi még üzemeltetési szempontból is aggályos"

Ezt kifejtenéd?

“Yeah, well, you know, that’s just, like, your opinion, man.” — The Dude

Ha csak 1 számjegyet vársz, lekérdezheted a Character osztály statikus függvényével, hogy számjegy-e (isDigit).

Szerintem a legérdemesebb beszerezni valamelyik beginner Udemys Spring traininget. Általában nagyon szájbarágósak és a végletekig praktikusak. Ha szerencséd van, olyan helyed dolgozol, hogy van ingyen access. Ha nem, akkor érdemes kinézni valamelyik akciósat és rákölteni vagy 10-20 eurót. Szerintem ezerszer könnyebb megérteni egy ilyenből, mint könyvekből, vagy írott tutorialokból.

I am having fun staying poor.

Jelenleg egy ilyen Udemy-s anyagom van. Ez megfelelő lehet szerinted? Nekem jónak tűnik a content alapján.

Illetve találtam a YT-on magyar nyelvű anyagot is. A San Franciscoból jöttem csatornán Spring Boot ismeretek címmel.

A magyar nyelvűvel kezdeném, mert az angol lassabban megy kicsit sajnos (még). Gondolom nem gond, ha két külön helyről jön infó. Átfogóbb képet kapok. Igazából nem rohanok sehova csak veszett módon érdekel a Java és most lett egy kis időm.

Eddig PHP vonalon dolgoztam, kevéske OOP-vel sajnos a régi projectek miatt, mindenféle framework nélkül. A JAVA mellett állt rá az agyam is az OOP szemléletre. De ez egy másik történet ...

Egy metódus rekurzívan hívogatja saját magát. Hol tudom az exception (StackOverflow) elkapni?

Ez nem jó.

public void eat() {
try {
eat();
} catch (Exception e) {
System.out.println("SOF");
}
}

Gyors kérdés. Melyik build/dependency managert?

Maven vagy Gradle?

Előbbit már próbáltam, nagyon minimális ismereteim vannak róla, utóbbit még soha nem használtam.

Én a Gradle-t pártolom de kb. tökmind1. xml vs groovy.

"Ott szimatol a sarkadban vasfogait csattogtatva, minden egyes hétköznapod: kirúzsozott medvecsapda."

StackOverflowError, ahogy a neve is mutatja, nem exception, hanem Error -> Throwable.
A catchben StackOverflowErrort, Throwable-t vagy Errort próbálj elkapni.

[ Szerkesztve ]

Thank you to god for making me an atheist

Szerintem érdemes ismerni mindkettőt, de a maven-t mindenképp. Kezdőként elég az egyik is. A Gradle rugalmasabb, a néhanapján felmerülő cache problémákat szopás kiszűrni. A maven kevésbé rugalmas - pluginekkel persze lehet bármit - de régi motoros, szerintem minden problémára van megoldás (plugin) hozzá. Gradle esetében találkoztam olyannal, ami nincs vagy csak részben volt meg a maven-es megoldáshoz képest.

“Yeah, well, you know, that’s just, like, your opinion, man.” — The Dude

*Kotlin DSL

Ezt a tiltósdi dolgot nem annyira vágom miért kell... Voltam már olyan projektben, ahol az 1.5-ös fícsöröket tiltották, mindenki menekült, semmi értelme nem volt. 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. Amúgy is kényszermegoldás volt, mert a JCP board impotens nyúlbéla volt hozzá, az Oracle meg pénzt akart belőle kifacsarni, nem fejleszteni.

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. Szerintem a legszebben megfogalmazott Java config is nehezebben átlátható, mint akár az XML. Egyik megoldás sem jó tisztán, nekem leginkább az XML+annotáció az, ami leginkább kezelhető.

"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.

“Yeah, well, you know, that’s just, like, your opinion, man.” — The Dude

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.

Ha már így összejöttek itt a szakik egy kérdés.
Használom a docx4j projektet egyszerűbb docx doksik generálásához mintából. Projekt oldala: [link]

Ha valaki esetleg használja, meg tudná mondani, hogy az első doksi generálása miért olyan hosszú?
Látszólag megfagy az ezt használó projekt az indításától számított első variableReplace() hívásnál 5 mp-re, de újabb doksik generálása már pikk-pakk megy. Kínomban már inkább indításkor generálok valami kamu doksit.

Le az elipszilonos jével, éljen a "j" !!!

Csinálj előbb egy template docx-et. Úgy szerintem gyorsabb lesz. Nyisd meg és abba írkálj. Vagy próbáld meg az apache poi-t, ha a stack-be belefér.

[ Szerkesztve ]

MI 10T Pro 8/256 , Arsenal FC - Go Gunnarz...

Arra van-e valamifele library, ami valamilyen jsonban megadott filter/sort kriteriumokat kozvetlen Jpa criteria queryve tudna alakitani? Igazabol a formatum annyira nem is fontos, felolem lehet akar QueryParammal, vagy PathParammal. Irni tudnek, de ha van, akkor nem szeretnek ezzel foglalatoskodni. Viszont nem talalok ra hirtelen jo keresofeltetelt a guglihoz.

I am having fun staying poor.

Szia! Köszönöm a választ, POI-t használom az XLSX-ekhez, de nem találtam működő példát docx-hez. Nem tudnál egy linket dobni egy egyszerűbb docx kitöltésről POI-val?

Le az elipszilonos jével, éljen a "j" !!!

Na közben megszületett a tákolmány
Állandóan nyafogott a docx4j, hogy nincs konfig ezért az alapértelmezettet tölti be, úgyhogy ezt is megoldottam egy csapással:
public static void preInit(){
//preinit docx4j

// supress system.err
java.io.PrintStream _err = System.err;
try{
System.setErr(new java.io.PrintStream(new java.io.OutputStream() {
public void write(int b) {
}
}));
//preinit without file
WordprocessingMLPackage.load(new java.io.ByteArrayInputStream(new byte[0]));
}
catch(Exception e){}
//recover system.err
System.setErr(_err);
}

[ Szerkesztve ]

Le az elipszilonos jével, éljen a "j" !!!

Hétfőn tudok majd

MI 10T Pro 8/256 , Arsenal FC - Go Gunnarz...

Csak jobb lenne patkolás nélkül. Várom.

Le az elipszilonos jével, éljen a "j" !!!

Na mindegy, eddig müxeni látszik a B megoldás, csak próbáltam a 8.0-ásról 8.1.1-re frissíteni a docx4j-t, de elrontja a docx-et, szóközöket von egybe. Úgyhogy visszaálltam 8-ra.

Le az elipszilonos jével, éljen a "j" !!!

Sziasztok!

Valószínűleg elég triviális lesz a kérdésem

2 éve programozok, idén érettségiztem emelt informatikából (Java-ban), alapvetően értem az OOP lényegét, tisztában vagyok az alapokkal, viszont az osztályok közötti öröklődés hasznát nem igazán látom át.

Egy egyszerű példával:
Adott egy car osztály, benne egy String marka mező. Ennek a mezőnek adhatok akármilyen értéket. (Subaru, Citroen, Mazda...) Később ezen osztály objektumait pl. hozzáadhatom egy ArrayListhez amiben egy if(marka=="Mazda") feltétellel rögtön tudok kezdeni valamit.
Miért lenne jobb ha a car osztályt terjeszteném ki több al-osztályra?

Elképzelhető, hogy nagyon rossz a példám mert nem látom át az egész lényegét, gyakorlati alkalmazását.
Valaki fel tudna világosítani, esetleg kész gyakorlati példát mutatni?

[ Szerkesztve ]

"Life's simple: You make choices and you don't look back."

Sztem rosszul közelíted meg a dolgot képzeld el így

Van egy osztályod ami tárolja az autók fő tulajdonságait mint pl Le, fogyasztás stb, amit minden autóra el lehet sütni, ebből örökölnek a konkrét típusok, amiknek meg lesznek a fő osztály adattagjai, mint a Le meg a fogyasztás, de ehhez hozzá rakhat még mást, ami esetleg csak rá vonatkozik

Az egésznek az a lényege, hogy ha hasonló osztályaid vannak, akkor nem mindegyikben hozod létre ugyan azokat a változókat, hanem csinálsz egy ős osztályt, ami tartalmazza ezeket a közös tagokat és a többi csak örökli

+ ugyan ez igaz a függvényeire is, pl ha másodfokú egyenletet szeretnél kiszámolni, akkor ha már van egy osztályod ami össze ad két számot, akkor ezt se kell megírni megint csak használni

Nyilván ezek móricka példák, és semmit értelmét nem látod ezeknek, de egy nagy alkalmazásban majd igen jó jönnek ezek

[ Szerkesztve ]

Xbox One: bandymnc

Ebből sajnos úgy tűnik, hogy éppen nem érted az OOP lényegét, de majd idővel az is eljön.

Én az öröklésből elsőre a polimorfizmust emelném ki. Van például egy Alakzat osztályod. Ebben van egy teruletSzamitas metódus. Van két Alakzatod, Kor és Negyzet. Kor és Negyzet nyilván teljesen máshogy számítja ki a területét, más belső tényezők alapján. De mindkettőben közös, hogy rendelkeznek területtel, és neked ha van egy raklapnyi Alakzatod, egyszerűbb dolgod van, ha mindegyik objektum megmondja magáról, hogy az ő területe mennyi. Persze itt is megcsinálhatod, hogy valamilyen típus változóban elrakod az Alakzat típusát, és ez alapján döntöd el a területszámító függvényben, hogy mit kell tenni. De ez hosszú távon teljesen fenntarthatatlan lesz. Ugyanis ha hozzáadsz egy új Alakzatot, 99%, hogy nem fogod megkeresni az összes if-et, ami Alakzatokat kezel, s el fog romlani a programod. Míg ha a teruletSzamitas abstract metódus, vagy interface-ben van megadva, akkor amint létrehozol egy újfajta Alakzatot, kötelező lesz megadnod a teruletSzamitas fuggveny implementaciojat. Másik probléma: hogyan kezeled azt, hogy egy Kor átmérővel rendelkezik, de egy Negyzet pedig oldal hosszúsággal? Mondhatod, hogy van egy változód, ami vagy az egyik, vagy a másik dolgot reprezentálja. Viszont ha bevezetsz egy téglalapot, akkor már nem lesz elég egy oldal, kettő kell. Ilyenkor mit csinálsz? Ha az Alakzatokban csak az a közös, hogy van számítható területük, akkor nem kell ezzel foglalkoznod. Minden osztályod csak annyit fog magából megmutatni a külvilágnak, ami feltétlenül szükséges.

I am having fun staying poor.

Köszi mindkettőtöknek!

Interfészt és absztrakt osztályokat használtam már pár feladat során, pl. ezt az alakzatos példát is csináltam már absztrakt osztály kiterjesztésével.

A kérdésem inkább a sima osztályokra vonatkozott, hogy azok esetében mikor érdemes tovább bővíteni.

"Life's simple: You make choices and you don't look back."

Egy konkrét feladat kapcsán amint érdemes lesz a bővítés, azt azonnal észre fogod venni.

Aki tejszínhabot szeretne, az inkább verje ki a fejéből!

Ezt tanulmányozva talán kicsit közelebb kerülsz a válaszhoz.
Fent van a megoldása is egyébként.

Na belenyultam egy specko esetbe.
Elkepzeles: tobbfele matrixszamitasi (2dim, altalaban java-hoz kepest kezelheto meretu de sok szamitast igenylo) implementacio hasznalatanak lehetosege. Interface, utils osztaly stb. minden megvan, a factory alapbol rendszervaltozobol veszi az aktualisat, es ha nincs default-ozza, szoval egyszerre biztositott hogy egyfele lesz.
Minden popec, egyszer csak benyogi az egyik review-er, hogy ne hasznaljunk raw type-okat, egyaltalan, mert az antipattern, nem tud a fordito osztalytipust ellenorizni. Java 8. Fogta az interface eredeti kitalaloja, minden fugg mar szinte onmagatol is, de a vege csak az lett, hogy az en kodomban nemes egyszeruseggel a konkret tipust (egyelore egy van elfogadva, bar masik kettot megcsinaltunk) hard code-olta'k mint hibajavitas. Innentol ki van dobva az egesz flexibilitas, ami a lenyeg lett volna...
En siman azt mondanam, hogy a raw type kerulese altalaban nem jelenti azt, hogy - foleg hogy a kodhoz nem fognak egysegsugaruak hozzaferni a domain es a kodresz fontossaga miatt - benne hagynam azt a nem felreertheto raw type-ot, de gondoltam megkerdezem, van-e barmi lehetoseg amit kihagytunk.
Fontos dolog a review es a rossz mintak kerulese, de ez boven a lo tuloldalanak tunik.

? extends Akármi? Vagy nem értem...

"Ott szimatol a sarkadban vasfogait csattogtatva, minden egyes hétköznapod: kirúzsozott medvecsapda."

Mondjuk minél tipusosabb annál jobb.

"Ott szimatol a sarkadban vasfogait csattogtatva, minden egyes hétköznapod: kirúzsozott medvecsapda."

Nyilvan, de ha latnad mit csinaltak belole... annyit szeritnem nem er meg az egesz. Foleg karbantartas, rafejlesztes lesz igy sokkal attekinthetetlenebb. Es most volt standup, kiderult hogy "try to" szinten van hogy kiszedjek a bedrotozast... eh.

Valaki próbálta már a GraalVM-et?

mobal,

"Ott szimatol a sarkadban vasfogait csattogtatva, minden egyes hétköznapod: kirúzsozott medvecsapda."

A raw típus manapság csak a probléma kikerülése. Nyilván a full típusosság több tervezést igényel, de meg szokta érni.

MI 10T Pro 8/256 , Arsenal FC - Go Gunnarz...

Az a baj h legyinthetnek de az mar kiveri a biztositekot hogy irracionalis megoldast csinalnak. Atterveztek, full tipusos [eddig jo], de ehhez 'en' a szamolo rutin mondjam meg melyikkel akarom hasznalni [implnev.class]. Mert hogy csak igy lehet. Magyarul, atnezve az atalakitast, csak nem akarjak h naluk legyen default. Ez mar reg nem a tipusossagrol szol... Megmodositottam offline ugy [azaz lehetseges, szoval vegulis +1 nap alatt kiderult a valasz, h o"k erveltek rosszul -- bar tovabbra is randa, rosszabb mint volt, karbantarthatalanabb], hogy jojjon 'toluk' default, mi a velemenyuk - a vicc hogy azt meg egy darab if miatt [hogy jofej legyek es ne null-t adjak at ha a default-ot kerem] le-felesleges-bonyolitasozta. Ja ok Londonban ulnek csak en Mo-on...
Mind1, egyelore dokumentalom az egyet nem ertesemet, mar ha benne marad nalam az implementacio megadasa a calc-os osztalyban, aztan ha telik a pohar [mert kozben a manager fonoknek meg en vagyok lasu mig ok ezen ulnek] akkor aktivalom a linkedin-emet...
Viszont sokat javult a generic-ekrol a tudasom, eddig ahhoz hasonlitanam mint nyelvtudasnal a passziv szokincset, hat most beaktivaltak ;-)

Ha valakinek kellene DOCX "sablon" (változókkal ellátott DOCX doksi) kitöltése Apache POI-val (és StringUtils-szal), akkor itt az én módszerem.
Két-három StackOverFlow-os példát kicsit össze kellett gyúrni, hogy megtalálja a változókat és sortörést és formázást is jól kezeljen:
A lényeg, hogy a változónevek a docx-ben ${változónév} formában szerepeljenek, valamint a változók és a helyettesítő szövegek egy HashMap<String,String> objektumban vannak, ahol a key a változónév csupaszon, a value meg a helyettesítő érték.
Docx4j így kezelte, és nem akartam mindent újraírni.
Mindenesetre mind az IDE mind a java fellélegzett, hogy kiszedtem a Docx4j-t meg a függőségeit
private static void removeAllRuns(XWPFParagraph paragraph) {
int size = paragraph.getRuns().size();
for (int i = 0; i < size; i++) {
paragraph.removeRun(0);
}
}

private static void insertReplacementRuns(
XWPFParagraph paragraph, String replacedText,
String fontFamily, int fontSize)
{
String[] replacementTextSplitOnCarriageReturn = StringUtils.split(replacedText, "\n");
XWPFRun newRun = paragraph.insertNewRun(0);
newRun.setFontFamily(fontFamily);
newRun.setFontSize(fontSize);
String part = replacementTextSplitOnCarriageReturn[0];
newRun.setText(part,0);
for (int j = 1; j < replacementTextSplitOnCarriageReturn.length; j++) {
part = replacementTextSplitOnCarriageReturn[j];
newRun.addBreak();
newRun.setText(part);
}
}

public static void poiReplace(java.util.HashMap<String,String> hs, String in, String out) throws Exception
{
XWPFDocument doc = new XWPFDocument(new java.io.FileInputStream(in));
for (XWPFParagraph p : doc.getParagraphs()) {
String text = p.getText();
boolean change=false;
for ( String key : hs.keySet() ) {
if (text != null && text.contains("${"+key+"}")) {
text = text.replace("${"+key+"}", hs.get(key));
change=true;
System.out.println("\nx\n"+p.getText()+"\n"+key+"\n"+hs.get(key));
}
}

if(change){
List<XWPFRun> runs = p.getRuns();

if (runs != null) {
String ff=runs.get(0).getFontFamily();
int fs=runs.get(0).getFontSize();
removeAllRuns(p);
insertReplacementRuns(p,text,ff,fs);
}
}
}

for (XWPFTable tbl : doc.getTables()) {
for (XWPFTableRow row : tbl.getRows()) {
for (XWPFTableCell cell : row.getTableCells()) {
for (XWPFParagraph p : cell.getParagraphs()) {
String text = p.getText();

boolean change=false;
for ( String key : hs.keySet() ) {
if (text != null && text.contains("${"+key+"}")) {
text = text.replace("${"+key+"}", hs.get(key));
change=true;
}
}

if(change){
List<XWPFRun> runs = p.getRuns();

if (runs != null) {
String ff=runs.get(0).getFontFamily();
int fs=runs.get(0).getFontSize();
removeAllRuns(p);
insertReplacementRuns(p,text,ff,fs);
}
}
}
}
}
}
doc.write(new java.io.FileOutputStream(out));
doc.close();


}

A poiReplace függvényt kell hívni, a másik kettőt meg a poiReplace hívogatja.

[ Szerkesztve ]

Le az elipszilonos jével, éljen a "j" !!!

Tegnap picit még püföltem a kódon:
- kettévettem a poireplace függvényt,
- megcsináltam, hogy elvileg működjön fejléccel és lábléccel is, de ez nem lett alaposabban tesztelve
- néha írt hibaüzeneteket a Word, hogy a fájl meg van már nyitva, így bezártam az input és output állományt is a függvény végén
- kicsit sztrímesítettem, ha valakinek gondja lenne vele, távolítsa el a kódból elsőnek a .parallel() részeket:
private static void paragReplace(XWPFParagraph p,java.util.HashMap<String,String> hs){
String text = p.getText();

boolean change=false;
for ( String key : hs.keySet() ) {
if (text != null && text.contains("${"+key+"}")) {
text = text.replace("${"+key+"}", hs.get(key));
change=true;
}
}

if(change){
List<XWPFRun> runs = p.getRuns();

if (runs != null) {
String ff=runs.get(0).getFontFamily();
int fs=runs.get(0).getFontSize();
removeAllRuns(p);
insertReplacementRuns(p,text,ff,fs);
}
}
}

public static void poiReplace(java.util.HashMap<String,String> hs, String in, String out) throws Exception
{
//Bekezdések
java.io.FileInputStream ins=new java.io.FileInputStream(in);
XWPFDocument doc = new XWPFDocument(ins);
doc.getParagraphs().stream().parallel()
.forEach((p) -> {
paragReplace(p,hs);
}
);

//Táblázatok
doc.getTables().stream().parallel()
.forEach((tbl) -> {tbl.getRows().stream()
.forEach((row) -> {row.getTableCells().stream()
.forEach((cell) -> {cell.getParagraphs().stream()
.forEach((p) -> {
paragReplace(p,hs);
});
});
});
}
);

//Fejléc bekezdések és táblázatok
doc.getHeaderList().stream().forEach( (hdr) ->
{

hdr.getParagraphs().stream().parallel()
.forEach((p) -> {
paragReplace(p,hs);
});

hdr.getTables().stream().parallel()
.forEach((tbl) -> {tbl.getRows().stream()
.forEach((row) -> {row.getTableCells().stream()
.forEach((cell) -> {cell.getParagraphs().stream()
.forEach((p) -> {
paragReplace(p,hs);
});
});
});
});

}
);

//Lábléc bekezdések és táblázatok
doc.getFooterList().stream().forEach( (ftr) ->
{

ftr.getParagraphs().stream().parallel()
.forEach((p) -> {
paragReplace(p,hs);
});

ftr.getTables().stream().parallel()
.forEach((tbl) -> {tbl.getRows().stream()
.forEach((row) -> {row.getTableCells().stream()
.forEach((cell) -> {cell.getParagraphs().stream()
.forEach((p) -> {
paragReplace(p,hs);
});
});
});
});

}
);

doc.write(new java.io.FileOutputStream(out));
doc.close();
ins.close();
}

Le az elipszilonos jével, éljen a "j" !!!

Sziasztok.

Hogy lehet egyik osztály függvényéből átadni értéket egy másik osztály függvényének?

Jelen esetben:

Innen szeretném

public class Ital {
String nev;
double szazalek;
int ml;

public double getAlkoholGramm() {
return 0.8*ml*szazalek/100.0;
}
}

a getAlkoholGramm() függvény értékét átadni a veralkoholEzrelek() függvénynek:

public class Ember {
String nev;
int kilogramm;
double alkoholGramm;

public double veralkoholEzrelek() {
return alkoholGramm / kilogramm;
}
}

Ha a veralkoholEzrelek()-be beleírom, hogy alkoholGramm = Ital.getAlkoholGramm(); , akkor pedig ezt az üzenetet írja ki NetBeans: non-static method getAlkoholGramm() cannot be referenced from a static context

Tudnátok segíteni, hogy mi a gond és hogyan lehet megoldani? Előre is köszönöm!

[ Szerkesztve ]

Csak statikus metódust tudsz meghívni osztálynévvel (Ital.getAlkoholGramm()).
Példányosítani kell az Ital osztályt, és azon a példányon meghívni a getAlkoholGramm() metódust.

A gond ott kezdodik (bocs, nem bantas, hanem segitseg akar lenni), hogy mas az osztalydefinicio es mas a peldany.
Menjunk vissza, mi a cel? Lesznek ember-peldanyaid, meg ital-peldanyaid, es az a kerdes, hogy ha megissza egy emberpeldany az italt, mi a(z uj) veralkohol-szintje. Vagy az jobban illik az eddigi kododhoz, hogy ha meginna, mennyivel emelne a veralkohol-szintjet.

Szoval a lenyeg, hogy a fenti, nevezzuk inkabb verezrelekNoveles() fuggvenyednek kene egy Ital tipusu parametert definialni, es az adott ital-peldanytol elkerni a megfelelo adatot.

public double verezrelekNoveles(Ital egyital) {
return egyital.getAlkoholGramm() / kilogramm;
}

Az elnevezes most direkt ilyen "kilogo", hogy jobban lasd a kulonbseget, de nem kovetendo.

szerk. lassu vagyok... keresztposzt

[ Szerkesztve ]

Zsoxx és axioma: nagyon köszönöm mindkettőtöknek a segítséget! Tényleg a példányosítás hiánya volt a probléma. Utánaolvastam, mert erről még nem volt szó abban a tananyagban, amiből tanulom. Mondjuk így elég durva, hogy az elvárt feladatot csak a következő tananyagokban lévő tudásból kellene megoldani...

A main függvényben egyébként scanner-rel beolvasom az embereket és az italokat, és azok alapján számolgatok, majd iratok ki értékeket. Elnézést, hogy azt nem másoltam be.

Mégegyszer köszönöm, fantasztikusak vagytok!

Sziasztok!

Java programozást tanulni hol éri meg elkezdeni? Főiskolán és egyetemen kívül, munka mellett, teljesen az alapoktól, egészen mást tanultam és mással foglalkozom jelenleg.