Hirdetés
-
Az EU szerint kartelleztek az indítóakkumulátorok piacán
it Jövő héten lesznek a meghallgatások, de az EU szerint az autóipari indítóakkumulátorok gyártói kartelleztek, ezért kerülnek többe ezek az alkatrészek.
-
Féltucat régi Samsung kapott új One UI-t, köztük az A52s
ma A 6.1 olcsó, drága, ütésálló és közönségkedvenc készülékekre is megérkezett.
-
[SoP] Bemutatkozott a Dynasty Warriors Origins
gp Az új játék valamikor jövőre érkezik PC-re és konzolokra, további részleteket egyelőre még nem kaptunk.
Új hozzászólás Aktív témák
-
Lortech
addikt
Szerintem ha alapszinten programozni akarsz megtanulni akár java-ban, vagy akár másban, akkor először ne ui-ra, grafikára koncentrálj, mert nem ez a lényeg. Alkoss egy (állapottér) modellt fejben a játékodhoz, azonosítsd a különböző entitásokat, azok tulajdonságai, lehetséges állapotváltozásait, a játék logikáját. Vesd papírra, majd kezdj el gondolkodni rajta, hogyan lehet ezt Javába átültetni.
Ha kész a "motor", akkor érdemes a megjelenítésen elkezdeni dolgozni.Thank you to god for making me an atheist
-
Lortech
addikt
válasz axioma #10211 üzenetére
Röviden: tényleg nincs.
Csinálhatsz generikus interface-t:
public interface IF1<T extends IF1> {
void add(IF1<T> other);
}
public class Imp1 implements IF1<Imp1> {
@Override
public void add(IF1<Imp1> Other) {
}
}
public class Imp2 implements IF1<Imp2> {
@Override
public void add(IF1<Imp2> other) {
}
}
{
IF1 impraw = new Imp2();
IF1<Imp1> impl1 = new Imp1();
IF1<Imp2> impl2 = new Imp2();
impraw.add(impraw);
impraw.add(impl1);
impraw.add(impl2);
impl1.add(impl1);
impl1.add(impraw);
impl2.add(impl2);
impl2.add(impraw);
pass(impraw, impl1);
pass(impl1, impraw);
pass2(impl2, impl1);
}
private static void pass(IF1<Imp1> one, IF1 other) {
one.add(other);
other.add(one);
}
private static void pass2(IF1 one, IF1 other) {
one.add(other);
other.add(one);
}De ez jobbára csak bohóckodás, mert ha használni akarod, úgyis meg kell adnod a típus paramétert fordítás időben, hogy garantáltan *csak saját magával tudd átadni neki, vagy típus paraméter nélkül hagyod és unchecked leszel. Valamint raw IF1 (impraw-t) IF1 példányt oda vissza tudod passzolgatni futási és fordítási hiba nélkül.
[ Szerkesztve ]
Thank you to god for making me an atheist
-
Lortech
addikt
válasz Drizzt #10214 üzenetére
Ha azt csinálod, akkor azzal meg tudod akadályozni, hogy a "impl1.add(impraw);" illetve a "impl2.add(impraw);" leforduljon.
De azt is megakadályozza, hogy az
impl1.add(impl1);
impl2.add(impl2);
forduljon. De ja, igazából nem vagyunk sokkal beljebb az IF1<T> fordítási idejű típussal sem az Imp1 / Imp2 helyett. IF1<T> -vel mind a két imp típuskompatibilis - nem úgy a Matrixtype és Vectortype egymással -, ezért nem kapsz classcastexceptiont, ahogy a példádban viszont igen. Fordítás időben kéne tudni kiküszöbölni ezt az esetet, de a generikusok erre nem jók javában.[ Szerkesztve ]
Thank you to god for making me an atheist
-
Lortech
addikt
válasz XP NINJA #10298 üzenetére
Illetve ez így gép specifikus lesz?
Ez így java runtime specifikus lesz, a cacerts ahhoz tartozik, ez egy sima fájl a lib/security mappában.
Nálam letölti a fájlt a FileUtils.copyURLToFile. openjdk-8/11 cacertsben benne van a netlock ca certje. Nincs előttem windows éppen, oracle jre ezek szerint nem tartalmazza. Tuti ugyanazzal a java runtime-mal futtatod a programodat, mint aminek a cacertsébe beimportáltad a certet?[ Szerkesztve ]
Thank you to god for making me an atheist
-
-
Lortech
addikt
Nem írtam, hogy lenne baj a magyar könyvekkel, de általában minden témában vannak jobbak, nemzetközileg elismert szerzőktől. De főleg azért nem javaslom őket, mert ha valaki professzionálisan akar Javát tanulni, akkor jó, ha az angol terminológiát szokja meg. Legtöbb érdemi anyag, cikkek, szakmai fórumok, tananyagok angolul elérhetőek.
Thank you to god for making me an atheist
-
Lortech
addikt
Már mindegy elvileg, de azért tegyük tisztába, hogy nem a Derby használ JDBC-t, hanem a Java programod JDBC-t használva kapcsolódik a Derby adatbázishoz, már ha úgy írtad meg. A JPA (hibernate, eclipselink stb) leggyakoribb esetben egy relációs adatbázishoz való csatlakozáshoz a motorháztető alatt szintén JDBC-t használ, csak ezt magasabb absztrakció lévén elfedi előled.
Derby és JPA minden további nélkül összebarátkoztatható, egy ilyen egytáblás projekt összerakása egy tutorial alapján 10 percekben mérhető ([link]), legyen az akár standalone, vagy webes, konténeres megoldás.
Ha már telefonkönyv adatot tárolunk - nem konfigról volt szó, akkor nem látom értelmét (fájl alapon) JSON-nel vagy XML-lel szüttyögni, egy derby vagy akármilyen embedded sql/nosql megfelel a célra JPA-val kombinálva.szerk: Szvsz nincs baj az XML-lel sem, csak a megfelelő feladatra kell használni, ugyanúgy ahogy a JSON-t, Yaml, protobufot stb. Ilyen leegyszerűsítésnek, hogy XML-t úgy általában felejtsük el, szerintem nem sok értelme van, mint ahogy a 2000-es évek XML fetisizmusának se volt sok.
Ismerjük az eszközeinket és használjuk mindig a megfelelőt a megfelelő célra. [law of the instrument][ Szerkesztve ]
Thank you to god for making me an atheist
-
Lortech
addikt
Lehet force-olni egy windowsos ablak átméretezhetőségét (ResizeEnable util pl), de ettől önmagában még nem fog skálázódni a layout is, vagy igen, vagy nem, vagy jól vagy nem. Sokszor azért veszik fixre az ablak méretet, mert nem tudták rendesen megcsinálni a layout skálázódását.
De ez igazából nem javás kérdés.[ Szerkesztve ]
Thank you to god for making me an atheist
-
Lortech
addikt
Az emlitett reszletek (single thread pool) nelkul nem oldja meg a problemat, a felteves az volt, hogy van ket async task, tehat a szal inditas megvolt, a kolcsonos kizaras volt a kerdes, amit az executorservice onmagaban nem old meg.
Legegyszerubb fapad megoldas elhangzott, 2-3 threadnel teljesen ok egy kozos eroforrasra lockolni. Ha nem nagyon gyors lefutasuak a szalak, ebben az esetben jobb sorbarendezni a futtatasukat.Thank you to god for making me an atheist
-
Lortech
addikt
válasz #68216320 #10663 üzenetére
Kissé összemosódik a kép "nevének" (fájlnév / uri ? ) és magának a képnek a dinamikussága.
Nem világos az sem, hogy jön ide a header. Mindegy, kezdjük el és hátha kiderül, mire gondoltál./kepstream-re mappelsz egy servletet web.xml-ben vagy annotációval, request.getPathInfo-ból kiparse-olod a /kepstream utáni részt, megvan a path paramétered, amivel a képet azonosítod szerver oldalon.
Aztán a httpservletresponse outputstreamedre azt írsz dinamikusan, amit csak akarsz, akár on-the-fly generált képet, akár fájlból beolvasottat.
Plusz content-disposition, content-type headert nem árt kitölteni a céljaidnak megfelelően.[ Szerkesztve ]
Thank you to god for making me an atheist
-
Lortech
addikt
válasz #68216320 #10668 üzenetére
Jonak nez ki.
Annyi megjegyzes, hogy ImageIO es a beepitett javas kepfeldolgozo megoldasok nagyon eroforraspazarloak mind memoria, mind cpu szempontjabol, es a vegeredmeny minosege sem feltetlenul a legjobb, szoval ha komoly megoldas kell, akkor erdemes ezeket kikerulni es valami nativ celeszkozt hasznalni (Pl convert (imagemagick) parancs linuxon), majd a vegeredmenyt direktben kiirni az outputstreamre.Thank you to god for making me an atheist
-
Lortech
addikt
válasz axioma #10670 üzenetére
Nem látom át teljesen a problémádat, a streamektől nem egyértelmű, hogy mi történik. Egy működő példa talán segítene, hogy pontosan lehessen vizsgálni, mire gondoltál.
Nekem úgy tűnik, hogy a lambdák type inference limitációjába ütköztél.
Néhány link, ami indulásnak jó lehet, Brian Goetz kommentjeit érdemes olvasni:
[link]
[link]
[link]
Ha nagyon beleásod magad, javac-vel debug paraméterezéssel (utolsó link) ki lehet vsz. deríteni, hogy mi történik pontosan.[ Szerkesztve ]
Thank you to god for making me an atheist
-
Lortech
addikt
válasz #68216320 #10704 üzenetére
A best practice az olvasható kód. Ez persze bizonyos mértékig szubjektív.
Az olvashatóság lambda esetében még inkább az, erősen függ attól, hogy ki az olvasó. Ki mihez van szokva, kinek már állt rá jobban az agya. Már csak azért is, mert a lambda nem volt mindig alap nyelvi elem, és máig rengeteg kódbázis van, ami nem ilyen szemléletben íródott. Ha a csapat, aki a kódot írja és karbantartja, lambdát preferálja, akkor menjen a lambda, de azért ne ész nélkül.
Az adott problémától függ, hogy lambdával olvashatóbb lesz-e a kód, esetleg hatékonyabb vagy elegánsabb.[ Szerkesztve ]
Thank you to god for making me an atheist
-
Lortech
addikt
Ja. Ne keverjük már a kommentet egy javadoc (API) leírással. API leírás kell, ha például 3rd party használja az API-dat, aki nem tudja/akarja elolvasni a forrásodat, hogy megismerje a belső működését.
Olyan komment nem kell, ami a kódot szemeteli tele. Normális esetben a clean code egyúttal jól strukturált és jól olvasható kód is, tehát könnyű megérteni, így nem kell lépten nyomon teletűzdelni olyan kommentekkel, hogy "ez azért van, mert..", vagy "ezt ne változtasd meg mégha nagyon fura is, mert behány tőle a rendszer stb". Ugyanakkor ilyen kód nem létezik, és sokszor jól jön egy-egy magyarázó sor.[ Szerkesztve ]
Thank you to god for making me an atheist
-
Lortech
addikt
Na, ki tud nagyobbat mondani a fentieknél, szakmaiságban és megalapozottságban?
Viccet félretéve, egy okból váltanám le a mavenes projektjeinket gradle-re, ha olyan jellegű performancia problémánk lenne, amin a gradle segítene, és a probléma elérne olyan szintet, hogy megérné kidobni kb. 1 hónapot az egyébként jól működő, maintenance és problémamentes projektjeink migrációjára.
Thank you to god for making me an atheist
-
Lortech
addikt
Nagyon beakadt ez az XML. Így pár száz maven projekt és modul (és jópár plugin megírása) után azt tudom mondani, hogy az XML-t éreztem a legkevésbé problémásnak a mavenben. Csak a felszínt karcolgatod.
Én sem szeretem az XML-t különösebben, de nem érzem problémának, mert ha mavent is használ a projekt, ez nem jelenti azt, hogy egész nap ezt kell hegeszteni az egész fejlesztő cspatnak, nem olyan fajsúlyú kérdés, mint mondjuk egy frontend template, amiben egész nap hegeszt a fél társaság. A kezdeti project setup után kb. heti rendszerességű, hogy a buildünk változik, leginkább új dependency vagy verzió update miatt, ami teljesen automatikus és fájdalommentes változtatás, bármi érdemi változás ennél ritkább.
Most megnéztem egy kisebb-közepes projektet, van kb. 20 pom.xml össz. 150KB, aminek a 90+%-a copy paste-elt <dependency>, nincs mind module submodule viszonyban, tehát nem mindenhol van öröklődés, ezért a viszonylag nagy méret.Nem XML alapján döntünk, hogy maven vagy gradle.
Saját döntési szempontok:
-mi a probléma, amit meg akarunk oldani, mit kell tudnia a buildnek és mit akarunk azon kívül kezelni.
-van-e bármi nem szokványos körülmény, amiért testre kell szabni a buildet, kell-e egyedi plugint írni hozzá, ez a néhány fajsúlyosabb probléma viszi el az idő 90%-át általában.
-hol fog futni, hova és hogyan kell illeszkednie, mivel kell integrálódnia, gondolok itt meglévő projektekre, IDE-re, teszt keretrendszerre, futtatókörnyezetre, CI/CD-re, konténerekre stb.
-karbantarthatóság, mennyire egyszerű bővíteni, vagy teljesen átalakítani
-olvashatóság, átláthatóság: pl. a konvenciók, ha ismered őket, sokat segíthetnek egy projekt megismerésében egy új résztvevő számára, míg a flexibilitás, hogy kódot tudsz írni a buildben, nem mindig előny, ha a fejlesztő csapat tényleg elkezd nagy mennyiségű kódot beleütni a buildbe.
-várható fejlesztői élmény, pl. mennyire egyszerű vele belőni a fejlesztői környezetet, milyen a tooling támogatás
-megoldás erőforrás igénye (esetleges traininggel együtt)
egyszerű használni, mennyire gyors, kiszámítható és problémamentes
-csapat meglévő kompetenciája, tanulási görbe, community, dokumentáció
-megoldás várható performanciája, ha nagyobb a projekt és számít bármit
...
...
és valahol itt egy kilométerrel lentebb van az, hogy XML-e[ Szerkesztve ]
Thank you to god for making me an atheist
-
Lortech
addikt
válasz togvau #11442 üzenetére
Áh, mavenes a projekt, ott a bibi, használj gradle-t, az ezt is megoldja.
Nyilván pontos válaszhoz kéne egész pontos infó, hogy a TLS handshake melyik ponton döglik, pl. openssl s_client kimenet, de ágyúval verébre megoldás itt:
https://stackoverflow.com/a/45444355Thank you to god for making me an atheist
-
Lortech
addikt
válasz togvau #11708 üzenetére
Magától értetődően legegyszerűbb maga a session (HttpSession), ha tényleg van... Ugye ez nem egyértelmű RESTful API-nál és JWT authentikációnál, aminek statelessnek kéne lennie.
Komolyabb alkalmazásnál floodot még az alkalmazás előtt célszerű megfogni, api gatewayen, proxyn, load balanceren stb.[ Szerkesztve ]
Thank you to god for making me an atheist
-
Lortech
addikt
válasz togvau #11714 üzenetére
Egy spring alkalmazásban (is) a session életciklusa beállítás kérdése. Amit írsz, azt szerintem benézed, vagy spéci beállításod van (tehát nem szűz spring boot app ), nem ez a default működés.
Egy request feldolgozás viszonyában a session (id) alapvetően attól függ, hogy a böngésződ küldött-e a requestben session id-t (JSESSIONID cookie (default)) , és hogy mi a spring appod sessionCreationPolicy-je, ezektől függően fogja a Spring (újra)használni a kapott sessionid alapján a meglévő sessiont (az objektumot, nem az id-t) vagy újat gyártani vagy nem gyártani vagy teljesen ignorálni a sessiont (springen kívül továbbra is létrehozható session).a session.setAttribute-ban állított dolog pedig mindegyik globális, mindegy milyen böngészőről/kliensről van a beállító kérés, mindegyiknek ugyan az lesz a getattribute valami értéke amit az egyik legutoljára settelt
Ez nem így működik, pont az a session lényege, hogy egy session példányhoz és állapothoz (így a session attribútumaihoz) csak azok a kliensek férnek hozzá, amelyek azonos session id-val rendelkeznek.
Szerinted téged a spring session fixation védelme zavarhat meg, emiatt látsz különböző session id-kat és emiatt tűnik úgy, hogy a sessionök különbözőek (valójában ugyanazok a sessionök különböző session id-val), mégis ugyanazok az attribútumai.[ Szerkesztve ]
Thank you to god for making me an atheist
-
Lortech
addikt
válasz btraven #11795 üzenetére
Ez egy console application vagy gui? Ha gui van akkor értelemszerűen ne system.out-ot használj logolásra vagy irányítsd át azt egy loggerrel fájlba, vagy console appot generált a jpackege-dzsel --win-console argumentummal.
[ Szerkesztve ]
Thank you to god for making me an atheist
-
Lortech
addikt
válasz Ablakos #11899 üzenetére
Itt a gc egy példányszintű metódus (instance method), ami késői kötést (late/dynamic binding) használ, így a Counter futásidejű típusa határozza meg, hogy melyik gc() metódus implementáció hívódik meg (polimorfizmus). Ha SubCounter újradefiniálta (override) a gc()-t, akkor ha a list változód futás idejű típusa SubCounter, akkor az override-olt változat fog hívódni, nem tudod meghívni a Counter gc() metódusát azon a példányon keresztül.
(azért írtam zárójeleket, hogy jobban utána tudj nézni ezeknek a fogalmaknak)
[ Szerkesztve ]
Thank you to god for making me an atheist
Új hozzászólás Aktív témák
A topicot kiemeltem. Valaki nem akar egy nyitó hsz-t írni?:))
Állásajánlatok
Cég: Ozeki Kft.
Város: Debrecen
Cég: Promenade Publishing House Kft.
Város: Budapest