Megoldottam.

Annyi volt, hogy létrehoztam egy maven projectet és az src mappában létrehoztam egy package-et és az alá bemásoltam a meglévő java file-okat.
Amit pebirosozott, arra rágugliztam, hogy "maven dependency", és beraktam a pom xml-be.
Ezután letöltötte szépen a megfelelő dolgokat.
Majd szoptam egy sort a java verziókkal vagy 3 helyen, utána már ment is.

[ Szerkesztve ]

Eladó régi hardverek: https://hardverapro.hu/apro/sok_regi_kutyu/friss.html

Sziasztok!

Kérlek titeket, hogy segítsetek kiválasztani a legjobb java IDE-t. Eddig az eclipse illetve a netbeans amit ismerek. Mit tudtok még ajánlani?

köszönöm

IntelliJ Idea
A legjobb az összes közül, mára kb. de facto. A teljes változat fizetős, de van belőle community edition is, és a jó pár dologra az is megfelel.

Hazudnék, ha cáfolnám annak tagadását, hogy ez az ital nem nélkülözi a koffeinmentesség megnemlétének hiányát. Na most akkor van benne koffein, vagy nincs?!

+1 az intelliJ-re.

Eladó régi hardverek: https://hardverapro.hu/apro/sok_regi_kutyu/friss.html

Megszokás kérdése. Sokáig eclipse-et használtam, de kotlin miatt rá kellett szokni az ideara. Újabban vs code-ot is használok. Leginkább ez a két utóbbi talán a legjobb kompromisszum. Mindegyiknek vannak hülyeségei, de talán az idea és a vs code akadályoz a legkevésbé a munkában

Azért ez a de facto erős túlzás

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

Nyilván vi-ban is meg tudod csinálni ugyanazt, de minek szivasd magad?

Szerk.: hozzáteszem az idea ce egy zseniális húzás.

[ Szerkesztve ]

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

Eclipse maven integrációjával minden rendben van? Nekem rengeteg gondom volt vele. Aztán az IDEA-ban meg semmi.

Azért a vi és az Eclipse összehasonlítása erős túlzás ugyancsak Pont ugyanolyan hatékonysággal lehet Eclipse-ban dolgozni, mint Idea-ban.

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

Nekem Eclipse-ban nincs semmi gondom a maven integrációval. Btw, tényleg nagy projekteket toltunk végig, ahol is a csapat egy része Eclipse-ban, másik része Idea-ban tolta. Sosem volt gond egyik ággal sem.

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

Egyébként a Netbeans néha indokolatlanul magas processzorhasználatára született már valami megoldás?

Te lehet, én nem lennék rá képtelen. Ízlések és pofonok - nekem az Eclipse-szel való munka olyan lenne mintha a fogamat húznák.

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

Milyen "munka"?

[ Szerkesztve ]

Ez zseniális kép és módszer
A fordítottja is lenne esetleg?
Tudod amikor délután 4-kor odajön a projektvezető hogy "Te figyu lenne itt egy kéthónapos munka. Jó lenne ha kész lennél vele holnap reggelre."

Tpikus. Pénteken odabaxnak egy 20 napra becsült user story-t, hogy hétfő reggel UAT-ra kéne mennie Ott az egész hétvége felkiáltással

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

Nyilván. Ezért nem lehet kijelenteni, hogy az egyik jobb, mint a másik. Viszont pont emiatt kiváló flamewar alapanyag

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

Stíluson és Java IDE-n nem vitatkozunk!

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

Srácok, SQLite...
Hogy tudom a ResultSet-et foreach-elni? Jelenleg van rá egy while ciklusom, de C#-ból megszokásból mindenre foreach-et használok, szeretném itt is.

Ugyanez C#-ban sematikusan:
foreach (datarow in datatable)

Köszi!

[ Szerkesztve ]

A ResultSet java alatt nem Iterable ezért önmaga nem támogatja a foreach-et. Írhatsz rá saját Iterator-t vagy használhatod az apache dbutils ResultSetIterator-át.

Viszont csupán megszokás miatt abszolút fölösleges.

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

Nem kifejezetten Java kérdés....de nincs spec topik és lazán kapcsolódik...előre is elnézést. De minden komoly észrevétel jól jön.

