- Féltucat régi Samsung kapott új One UI-t, köztük az A52s
- Huawei Mate 50 Pro - blendemonda
- Mobil flották
- Milyen okostelefont vegyek?
- Samsung Galaxy A54 - türelemjáték
- Android szakmai topik
- Apple iPhone 14 Pro Max - sziget fesztivál
- Huawei Watch Fit 3 - zöldalma
- iPhone topik
- Samsung Galaxy S24 Ultra - ha működik, ne változtass!
Hirdetés
-
A hajlíthatók kedvence lehet a Dimensity 7300X 5G
ma Átcímkézés helyett csíkszélességet váltott a MediaTek, népszerű Motorolában debütálhat.
-
Összemoshatja a Google és a Magic Leap a valódi és a digitális világokat
it Együttműködésbe kezdett a Google és a Magic Leap nevű AR-startup.
-
Retro Kocka Kuckó 2024
lo Megint eltelt egy esztendő, ezért mögyünk retrokockulni Vásárhelyre! Gyere velünk gyereknapon!
Új hozzászólás Aktív témák
-
Lortech
addikt
válasz smallmer #9292 üzenetére
A lista nem tömb, ha a listából törölsz egy elemet, akkor csökken a lista hossza.
Tehát az utolsó for ciklusodban, ha jól látom i=4-nél már csak 3 elemed lesz a listában, és nem tudsz megcímezni a get(4) hívással 4-es indexű elemet. Ha minden elemet törölni akarsz, akkor MyList.clear(); Ha egyesével akarod, akkor mindig az elsőt a MyList.remove(0) hívással, vagy inkább iterator.remove.Thank you to god for making me an atheist
-
Lortech
addikt
válasz smallmer #9299 üzenetére
Az alapokat azért nem ártana elsajátítani mielőtt nekiállsz egy hello worldnél komolyabb feladatnak. Az értékadás pl. elég alap.
A kliensek.get(i) egy függvényhívás. Függvényhívás mint bal oldali kifejezés azt jelentené, hogy a hívás visszatérési értékének akarsz értéket adni. Ennek nincs értelme nyilván javában. Értéket adni változónak lehet. Egy lista adott elemét a set metódussal tudod lecserélni.
szerk: mindegy, már itt marad.[ Szerkesztve ]
Thank you to god for making me an atheist
-
Lortech
addikt
Thank you to god for making me an atheist
-
Lortech
addikt
A segítségkérésed itt offtopik. Nem csak a processing vs java miatt, hanem az "oldja már meg valaki helyettem a beadandómat" is.
Ez itt egy fórum, aminek az az értelme, hogy tudást, véleményt osszunk meg.
Te meg privátban kértél segítséged, konkrétumot nem írva, kvázi arra utalva hogy oldja meg helyetted valaki. Hülye lesz bárki minimum órákat beletenni és téged pátyolgatni, csak azért, hogy neked jó legyen.
Van álláshirdetés kategória. Ha azt akarod, hogy csinálja meg valaki helyetted, akkor tedd fel oda a hirdetésed.
Az meg, hogy neked áll feljebb, szánalmas. Magyar ugar? Tanulj, olvass el egy könyvet esetleg, ne másoktól várd a megoldást.
Amúgy meg levelező szakon alapvetés, hogy nem fogják neked szájbarágósan leadni az összes szükséges tudást, azért levelező. Azt feltételezi, hogy a hiányzó részt te rakod mellé. Lehet, hogy tájékozódni kéne mielőtt minden szar, csak a szegény diák nem, akinek dolgoznia kell a tudásért.[ Szerkesztve ]
Thank you to god for making me an atheist
-
Lortech
addikt
válasz #74220800 #9392 üzenetére
Kell nekik egy közös ős, interface vagy base class, pl.
public interface Queue<E> {...}
aztán
public class QueueArray<E> implements Queue<E> {}
végül
public static <E> long counter(Queue<E> c, int r) {Persze nem írtad, hogy néz ki az általad kreált két class és hol lenne ez a metódus, illetve nem tudni pontosan mit akarsz ezzel, de gyanús, hogy érdemesebb lenne eleve az interface-be vagy base-be tenni ezt a countert, példány szinten.
[ Szerkesztve ]
Thank you to god for making me an atheist
-
Lortech
addikt
válasz Cathfaern #9407 üzenetére
Már linkelték a nem pollozós, eseményalapú megoldást. Ez ha lehetséges, akkor az OS funkcióját veszi igénybe, amely értesíti a változásról, amikor az történik.
A pollozás általában kerülendő, ha van más megoldás, és itt van. Nem is biztos, hogy bármennyire is megoldás a pollozás, az eredeti igényben szerepelt az azonnaliság. Továbbá nem biztos, hogy értesülsz egyáltalán egy változásról, pl. létrehozás és rögtön utána törlés esetén, ha az két poll közé esik. Ez vagy releváns az adott probléma szempontjából, vagy nem. De egy nagyobbacska (több ezer elemet tartalmazó) mappa is meg tudja nehezíteni az ilyen naiv megoldások működését, ha folyamatosan pollozni kell.Thank you to god for making me an atheist
-
Lortech
addikt
válasz sztanozs #9452 üzenetére
Normális helyen nem szakbarbár fejlesztők vannak, hanem intelligens emberek, akik a fejlesztésen túl egyéb
kapcsolódó területeket is képesek megismerni, átlátni a szükséges mértékig.Business analyst semmiképp sem csinál technikai specifikációt az üzleti igényből. Üzleti igényből készíthet pl. funkcionális specifikációt, user storyt vagy bármit, ami már közelebb áll ahhoz, ami közös alapot képezhet a fejlesztőkkel. De egyáltalán nem szokatlan normálisan helyen sem, hogy egy fejlesztő csapat dolgozza fel az üzleti igényt és talál ki megoldást rájuk, hiszen a szoftverekhez sokkal jobban ért mint az üzlet. Pl. az üzlet nem fogja neked megmondani, hogy milyen egy modern ergonomikus, jól használható webes felület.
Persze az értelmes vitát úgy kéne kezdeni, hogy ki mit ért technikai specifikáció alatt, üzleti elemző alatt, üzleti igény alatt, mert ezek cégenként, területenként mást és mást jelenthetnek.Thank you to god for making me an atheist
-
Lortech
addikt
Egyszer már kérdezted ezt. "Hagyományos értelemben" vett többszörös öröklődés nincs, ha pl. a C++-szal összevetésben vizsgáljuk a kérdést. Ha egy tesztben látod ezt a kérdést, akkor a tesztíró fejével kellene gondolkodni, mert nem biztos, hogy a hosszú válaszra kíváncsi. DE a nincstől bonyolultabb a téma.
Az interface, ahogy emvy anno rámutatott, gyakorlatilag egy abstract class csak publikus metódusok body nélkül (+final static mezők és static metódusok implementációval). Többszörös öröklődés van Javában a saját terminológiája szerint, viszont megkülönbözteti az állapot (ilyen nincs Javában, az interface esetleges statikus mezőit nem tekinti annak, hiszen osztály szintűek), implementáció (default interface Java 8-tól, +esetleg static interface method, szintén Java 8-tól) és típus (interface) szerinti többszörös öröklődést.Thank you to god for making me an atheist
-
Lortech
addikt
válasz Aethelstone #9532 üzenetére
Mitől lenne temető? Ennyi erővel az iparág 90%-ára rá lehet mondani, hogy temető. Pl a Javára is úgy általában.
Ha most azt mondta volna az Ora, hogy Java EE 8 volt az utolsó, és beszántja a francba, akkor is alaphangon egy évtized mire tényleg kikopik.[ Szerkesztve ]
Thank you to god for making me an atheist
-
Lortech
addikt
válasz Aethelstone #9545 üzenetére
Spring fanboykodáson felülemelkedve amúgy érdekes vita lehetne - bár nem valószínű - , ha írnál valami releváns szakmait is azon kívül, hogy gyűlölöd a Java EE-t. Nem téríteni szeretnék, nekem se a Spring, se a Java EE nem a drágaszágom.
JSF ami zavar? Mást igazából nehéz elképzelnem, hogy mitől viseltetsz ekkora ellenszenvvel Java EE felé. Van megalapozott szakmai alapja vagy csak valami berögződés? Netán előző életedben EJB 1.1-et kellett használnod glassfish 1.0-n és azóta is rémálmokat okoz?
Elmúlt 4 évben többségében architektként 10+ Java EE projektem volt , de több Springes is, sőt most van egy OSGi leváltás is, volt zöldmezős, brownfield, meg totál legacy is. Sosem éreztem, hogy Spring az húde, Java EE meg blee.
Amikor tech stacket mérlegelünk architekt boardon, akkor általában sokadik szempont, hogy a Spring jellegéből fakadóan néhány lépéssel Java EE előtt jár.
GWT-t használsz meg Vaadint, közben írod, hogy IT-ban az évek az örökkévalóságot jelentik, holott ezek sem éppen jövőbe mutató technológiák finoman szólva és a trendek nem efelé mutatnak. Hogy van ez?Thank you to god for making me an atheist
-
Lortech
addikt
-
Lortech
addikt
válasz Aethelstone #9552 üzenetére
Bár nem rólam van szó, de ha már ... Igen, abszolút kódolok és reviewzok. Nem ilyen enterprise architect vagyok aki meetingekre jár és ott okoskodik. De, elég részletesen bele tudok merülni a technológiákba igen, hiszen ez a munkám, hogy meghatározzam az irányokat. Azért felelek, hogy jó döntéseket hozzak és jó irányba tereljem a projektet és csapatot, sőt a cég stratégiáját.
Dev környezetet, infrát,, db-t, CI-t, fejlesztői teszt alap struktúráit, integrációt, az alap framewörk megoldások elsőprő többségét, a fejlesztési folyamatot, a branchelési stratégiát meg még ki tudja mit én rakom össze. Csapattagok többnyire feature-t fejlesztenek.Írtál pár dolgot, mi az, ami miatt Spring, de semmit arról, hogy mi az, ami miatt nem Java EE.
JSF-hez hozzá sem nyúltam pár éve, előtte sem saját elhatározásból.
Java EE nem azt jelenti, hogy akkor JSF-et kötelező használni webre. Eleve nem csak webalkalmazás létezik, másrészt meg hülye lennék JSF-et választani, sőt bármilyen Java alapú webes frameworköt.
Nem volt "JSF vs gwt/vaadin", csak a te fejedben, Már csak azért sem, mert Java EE és gwt / vaadin semennyire sem zárja ki egymást. A JSF-fel csak tippeltem, hogy az biztos nem szíved csücske. Nekem se, de a Vaadint is hasonló baromkodásnak tartom.Alkalmazás-szerver vs Servlet Container. Szerintem erről ne nyissunk vitát.
Hát a semmivel nem tudok vitatkozni.Spring Data - Deltaspike, két saját projekten eddig bevált.
Spring Boot - ezzel mit szeretnél? Ezért használjon valaki Springet? Enélkül nem élet az élet? Csak így lehet?
Spring Rest - egy REST API az valami olyasmi, amire csak a Spring lenne képes 2017-ben? Lehet, hogy csak álmodtam, hogy ma is vagy 5db REST API-t implementáltam A-Z-ig (wildfly / resteasy).Satöbbi. Igen, rühellem az EE-t. Pont. Befejeztem.
El se kezdted, de oké, nem is számítottam többre.[ Szerkesztve ]
Thank you to god for making me an atheist
-
Lortech
addikt
Vagy TomEE, ha már...
mobal: egyszerűnek egyszerű, de csak egy servlet konténer, így nem alternatívája egy Java EE alkalmazásszervernek.
Amúgy a wildfly is tök egyszerű, alapból is, de elég jól testre is szabható, moduláris.
Productionben pedig leginkább ugyanazon kell futni, mint fejleszteni (persze lehet egy lightosabb profilon), különben tökönlövöd magad, Java EE kompatibilitás ide vagy oda.[ Szerkesztve ]
Thank you to god for making me an atheist
-
Lortech
addikt
A maven nem bloatware, a Javás világ jelentős része használja, nem azért, hogy szívassa magát, hanem hogy megkönnyítse vele a saját életét.
Az elkészült artifactok méretét nem befolyásolja érdemben (opcionális maven leírókat leszámítva), hogy mavent használsz, ellenben 2 perc alatt lehet egy működő webalkalmazás vázad egy megfelelő archetípusból generálva, ami azonnal telepíthető, war/ear release-t készít. Sőt 1 perc bekonfigurálni egy maven plugint, ami deployol is neked a wildflyra. Csak érteni kell hozzá.
De a te kézzel összevadászott librarys gányolásod biztos gyorsabb, hibamentesebb, profibb lesz.Thank you to god for making me an atheist
-
Lortech
addikt
Húzd be a wildfly jsf függőséget (wildfly 11.0.0 verziót feltételezve):
<dependency>
<groupId>org.wildfly</groupId>
<artifactId>wildfly-jsf</artifactId>
<version>11.0.0.Final</version>
</dependency>Vagy telepíts jboss tools az eclipse-edbe, és add hozzá a runtime-ot.
[ Szerkesztve ]
Thank you to god for making me an atheist
-
Lortech
addikt
Kézzel úgy tudtad feloldani helyesen a jsf-et, hogy a wildfly-odban lévő verziót (az appszerverben lévő verzióval pontosan megegyező) adtad hozzá, bármely más jsf lib hozzáadása lehet, hogy elfedi a hibaüzenetet, de problémát okozhat (és semmiképp se csomagold bele az elkészült artifactodba függőségként)
Hibernate a jpa implementáció wildflyban. Provider helyére: org.hibernate.ejb.HibernatePersistence kell.
A Wildfly szervereden definiálsz egy datasource-ot (standalone/domain.xml-ben kézzel , vagy jboss-cli-ben vagy webes admin konzolon), majd a persistence.xml-ben (ear-ban META-INF könyvtárba, war-ban WEB-INF/classes/META-INF könyvtárba) beállítod a datasource-ot.
<persistence xmlns="http://xmlns.jcp.org/xml/ns/persistence"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/persistence
http://xmlns.jcp.org/xml/ns/persistence/persistence_2_1.xsd"
version="2.1">
<persistence-unit name="mysqlpu" transaction-type="JTA">
<provider>org.hibernate.ejb.HibernatePersistence</provider>
<jta-data-source>java:jboss/datasources/mysqlds</jta-data-source>
<properties>
<property name="hibernate.dialect" value="org.hibernate.dialect.MySQLDialect"/>
</properties>
</persistence-unit>
</persistence>Ezután a managed beanekből már tudod injektálni az em-et:
@PersistenceContext(unitName = "mysqlpu")
protected EntityManager em;[ Szerkesztve ]
Thank you to god for making me an atheist
-
Lortech
addikt
Wildfly picketboxot használ jaasra, van olyan login module, hogy
DatabaseServerLoginModule.
Meg lehet adni neki datasource-ot paraméterként és jdbc-vel hozzáfog férni a db-dhez. Nem tudom, friss-e a leírás, de bele lehet nézni a login module forrásába.[ Szerkesztve ]
Thank you to god for making me an atheist
-
Lortech
addikt
Na ez az az irány, amit nem kéne erőltetni.
Javaslom, szervezd EJB-be az üzleti logikádat és az adathozzáférést, és azt injektáld a JSF managed beanbe. Mert az nem arra való, hogy direktben JPA-zz és tranzakciót kezelj benne.
AZ EJB-be pedig injektáld az entitymanageredet pl. az általam fentebb írd módon. Így nem kell foglalkoznod az entitymanager létrehozásával, életciklusával (pl. hogy többször létrehozod a factory-t, mint ahogy tetted).
BalusC tutorialjait, megoldásait érdemes olvasni, ő jó forrása a JSF-fel kapcsolatos megoldásoknak: [link]JAAS-hoz: a login-config.xml az jboss szerinti leíró, wildfly-on máshogy néz ki.
wildfly login module pl (standalone.xml vagy domain.xml megfelelő profiljában):<security-domain name="xysecdomain">
<authentication>
<login-module code="org.jboss.security.auth.spi.DatabaseServerLoginModule" flag="required">
<module-option name="dsJndiName" value="ds jdni név"/>
... többi opció ...
</login-module>
</authentication>
</security-domain>De mindez megtehető webes admin konzolból is.
Aztán jboss-web.xml-ben kell egy <security-domain>xysecdomain</security-domain> hivatkozás, ami a webalkalmazásodat összekapcsolja a security domainnel wildfly-ban.selectItem vs enum passz, szerencsére már rég JSF-eztem.
[ Szerkesztve ]
Thank you to god for making me an atheist
-
Lortech
addikt
Valószínűleg rossz az entity-db mappinged, de ez abból amit írtál, nem látszik.
Logolás: org.hibernate (vagy specifikusabb) kategóriára fel kell venni egy loggert és hozzá egy handlert:
[link]
Jboss logging teljesen oké, nem kell log4j vagy egyéb implementáció.[ Szerkesztve ]
Thank you to god for making me an atheist
-
Lortech
addikt
Azt értettem alatta, hogy az entitásban/db-ben a probléma mezőt/oszlopot nem jól definiáltad.
Pl. nem jó oszlopnevet adtál meg.
Detached entity passed to persistnek számos oka lehet. Kézzel állítasz be kulcs mezőket mentés előtt? Másodjára persisttel már nem fog menni, mert már létezik adott kulcsú mező, viszont az entity detached állapotban van, mivel még a persistence contextedbe nem töltődött be (pl. merge-dzsel tudod manageddé tenni). Látatlanban okosabbat nem tudok mondani.[ Szerkesztve ]
Thank you to god for making me an atheist
-
Lortech
addikt
Nem definiáltál az entitásaidba relációkat, legalábbis nem látszik. Anélkül nem nagyon fog menni és FK be fog utagni, meg nyilván generátor se fog tudni jó db sémát generálni így. Ajánlott olvasmány: JPA relációk, de úgy általában JPA.
EntityManager em= getFactory().createEntityManager();
em.getTransaction().begin();
Event evt= new Event(new Date(),em.merge(getGod()),event, success);
em.persist(evt);
em.getTransaction().commit();
em.close();Ezzel itt az (lehet) a baj, hogy amint lezárod az EntityManagert, az összes managed entitás példányod, amit a persistence contextben használtál, detached lesz. Ennek pedig az a következménye, hogy a még be nem töltött, lazy load relációk nem tudnak majd betöltődni, ill. az objektumok módosítása esetén nem lesznek automatikusan perzisztálva sem.
Thank you to god for making me an atheist
-
Lortech
addikt
UsersRolesLoginModule az egy fapad login module, property fájl alapú, nem tud db-ből authentikálni.
Amit én linkeltem, az direktben a datasource-on keresztül jdbc-zik, de simán lehet írni JPA alapú login module-t, írtam is már wildflyra, weblogicra.. Nem triviális, de nem is ördöngősség.
Pl. csinálsz egy EJB szolgáltatást ami JPA-n keresztül elvégzi az authentikációhoz szükséges ellenőrzést. A loginmodule-ból pedig JNDI-n keresztül lookupolod az EJB-det. A loginmodule-t csomagolhatod az alkalmazásodhoz is, nem muszáj külön modulként telepíteni.
Belépés után httpservletrequestből (JSF-ben facescontexten keresztül) elérhető a felhasználó a getUserPrincipal metódussal (getName normálisan a felhasználó nevét adja vissza), ezzel bekérdezhetsz az adatbázisodba. Van még isUserInRole is ugyanitt.[ Szerkesztve ]
Thank you to god for making me an atheist
-
Lortech
addikt
Pedig a standalone/domain.xml-ben kell beállítanod a security domainedet. A security domain / realm az nem 1:1 egy alkalmazáshoz kapcsolt, hanem alkalmazások fölött álló koncepció. JAAS infrastruktúra és Java EE pedig nem ad standard megoldást arra, hogy hogyan kell az alkalmazáshoz security domaint rendelni. Ezért van az, hogy jboss-web.xml-ben kell megadni. Vagy standalone/domain.xml-ben default security domainnek beállítani.
jboss-web konfiguráció itt van említve: [link]
security subsystem pedig itt van leírva: [link]
Ebből látszik, hogy a Database / DatabaseUsers modul a webes admin konzolon
a org.jboss.security.auth.spi.DatabaseServerLoginModul-t jelenti.
Tutorial: [link]Fontos, hogy wildfly 11-től elytron alrendszer van és önmagában kevés a fenti legacy konfiguráció.
Migráció: [link][ Szerkesztve ]
Thank you to god for making me an atheist
-
Lortech
addikt
Ez javascript, nem java.
Alábbi példából talán ki tudod hámozni, ami neked kell, a screenshot alapján készült a struktúra, nem tudtam pontosan azonosítani.
var sampleObj = { cid: 'genBasic',
data: {
xiaomiStruct:
[
{ index : 100, data: 0 },
{ index : 150, data: 2205 }
]
}
}
var indexToLookFor = 150;
var dataObj = sampleObj.data.xiaomiStruct.find(function(e) {
return e.index == indexToLookFor
});
console.log(dataObj.data);Thank you to god for making me an atheist
-
Lortech
addikt
válasz Vesporigo #9701 üzenetére
Amikor deklarálsz egy metódust, mindig meg kell adni a visszatérési értékének típusát vagy a voidot.
Vegyünk két metódust:
void m1() {
}String m2() {
return "visszatérési érték";
}m1 void, ami azt jelenti, hogy nincs visszatérési értéke, azaz a metódus hívás nem használható olyan kontextusban, ahol egy értéket várunk.
pl.
String x = m1(); //hibás, mert m1 nem tér vissza értékkel.
System.out.println(m1()); //hibás, mert m1 nem tér vissza értékkel.
x = m2(); // ok, x értéke "visszatérési érték" leszUgyanígy m1 metódus törzsében nem adhatsz meg pl. return "xyxy"; utasítást, mert nem térhetünk vissza értékkel, ellenben megadhatunk return; utasítást, amivel jelezzük, hogy adott ponton térjen vissza a metódus (visszatérési érték nélkül).
pl.void m1() {
return "xyxy"; //hiba
return; //ok, de nem kötelező, itt felesleges
}[ Szerkesztve ]
Thank you to god for making me an atheist
-
Lortech
addikt
Most tényleg kérdőjel van az exceptionben, vagy csak nem akartad leírni a konkrét hibát?
Én először megnézném, hogy az adott requestre adott válasz érvényes-e a wsdl-re.
Pl. Soapui megmondja a response-on jobb klikkre.
Aztán leellenőrizném, hogy a wsdl nem változott-e időközben, ugyanazt a wsdl-t implementálja-e a végpont, mint amiből a kliens lett generálva (?).
Ha már muszáj debuggolni, akkor IDE-ben be tudsz állítani exception breakpointot az exception típusra.Thank you to god for making me an atheist
-
Lortech
addikt
válasz <Lacy85> #9811 üzenetére
Új frontend fejlesztésre JSP-t nem javaslom, egyáltalán nem. Függetlenül az Oracle és Java EE viszonyától, mert ez itt irreleváns. JSP már nem fog fejlődni érdemben, ha Oracle diktál Java EE fronton, ha nem.
Érdemes lehet max pár órát rászánni, megnézni, hogy ilyen is volt, hozzátartozik az evolúcióhoz címszóval, kipróbálod, megérted, pipa, next. Servlet speccel azért érdemes lehet tisztában lenni.A "dobja az Oracle" lehet pozitív vagy negatív is, én inkább pozitívumként élem meg, hogy hátralép egyet és átengedi a communitynek az irányítást, a tényleges következményeket utólag lehet majd értékelni. A jelenlegi állapotában a Java EE egy használható platform. Amire nincs jelenleg Java EE spec, és reális igény, azt belegózhatod majd külső libraryként a stackbe, mint ahogy teheted most is. Én akkor se aggódnék néhány éves távlatban, ha nem volna egyáltalán Java EE fejlesztés. De erről nincs szó.
Thank you to god for making me an atheist
-
Lortech
addikt
válasz <Lacy85> #9813 üzenetére
Java EE-ben JSF van, használható, de nincs benne túl sok perspektíva szerintem. Ahogy úgy általában a Java alapú frontend fejlesztésben.
Elhangzott már a GWT és Vaadin, előbbi alacsonyabb szintű, jól kiforrott megoldás, utóbbival gyorsan lehet használható frontendet készíteni.
Van még sok egyéb, pl. a Play fw, vagy az Apache webes frameworkök mint Struts/2, Wicket, Tapestry, Stripes.
Ott van a Spring (web) MVC pl. thymeleaffel.
Én már nem tervezek/fejlesztek új projekten java alapokon frontendet, a legtöbb esetben java az API-kat szolgáltatja, valamint a middleware-t, backendet, a frontend pedig böngészőben fut valamelyik javascript alapú frameworkön/libraryben megvalósítva, pl. React, Vue.js vagy Angular valamelyikében.[ Szerkesztve ]
Thank you to god for making me an atheist
-
Lortech
addikt
válasz Taoharcos #9817 üzenetére
Az álláshirdetésekben általában össze vissza van ez. Akkor is beleírják sokszor, ha full spring stacken dolgoznak. Akik kiírják a pozíciókat, sokszor azt se tudják, mi a különbség. Mai napig J2EE-nek nevezik Java EE helyett stb.
Thank you to god for making me an atheist
-
Lortech
addikt
válasz Aethelstone #9841 üzenetére
(bocs, válaszra nyomtam, de nem csak neked írtam)
-Null-ra instanceof String false-t ad természetesen. Null az null típusú.
-Pointerezést hagyjuk már, nincs pointer javában, referencia van. Nem ugyanaz a kettő, úgyhogy nem csereszabatos a két fogalom.
-Az eredeti példában AskDeviceName null, és mivel isEmpty egy példány szintű metódusa a String oszálynak, ezért kapsz nullpointexceptiont, mert null referencián próbálod hívni a metódust. Objektum példányod viszont nincs.
-primitív típusoknak van default értékük, ha mezők. Lokális változokként inicializálatlanok by default, compile time error rájuk hivatkozni.[ Szerkesztve ]
Thank you to god for making me an atheist
-
Lortech
addikt
Nullra kell vizsgálnod:
if (AskDeviceName == null) { ... }Egymásnak ellentmondóak, amiket írsz, vagy valami nagyon béna API-d van, ami egy sima get-re is mellékhatással jár és/vagy nem konzisztens, egyszer működik, egyszer nem.
[ Szerkesztve ]
Thank you to god for making me an atheist
-
Lortech
addikt
válasz bambano #9848 üzenetére
Jaj istenkém, hát így hívják az exceptiont, béna, inkonzisztens elnevezés. És akkor mivan?
Historikusan (pl. C és társai esetén) mutató típushoz olyan többletjelentést (pointer aritmetika) társítunk, ami Java referenciáknak nincs, ezért szoktuk különválasztani a kettőt.[ Szerkesztve ]
Thank you to god for making me an atheist
-
-
Lortech
addikt
-
Lortech
addikt
válasz Aethelstone #9913 üzenetére
Jól mondod, de én még tovább mennék: nem nem csak, hanem egyáltalán nem hatékonyság kérdése. Ha ugyanarra volna való a két operátor, csak az egyik hatékonyabb lenne, akkor nem is létezne a kevésbé hatékony.
Abban a nagyon ritka esetben, mikor &,|,^ valamelyikét írod boolean operandusok esetén és nem elírtad, akkor 99,99..%, hogy a rövidzár/nem rövidzár különbséget akarod valamiért kihasználni.[ Szerkesztve ]
Thank you to god for making me an atheist
-
Lortech
addikt
válasz Aethelstone #9917 üzenetére
Ez oké, amikor egyedül toljuk a saját garázs projektben, viszont csapatban illik a standardek, konvenciók, ajánlások szerint fejleszteni, mert jó esetben ez az, ahogyan a többi csapattag is fejleszt, egy új csapattagot így lehet legkönnyebben beilleszteni. Volt szerencsem mar sokfele tragya munkahoz sajnos, ahol a tragya megoldasok valtak konvenciokka, es igen kellemetlen tud lenni, mikor mindenki hulye a csapatban, csak en vagyok helikopter. Nalam az & PR-nel azért menne a levesbe boolean operandusok eseten, mert a fejlesztok tobbsege szerintem csak a bitenkenti ES jelenteset, egeszeken ertelmezve ismeri es dobna egy exceptiont, ha ilyet lat, es ez netto kidobott ido, ha egy sima feltetelen gondolkodni kell.
[ Szerkesztve ]
Thank you to god for making me an atheist
-
Lortech
addikt
válasz Aethelstone #9934 üzenetére
Ha restcontroller, akkor feltetelezhetjuk, hogy spring @RestController, default jackson, es @RequestBody automatikusan deszerializalodik (sajat típus is), ha lehetseges. Tehat nem feltetlenul kell egyedi (de-) szerializaciot faragni hozza.
REST(-ful webservice) pedig ugyancsak webszerviz ebben a kontextusban, ahogy a SOAP, en nem szeretem ezt a megkulonboztetest.[ Szerkesztve ]
Thank you to god for making me an atheist
-
Lortech
addikt
válasz Amartus #9971 üzenetére
Nem olvastam a cikket, de vagy hülyeséget írtak, vagy félrevezetően írták, vagy féltreértelmezted (valószínűleg utóbbi). A "java" használata továbbra is teljesen ingyenes. A 8-as verzió támogatása szűnik meg 2019-ben, a támogatásért kell fizetni onnantól kezdve, ha igénybe szeretnéd venni. Tehát továbbra sem akadályoz meg semmi abban, hogy 8-as verzió legutolsó kiadását használd az ingyenes támogatás lejárta után is. De ajánlott gyorsabban átállni újabb verziókra.
Thank you to god for making me an atheist
-
Lortech
addikt
válasz bambano #9975 üzenetére
"Fizetős lesz a java az Oracle-től": igen.
Nem.
Még úgy sem állja meg a mondat a helyét, hogy a frissítések lesznek fizetősek.
Azzal a kitétellel állja meg a helyét, hogy bizonyos főverziók frissítései és támogatása és bizonyos idő után.
Mondhatná azt is, hogy lófütyit nektek, EOL után nem csinálok frissítést, helyette megpróbál pénzt csinálni belőle. Tetszik nem tetszik, nekem ugyan nem tetszik, de maradjunk a tényeknél egy szakmai topikban, a riogatást, félinformációk terjesztését, térítést meg hagyjuk.szerk: itthagyom, de áthúzom, mert félrevezető. Tévedtem, az állítás a 10-es verzióig bezárólag állja meg a helyét, az Oracle JDK használata a 11-es verziótól kezdve valóban nem ingyenes "üzleti célú" felhasználásra.
[ Szerkesztve ]
Thank you to god for making me an atheist
-
Lortech
addikt
Én. JDK-bol azert kerultek ki a Java EE interfeszek tobbek kozott, hogy egyszerubb legyen a JDK/JSE kiadas. Lasd motivation resz itt [link]. Eleve nem kellett volna belerakni Java EE reszeket.
Eddig sem volt resze a Java EE modulok tobbsege a JDK-nak, onmagaban a JDK nem volt elegendo (Java EE) fejlesztesre.
Ezeket csak azért tartottam fontosnak leírni, mert a hozzászólásodat továbbgondolva arra a következtetésre juthatnak a témában kevésbé járatosak, hogy most lényegesen nehezebb lesz Java EE-re fejleszteni vagy hogy halott a történet, pedig a szóbanforgó változások nem jelentenek ilyet.[ Szerkesztve ]
Thank you to god for making me an atheist
-
Lortech
addikt
Ez elég nyilvánvaló. De eddig is lassan mozgott a Java EE. Aminek nem csak hátránya van azért.
Meglátjuk a következő 1-2 évben, hogy mi lesz a Jakarta EE-vel.Szerintem nem nehezebb EE-ben dolgozni, napi szinten használom mindkettőt évek óta és még mindig a specifikus igényektől függene, hogy melyikhez nyúlnék, ha valami zöldmezőset kellene csinálni.
Springben talán egyszerűbb kezdőként eredményeket elérni, de ha megvan a tudás Springben és Java EE-ben is, valamint egy jól összerakott, bejáratott architektúra, akkor elég jól lehet haladni mindkettővel.Thank you to god for making me an atheist
-
Lortech
addikt
A FileOutputStream flush() metódusa, melyet az OutputStream osztályból örököl, így néz ki:
public void flush() throws IOException {
}Szóval ne pazaroljuk a vizet feleslegesen.
Thank you to god for making me an atheist
-
Lortech
addikt
válasz axioma #10185 üzenetére
Lehet ilyeneken szörnyülködni, de ezek tudása / nem tudása pont nem mond el semmit arról, hogy az illető milyen szoftverfejlesztő.
Sok-sok interjún túl számtalan példát tudnék hozni, hogy ki mit nem tudott interjún, olyanok is akiket később felvettünk és tök jó kollégák lettek. Valószínűleg tőled is lehetne java témában 5/5-öt kérdezni, amit nem tudnál, ~mindenkitől.[ Szerkesztve ]
Thank you to god for making me an atheist
-
Lortech
addikt
Ha engem kérdezel, 1 óra alatt szerintem nem lehet, és nekem nem is célom. Reális cél számomra annak eldöntése, hogy együtt akarok-e dolgozni a jelölttel, ennek egy - fontos, de nem mindenek felett álló - összetevője a szakmai tudás.
Junioroknál szoktam javasolni inkább, hogy tesztsor vagy kódolós feladat legyen.
Senior esetén nálam szakmai beszélgetés jellegű az interjú, nem kérdezz felelek. Persze ehhez kell az, hogy a másik fél partner legyen ebben és jól tudjunk együtt gondolkodni, kommunikálni.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?:))
- Politika
- Star Wars Jedi: Survivor - Befutottak az első értékelések
- Motoros topic
- Gaming notebook topik
- Vírusirtó topic
- Xbox Series X|S
- Internet Rádió építése (hardver), és programozása
- bambano: Bambanő háza tája
- Féltucat régi Samsung kapott új One UI-t, köztük az A52s
- Autós topik
- További aktív témák...
- Fujitsu Lifebook E546 , 14" Kijelző, I3-6100U, 8GB DDR4, 128GB SSD, WIN 10, Számla, garancia
- Fujitsu Lifebook E544 , 14" Kijelző, I7-4712QM, 16GB DDR3, 128GB SSD, WIN 10, Számla, garancia
- Dell Latitude E6430, 14" HD+ Kijelző, I7-3720QM, 8GB DDR3, 320GB HDD, Nvidia 1GB, WIN 10, Számla,
- Dell Latitude E5540, 15,6" Kijelző, I7-4600U, 16GB DDR3, 500GB HDD, Nvidia 2GB, WIN 10, Számla, gar
- Dell Latitude E5540, 15,6" Kijelző, I5-4310U, 8GB DDR3, 500GB HDD, WIN 10, Számla, garancia
Állásajánlatok
Cég: Ozeki Kft.
Város: Debrecen
Cég: Promenade Publishing House Kft.
Város: Budapest