Zöldmezős alkalmazás. DB tervezés. Van egy csomó kis szótár tábla. Ez tipikusan arra van, hogy a legördülőket majd innen töltjük fel. De lenne karbantartó is ezekre a táblákra... Én ezeket a táblákat külön vettem fel... Viszont nemrég jött egy másik ötlet egy kollégától.
Ő 1 táblát javasol lényegében az összes szótártáblában tárolt adatra.
TYPE - ID - NAME - SPEC1 - SPEC2 ...stb mezőkkel.
DOG - 1 - kutyi - szánhúz- null
CAT - 1 - cica - null - alszik

Itt lényegében a TYPE tartalmazná a típust és az ID-val együtt alkotná az elsődleges kulcsot...
Állítólag azért jó, mert nincs sok kis tábla... Én még annyit gondolok mögé, hogy kevesebb JOIN miatt gyors tud maradni a lekérdezés. De nekem zavarja a szemem, hogy eltérő típusú adatokat gyúrunk egybe. Az eltérő típusú objektumok miatt sok a kitöltetlen mező.
Ráadásul nagy kérdés, hogy amikor mondjuk egy Hibernate-et teszek fölé, akkor mennyire kavarja meg a domaint, hogy minden objektumnál lesz getSpec1() metódus miközben nincs is értelmezve az adott objektumon, mert azt a Spec2 tulajdonságával értelmezzük, és így azért lehetnek fura dolgok a kódban...

Mondja, Mr. Babbage, ha rossz adatokat ad meg a gépnek, akkor is jó válasz fog kijönni belőle?" Képtelen vagyok felfogni azt az értelmi zavart, ami valakit egy ilyen kérdés feltevésére késztethet. - by Charles Babbage

Itt ment valasz.

Egyetértek az előttem szólóval.
xkcd#1691

Sziasztok!

A szakmai segítségeteket szeretném kérni.
Szálkezelést szeretném valahogyan megérteni. Pontosan hogyan működnek a párhuzamos szálak.

Ezt szeretném megvalósítani:

Van egy server. Csatlakozik 2 vagy több kliens. Minden kliensnek elkezd küldeni a szerver számokat. A kliensek a számokat egy listába tárolják.

Példa kódokat szívesen veszek.

Köszönöm szépen

Sziasztok!
Spring Boot-ot használok, szeretnék két adatbázist is használni. Találtam rá példát:
[baeldung.com] [medium.com] .
Az a problémám, hogy a Spring Boot mindenképpen kéri, hogy állítsam be a dialect-t. (pl.: spring.jpa.database-platform=org.hibernate.dialect.Oracle10gDialect).
A medium.com-os példában szerepel, hogy a spring.jpa.database=default -el be lehet állítani a dialect-t, de nálam ezzel is "access to dialectresolutioninfo cannot be null when 'hibernate.dialect' not set" hiba jön elő. Viszont a fentebb leírt módon csak az egyik adatbázis dialect-jét tudom beállítani. Valakinek van valami ötlete?

[ Szerkesztve ]

Sziasztok!
Azt szeretném kérdezni, hogy Ti futottak-e már bele olyan problémába, hogy
http servlet fut asztali gépen, de nem fut laptopon.
3 laptopon is kipróbáltam.
Mi lehet a probléma?
Köszönöm előre is a válaszokat.

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

[ Szerkesztve ]

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

Köszi a választ.
A jsp-k azok futnak, nincs skype a gépemen
A 80-as porton futna
A két kód teljesen ugyanaz, a db is. Asztali gépen lett megírva a kód ahol teljesen jól működött, aztán meg a laptopon ezt a hibát adta.
XAMPP adatbázissal lett fejlesztve.

Hibaüzenet:

HTTP Status 500 – Internal Server Error

Type Exception Report

Message Error instantiating servlet class [login.LoginServlet]

Description The server encountered an unexpected condition that prevented it from fulfilling the request.

Exception

javax.servlet.ServletException: Error instantiating servlet class [login.LoginServlet] org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:541) org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:92) org.apache.catalina.valves.AbstractAccessLogValve.invoke(AbstractAccessLogValve.java:678) org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:343) org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:367) org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:65) org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:860) org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1598) org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49) java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1135) java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635) org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61) java.base/java.lang.Thread.run(Thread.java:844)

Root Cause

java.lang.RuntimeException: login.LoginServlet.<init>(LoginServlet.java:1) java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) java.base/jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) java.base/java.lang.reflect.Constructor.newInstance(Constructor.java:488) org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:541) org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:92) org.apache.catalina.valves.AbstractAccessLogValve.invoke(AbstractAccessLogValve.java:678) org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:343) org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:367) org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:65) org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:860) org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1598) org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49) java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1135) java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635) org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61) java.base/java.lang.Thread.run(Thread.java:844)

Note The full stack trace of the root cause is available in the server logs.
Apache Tomcat/9.0.30

[ Szerkesztve ]

Ugyanolyan verzioju a Java a gepeken? A Java module support elegge bekavart a reflectionnek, a hibauzeneted meg onnan jon. Elsore ugyanolyan jdk-t bugaznek.

I am having fun staying poor.

Két különböző db, létre vannak hozva (Oracle és Mssql). Alapból nem szeretném beállítani, két külön alkalmazásban kapcsolódok most a db-khez, ott nem is kell beállítani. Most hogy megpróbáltam egy alkalmazásból kapcsolódni mind a kettőhöz, jött elő a hiba, hogy be kéne állítani a dialect-et.

Nekem az egyik projektben egy ideig két Oracle 10g adatforrásom volt beállítva v7-es driverrel ahhoz hasonlóan, ahogy a második példádban írják le. Nem kellett dialektust használni, viszont mysql-es példák alapján mindig belefutok ebbe. Kezdem én is hülyének érezni magam

Most végül egyéb szempontok miatt úgy döntöttem, marad az adatbázis elérés két külön alkalmazással.

Köszi szépen.
Ugyanaz a Java verzió mind a két gépen. Én telepítettem fel mind a kettőre ugyanazzal a telepítővel, sőt még a Tomcat is ugyanaz. Átírtam a környezeti változókat is hogy lássa tomcat servlet-api filet, hátha az a baj, de nem oldotta meg.

spring JPA tesztelgetés_
Van egy junit teszt class, ahol az egyik tesztben létrehozok B entityt, amit egy A entitybe illesztek (onetoone, lazy, nem cascade kapcsolat), és save a repoval.
Aztán, ha ezt le akarom kérdezni findAll-al az A entityket amihez ugye tartozik a B entity is, akkor exception: no session.
Ha Cascade.ALL-on van akkor nincs hiba. Ahogy akkor sem, ha a lekérdezős metódus springes @Transactional.
Nem értem, hogy hova tűnik a session? Mi köze egy független select-nek tranzakciókhoz?

hitler, sztálin, micro usb

Amikor meghívod a lekérdezést a Repository metódusban, az elkér egy aktuális sessiont az EntityManager-től. Mivel lazy, azon a ponton nem oldja fel a hivatkozást, csak egy B proxy-t kap az A objektum. Amikor visszakapod A-t, a session már ment a lecsóba, és hiába hívod meg a gettert, a proxy már nem találja a session-t.
Na többek között erre is való a @Transactional, mert megmondja az EntityManager-nek, hogy hol kezdődik a session lifecycle. Ha nincs @Transactional, akkor a Repository metódusban kéne inícializálni a lazy relációkat.

Köszi, így érthető!
Manuálisan pedig entitymanager begintransactionnel lehet kezdeni, és flush-al lezárni?

Ezt viszont megint nem értem:
Ez volt: (működött az autowired)
@Repository
public interface PhotosRepo extends CrudRepository<Photo, Long> {

Ez lett:
@Repository
public abstract class PhotosRepo implements CrudRepository<Photo, Long> {
 @PersistenceContext
 private EntityManager em;
és mellé autowirednél:
.NoSuchBeanDefinitionException: No qualifying bean of type 'org..asd.db.repository.PhotosRepo' available: expected at least 1 bean which qualifies as autowire candidate.
Miért?

hitler, sztálin, micro usb

Spring boot példából:
repository.findByLastName("Bauer").forEach(bauer -> {
        log.info(bauer.toString());
      });
      // for (Customer bauer : repository.findByLastName("Bauer")) {
      //  log.info(bauer.toString());
      // }
Ez mi? Mindent 2 módon kell leírni ezentúl?
Az a legnehezebb hogy a programozó tudja mikor melyik módszert kell alkalmazni.

[ Szerkesztve ]

A fő példa a Java8-as Stream API, a kikommentezett rész pedig a hagyományos foreach, ha valaki nem akar (vagy Java 7 miatt nem tud) Stream API-t használni. Teljesen mindegy, melyiket használod, de a Stream API egyre elterjedtebb.

Hazudnék, ha cáfolnám annak tagadását, hogy ez az ital nem nélkülözi a koffeinmentesség megnemlétének hiányát. Na most akkor van benne koffein, vagy nincs?!

Namost ez egy elég hosszú téma, de röviden itt van egy példa, ami alapján tudsz hozzácsapni összetetteb dolgokat egy JPA repo-hoz. Ezt most csak egy text editorban dobtam össze, de a lényeg itt van. Van egy JPA repository-d, amit a framework majd implementál magának. Kell egy új interface, amiben a saját új metódusaid vannak. Ezt implementálod egy külön osztályban, valamint az új interface-t hozzácsapod a JPA repo-hoz az extends-ben. Innentől kezdve a PhotosRepo típust injektálod be mindenhová, mert a Spring ez alapján készít saját implementációt.

// létrehozol egy inteface-t a saját metódusaidnak
public interface PhotosRepoCustom {...}

// meghagyod a Spring Data repository-dat is, de hozzácsapod a saját interface-t is
@Repository
public interface PhotosRepo extends CrudRepository<Photo, Long>, PhotosRepoCustom {...}

// implementálod az új interface-t
public class PhotosRepositoryImpl implements PhotosRepoCustom {
    @PersistenceContext
    EntityManager em;
    public List<A> findAllCustom() {
        ....
    }
}

De a @Query annotációval használhatsz JOIN FETCH-et is egy query metódusban pl.:
@Repository
public interface PhotosRepo extends CrudRepository<Photo, Long> {
    ...
    @Query("SELECT a FROM A a INNER JOIN FETCH a.b b")
    public List<A> find();
}


[ Szerkesztve ]

Jaj de bonyolult, és csúnya. DeltaSpike-nál létre lehetett hozni interfacet extends EntityRepository, ahol csak @Query elég volt, ahol meg vegyesen kellett @query, és rendes metódus is, ott abstract class extends AbstractFullEntityRepository, aztán abstract metódusnál csak @query, nem abstractnál meg minden más.

Vannak bajok ezzel a spring datával, belefutottam ebbe is [link], csak sima long-al. Akkor jön elő, ha entity kapcsolat van 2 tábla között. Bár a kapcsolat DB szinten sima id-kkel van meg (bigint-ek), id alapján queryben mégse lehet szűrni, mert bár a query paraméter long, ami jó a biginthez, de spring data azt már entity-nek látja, amivel nem stimmel a long...
Akkor lehet választani, hogy vagy entity szintű kapcsolatok, vagy optimalizált lekérdezések... bár criteriaqueryvel nem próbáltam még.

hitler, sztálin, micro usb

Relatív, hogy mi a csúnya van egy interface a Data metódusoknak, meg egy custom implementációhoz, már ha kell egyáltalán.

Annyit azért nem árt fejben tartani, hogy a @Transactional alap. Nem hozunk létre tranzakciót kézzel, nem nyitunk db kapcsolatot. EntityManager-t a legvéső esetben szabad csak babrálni. Helyette érdemes a projekciókkal csinálni, amit lehet.

Most kellett
Linkeltem fent a bugot, ami valahol van... exception alapján spring data-ban van, de a workaround az egy criteriaquery, aminél nem jelentkezik ugyan az a bug:

@Query("select p.id from Photo p where p.user = ?1")
List<Long> findIdsByUserId(long id, boolean restricted);
Ez elhasal, a linkelthez hasonló: org.springframework.dao.InvalidDataAccessApiUsageException: Parameter value [34] did not match expected type... -al

Míg ugyan az a lekérdezés (kicsit még kibővítve), criteriaqueryvel, ugyan olyan metódusparaméterekkel, fut ahogy kell:
 public List<Long> findIdsByUserId(long id, boolean restricted) {
  var cb= em.getCriteriaBuilder();
  var ids=cb.createQuery(Long.class);
  var root=ids.from(Photo.class);
  ids.select(cb.construct(Long.class, root.get("id")));
  var pred= new ArrayList<Predicate>();
  pred.add(cb.equal(root.get("user"), id));
  if (!restricted) pred.add(cb.equal(root.get("restricted"), false));
  ids.where(pred.toArray(new Predicate[pred.size()]));
  return em.createQuery(ids).getResultList();
 }

fura. user= User entity kapcsolat, ami DB-ben egy BIGINT-et jelent user_id mezőben.

[ Szerkesztve ]

hitler, sztálin, micro usb

Igy ranezesre: ket fuggveny parametered van, mig a querynek csak 1. A @Queryben jpql expression van. Ha a user id-jere akarsz szurni, akkor: where p.user.userId =?

I am having fun staying poor.

Nézd nem mondom, hogy hibátlan a framework. Tele van apróbb hiányosságokkal, dokumentálatlan sok helyen, és a dobott hibák félrevezetőek.
De ha alaposan ismered, nem csupán a tutorialokat bújod, akkor fel fogod ismerni az alapvető összefüggéseket. A fenti lazy init probléma nem bug. Így működik a JPA, és ha a @Transactional használata problémát okoz, akkor nagyon gyorsan igyekezz elsajátítani, mert mint mondtam: alap.

Az iménti kódrészlettel van egy baromi nagy baj, nem is csupán a paraméterek száma miatt. A query, amit leírtál, egy JPQL SELECT. Annyiban különbözik az SQL-től, hogy objektumokat kezel (többek között). A p.user=?1 nem a táblában lévő oszlopra vonatkozik, hanem a Photo entitás user adattagjára, ami gondolom User típusú. A JPQL nem long értéket vár, hanem egy User objektumot. Helyesen így lenne:
select p.id from Photo p where p.user.id = ?1
feltételezve, hogy a user azonosítója az id nevű property, így lehetne Long paraméterrel hívni. A restricteddel az a baj, hogy feltételesen csapod a query-hez a criteria API-s implementációjával. Ilyet @Query annotációval nem lehet. Ott fixen meg kell adni a JPQL-t, amit nem módosíthatsz, magyarán:
select p.id from Photo p where p.user.id = ?1 and p.restricted=?2
lenne a végső JPQL (ha el nem néztem még valamit).

Ne ess abba a hibába, hogy a frameworkben keresed a bugot, miközben helytelenül kódolsz.

[ Szerkesztve ]

Kérdés:
- Addott egy osztály, aminek főleg beépített osztályok az adattagjai. Van benne 1-2 Set is, amiket nyilván addAll-lal szeretnék összeuniózni. Erre van-e valami jó library, ami generálhat ilyet? Szóval olyat, mint lent az incrementBy.

public class Example {

private Double value;
private Integer count;
private Set<String> stringSet;

public void incrementBy(Example other) {
value += other.value;
count += other.count;
stringSet.addAll(other.stringSet);
}
}


I am having fun staying poor.

Sziasztok!
A következő metódus csv file-ból olvas ki sorokat és objektummá alakítom (minden sor egy objektum):

private static void readData(File inputFile, Class type) {

try {
BufferedReader reader = new BufferedReader(new FileReader(inputFile));
String line;
// Reading first line..
while ((line = reader.readLine()) != null) {
String[] values = line.split(COMMA_DELIMITER);
if (type == Student.class) {
Student student = populateStudent(values);

if (students == null) {
students = new HashMap<Integer, Student>();
}
students.put(student.getStudentId(), student);

}
if (type == Subject.class) {
Mark mark = populateMark(values);
Subject subject = populateSubject(values);

if (subject.getMarks() == null) {
subject.setMarks(new ArrayList<Mark>());
}
students.get(mark.getStudentId()).getSubjects().put(subject.getSubjectId(), subject);
students.get(mark.getStudentId()).getSubjects().get(subject.getSubjectId()).getMarks().add(mark);

}
}
reader.close();

} catch (Exception e) {
e.printStackTrace();
}

}

Ez szeretném megoldani Stream-el:

private static void readData(Path inputFile, Class type) {
Student student;
Subject subject;
Mark mark;
try {
Stream<String> lines = Files.lines(inputFile);

List<List<String>> values = lines.map(line -> Arrays.asList(line.split(COMMA_DELIMITER))).collect(Collectors.toList());

if (type == Student.class) {
values.forEach(value -> student = populateStudent(value));

if (students == null) {
students = new HashMap<Integer, Student>();
}
students.put(student.getStudentId(), student);

}
if (type == Subject.class) {

values.forEach(value -> mark = populateMark(value));

if (subject.getMarks() == null) {
subject.setMarks(new ArrayList<Mark>());
}
students.get(mark.getStudentId()).getSubjects().put(subject.getSubjectId(), subject);
students.get(mark.getStudentId()).getSubjects().get(subject.getSubjectId()).getMarks().add(mark);

}
//}

} catch (Exception e) {
e.printStackTrace();
}

}

A forEach-ben (value -> student = populateStudent(value)) ezt a hibát kapom: ''Local variable student defined in an enclosing scope must be final or effectively final'

Tudja valaki, hogy lehet ezt megoldani?
Köszi!

[ Szerkesztve ]

A kis emberek más emberekről beszélnek, a középszerű emberek eseményekről, a nagy emberek pedig ötletekről beszélnek.

Én mindenhol a stream-et igyekszem használni.
Akkor van baj amikor kiderül hogy valami váratlan feltétel alapján abba kellene hagyni a stream-et valahol a mélyben.
Ilyenkor írhatom át for ciklusra.

Nem túl szép, de talán így:
values.forEach(value -> {
    Student studentInner = student;
    studentInner = populateStudent(value);
});
values.forEach(value -> {
    Mark markInner = mark;
    markInner = populateMark(value);
});
Esetleg még az elején a Student, Subject, Mark -t inicializálni;

[ Szerkesztve ]

Azért mindennek van határa!
A stream api és a lambdák nem azért léteznek, hogy másképp is lehessen for ciklust írni.

Azért használunk steam apit, mert komplexebb műveleteket is egységbe zár, kis túlzással atomi műveletként tudunk rá tekinteni. Más szóval nincs mellékhatása, ezért szeretjük. Nyilván, ha valaki nem jól használja, akkor lehet mellékhatása, és néhány esetben a fordító meg is fogja ezeket a hibákat, ahogy az látható. Sajnos más esetekben nem fogja meg. Ez szintén látható a legutolsó kinyilatkoztatásból.

Mellékhatásnak tekintünk minden olyan változást a futó program állapotában, ami a monadon (az az egység amin pl. a stream műveleteket alkalmazod) kívül történik. Ezt most jó hülyén fogalmaztam meg, remélem érthető. Tehát az, hogy például a foreach-en (mapen, filteren, stbn) belül egy akármilyen azon kívül eső változó értékét buzeráljuk, az mellékhatás. A lambda nem nyúlhat a saját scope-ján kívül. Elméletben. Gyakorlatban persze meg lehet tenni, csak igénytelen kódot eredményez. Mellékhatásokkal. Értelmét veszti az egész koncepció. Nem véletlenül ragaszkodik a fordító is ahhoz, hogy final dolgok legyenek a lambdában behivatkozva. Final, tehát nem változtatható. Egyszer értéket kap és úgy marad. Ha neked nem így struktúrált a kódod, akkor nem a lambda a jó megoldás. Vagy átstruktúrálod úgy, hogy jó legyen, ez már egyéni preferencia kérdése.

Légyszives ismerkedjetek meg a monad fogalmával, mielőtt ilyen gusztustalan bűnöket követtek el.
Addig meg légyszi maradjatok a for ciklusnál. Az tökéletesen fog működni. Mert annak nem célja a mellékhatások kiküszöbölése. Bár nem néztem át tüzetesen a problémás kódot, de a hiba környékén lévő szándék számomra azt mutatja, hogy ott a for ciklus a gyors megoldás.

Mondtam, hogy nem túl szép.
Egyébként teljesen igazad van.

Igen

[ Szerkesztve ]

A kis emberek más emberekről beszélnek, a középszerű emberek eseményekről, a nagy emberek pedig ötletekről beszélnek.