- Samsung Galaxy S23 Ultra - non plus ultra
- Samsung Galaxy A54 - türelemjáték
- Milyen okostelefont vegyek?
- Középkategóriást mutatott be újra az Oppo
- VoLTE/VoWiFi
- Redmi Note 13 4G
- Fotók, videók mobillal
- One mobilszolgáltatások
- Felújított okostelefonokat kínál a Rejoy
- Csíkszélességben verné az Exynos 2600 a Snapdragon 8 Elite 2-t
Új hozzászólás Aktív témák
-
-
Oppenheimer
nagyúr
Ezt jottem linkelni, de megelőztél. Szerintem nagyon sokat tett a Google a Java-ért azzal, hogy tobb, mint 1 milliárd okostelefonra Java a fő programozási nyelv. Nem tudom miert faj az Oraclenek egy masik api implementáció. (jó tudom, készülékenként részesedést a bevetelbol).
Ezzel a ítélettel hosszu tavon mit veszíthet a szakma?
-
dangerzone
addikt
Ezt végigjártam, még az általános védelmi szintet is lejjebb húztam, de ugyanezt írja ki.
Egyébként visszaraktam a 32 bites java-t, de ugyanez. Már max csak annyira tudok gondolni, hogy talán a registry-t is ki kellene pucolni a sok java install miatt.Egyébként a másik gond meg az, hogy nem lehet elküldeni a navnak a nyomtatványokat, mindig valami hibát ír ki, hogy a küldés sikertelen. Ez lehet szintén a java hibája?
-
-
kemkriszt98
tag
Nem az idő rászánása a baj (van már tapasztalatom az andrioddal) csak tapasztalatból tudom, hogy ha úgy próbálom követni a tutoriált hogy közben ilyen drasztikus változtatásokat eszközölök annak nem lessz jó vége.... következő projekt már saját lesz, ott majd nem fogok appletekkel vacakolni...
-
WonderCSabo
félisten
A counter azért alakult ki, mert az Androidnál vannak komponens nyitó és csukó események, ezekben van hívogatva a get és a close. Ha nullára esett vissza, akkor már senki sem használja a helpert, ezért zárni kell a kapcsolatot. Kb. hasonló a referencia számláláshoz.
Nem tudom, hogy az asszimetria miért alakult ki.
M_AND_Ms: így is lehet végülis nézni. :-)
-
WonderCSabo
félisten
Azért kell usageCounternek is statikusnak lennie, mert a getHelper() többször is meg lehet hívva, ami statikus. Annyi a lényeg az egészben, hogy a getHelper() és a close() elvileg páronként vannak hívva, és ha a szám 0-ra esik akkor bezárja a db-t. Vagy mi volt a kérdésed?
-
-v-
addikt
A lambda meg a funkcionalis dolgok tok jok, en konkretan most arra ertem amit a java 8-ba beleraktak ... na annak ebben a formaban semmi ertelme szerintem. De most tenyleg, sporolok par sort, hogy nem kell anonymus classt csinalnom, es ennyi (amit amugy is baromi ritkan, 1-2 speci esetben hasznalni, mert nem valami jo gyakorlat) ... a fordito meg ugyis ugyanazt csinalja belole.
Ezen kivul meg lettek default methodok, es ennyi, ez a java 8? De tenyleg, nem hozott semmi ujat ... -
Valószínűleg az lesz nálunk is, még pár napig van meg az éves subscription, ha addig nem érkezik meg az új akkor rá leszünk kényszerítve rendesen. :-) Személy szerint nem bánnám, néha meg kell lépni 1-2 verzióváltást. Semmi speciális ficsört nem használunk, ami indokolná a myeclipse-t. Azon viszont meglepődtem, hogy máshol is "divat".
@WonderCsabo: Akkor neked is SR2 van már a 4.3.2-es verzió pont ez.
-
Használtál már myeclipse csodát? Nah az az igazi "csoda".. Sajnos a cégnél ez fut, 1000éves verziókban természetesen. :-( Bughalmaz, az általa létrehozott projekteket nem lehet más ide-be behúzni, egyrészt mert sajnos property fileokat generál, másrészt mert sajna a projektfájlok is az svn részeit képzik ügyesen okosan :-)
-
WonderCSabo
félisten
Dehát a Java SE 8 most már final. Tegnap jött ki, a letöltő oldalon is ezt adja.
Annyira sok újdonság nincs benne, bár azért van egy nagy dolog:
* JSR 335, JEP 126: Language-level support for lambda expressions
* JSR 223, JEP 174: Project Nashorn, a JavaScript runtime which allows developers to embed JavaScript code within applications
* JSR 308, JEP 104: Annotations on Java Types for Unsigned Integer Arithmetic
* JSR 310, JEP 150: Date and Time APIÉn egyelőre nem rakom fel, mert nem sokat érnék vele, az Eclipse saját fordítója még nem támogatja. Az Eclipse Java 8 fordítója már RC státuszban van, és a Java8-at támogatja az Eclipse következő Luna verziója. Kérdés, hogy ez mikor fog megjelenni.
-
LonGleY
veterán
Nem. :] Amúgy már van újabb.
Jah, közben én is megtaláltam az about-ot. Itt is keverik a szezont a fazonnal. A build az a 132, viszont mitől 1.8, ha egyszer v8? Tökömet az Oracle-be. Nem csodálom, ha össze-vissza jelzik a híroldalak is, ha maguk se tudják eldönteni, hogy miként verziózzanak. Hogy ez miért lényeges? Magam is híroldalra pakolnám a megjelent verziót. A sok igénytelen szutyok oldal szokása helyett az ilyeneket szeretem letisztázni, az információkat pontosan megjeleníteni.
-
WonderCSabo
félisten
-
Oppenheimer
nagyúr
Lesz mellélövés, a tündék 50% eséllyel elkerülik a lövedékeket.
(#5158) Karma: iskolai feladat, és pont ez volt a cél, hogy ne ismerjen mindenki mindenkit, és ne egy valaki döntsön mindenről. Egyébként itt a feladatkiírás:
A két torony
A gonosz emberek, tündék, törpök és hobbitok szövetséget kötnek, hogy elpusztítsák az Egy Gyűrűt a Végzet Hegyénél. Szerencsére csak Mordor földjén keresztül tudnak eljutni a hegyhez, így jóságos Szarumánnak lehetősége van védelmi tornyokat építeni, hogy segítsen megvédeni Szauron hatalmát. A játék célja annak megakadályozása, hogy a Gyűrű szövetségének tagjai közül bárki is eljusson a Végzet Hegyéhez. Egy ellenség akkor pusztul el, ha összességében megfelelő mértékű sebzést kap a tornyokból származó lövedékektől. A tornyok építéséhez Szarumánnak a varázserejét kell használnia. Szarumán akkor tud tornyot építeni, ha megfelelő mennyiségű varázsereje van hozzá. A varázsereje minden egyes elpusztított ember, tünde, törp vagy hobbit után bizonyos mértékben növekszik.
A Gyűrű szövetségének tagjai különböző utakon juthatnak el a Végzet Hegyéhez. Az utakról nem térhetnek le. Szarumán az utakra nem tud tornyot építeni, csak az utak mellé. Az utakra azonban tehet akadályokat, amik az akadály területén lassítják az ellenség haladását. A tornyoknak van egy adott hatótávolsága és tüzelési gyakorisága. Szarumán a varázserejét arra is használhatja, hogy a tornyokat és akadályokat különböző varázskövekkel ruházza fel. A varázsköveknek több fajtája is létezik, és különböző hatásúak lehetnek. Egyes kövek növelhetik a tornyok hatótávolságát vagy tüzelési gyakoriságát, más kövek egy-egy típusú ellenfél esetén megnövelik a lövedékek sebzési erejét.A játék során az ellenségek folyamatosan jönnek. A játék elején ritkábban, később gyakrabban és nagyobb csoportokban, azonban számuk véges, előbb-utóbb elfogynak. A játék akkor ér véget, ha egy ellenség eljut a Végzet Hegyéhez, vagy ha már sikerült az összes ellenséget kiirtani. Az első esetben Szauron és Szarumán megsemmisül, utóbbi esetben fényes győzelmet aratnak és örökké uralni fogják a világot.
-
hasman
tag
Még 1x köszönöm, megpróbálok előbb utóbb abból is felvenni magamra egy keveset
A szerkesztési körülmények alatt nem tudom mit értesz, de a struktúrák kialakítása, hogy az egyes hivatkozások jól legyenek megírva, az tényleg számomra másodrendű, nem vágyom bonyolult programokra, ha azt szeretnék, szerintem el sem kezdeném tanulni a JAVA-t mert az több év lenne mire össze tudnék rakni valamit. Egyelőre csak ismerkedem, tanulmányozom, aztán ha nem tetszik, vagy kifog rajtam megtanulok japánul, vagy valami hasonló hasznos dolgot -
hasman
tag
floatr: Rendben, ezt is megértem, sőt ki is próbálom hétvégén, de egyelőre a parancssoros meghívások nekem tökéletesen elég (jelenleg).
Nem az a célom a JAVA tanulásával, hogy akármit is megtervezzek, (lehet kisebb dolgokat magam is terveznék, ) inkább a cél az, hogy lássam a programozás korlátait, és ne olyan dolgot találjak ki amit mondjuk esélytelen leterveztetni.
A magam részéről egy hasonló program letervezését tűztem ki célul magam elé:
http://pf-prg.hu/trafo/trafo-4.php?mod=-3 -
Aethelstone
addikt
Agree. Ugye Java-ban van ez a remek package rendszer. Valaki korábban már említette, hogy package szerint is tök jól el lehet különíteni az osztályokat. Én is ennek a híve vagyok, ergó jelen pillanatban pl. az Eclipse nem sok segítséget ad. Annál inkább a hu.akarmi.iface és hu.akarmi.impl
A C/C++t meg annyira ismerem, amennyire a főiskolán kellett
-
Aethelstone
addikt
-
chabeee
aktív tag
hát eléggé, mivel rossz volt az import.
Részletesebben a multipart -ba nem tudtam MimeBodyPart típusú adattagot rakni, mert folyamatosan BodyPart-ot kért, akkor viszont máshol volt a hiba. (már nem emlékszem, reprodukálni meg nem sikerült) a vége ez lett
try {
MimeMessage msg = new MimeMessage(session);
msg.setFrom(new InternetAddress(username));
msg.addRecipient(Message.RecipientType.TO,
new InternetAddress(to));
msg.setSubject("Test Java Sending Zip File");
msg.setText("This is a message from a java program");
MimeBodyPart msgbodypart = new MimeBodyPart();
msgbodypart.setText("this is msg Body");
Multipart multipart = new MimeMultipart();
msgbodypart = new MimeBodyPart();
String filename = "MyFile.zip";
DataSource source = new FileDataSource(filename);
msgbodypart.setDataHandler(new DataHandler(source));
msgbodypart.setFileName("its_a_zipped_file.zip");
multipart.addBodyPart(msgbodypart);
msg.setContent(multipart);
System.out.println("-Sending");
Transport.send(msg);
System.out.println("Sent!");
}catch (MessagingException mex){
mex.printStackTrace();
} -
WonderCSabo
félisten
Én mondjuk mobilon mozgok mostanában, itt azért jóval kisebb libekkel találkozom, 20 megabyte-tól én is a falra másznék. A másik implementáció mondjuk tényleg nagyon zavaró, pl. jellemzően mindenki más logging frameworkot használ és akkor ez mind foglalja a helyet. Az előbb említett proguardot tudom ajánlani.
-
WonderCSabo
félisten
Én azon az állásponton vagyok, hogy inkább használjunk általános libeket. Egyrészt nem kell újraírni a kódot, másrészt a lib készítői valszeg több mindenre gondoltak (hibák, lehetőségek stb.), mint mi valaha is tudunk, továbbá folyamatosan fejlesztik is ezeket. A mai hardverek mentén én nem látok problémát a teljesítmény terén, már Android-on is csomó reflective kód fut (sőt maga az egész framework reflectionnel megy), pedig csak buta HW van alatta desktophoz vagy serverhez képest. A méretet tekintve pedig pl. proguarddal a nem használt kódot könnyen ki lehet dobni a libekből.
A GSON-t egyébként pont Karma mutatta nekem anno, sztem szuper jó lib, csak ajánlani tudom mindenkinek. Olyan gyönyörű megoldások vannak benne, amik sztem egy hétköznapi fejlesztőnek sosem jutnak eszébe.
-
Karma
félisten
Pont a specifikusság az, amivel karcsúbbat lehet írni. A Gsont durván szét lehet hackelni anélkül, hogy a forráskódhoz nyúl az ember(*). Másrészt vannak benne apróságok, amik elméletben nem is számítanának, de a gyakorlat más... Például hogy a Mapek sorrendtartóak.
(*) Személyes rekordom: olyan bővítmény. ami új annotációkat figyel a célosztályon, és a bemeneti JSON fát transzformálja többféleképpen, mielőtt a reflexió rámenne. Nagyon ocsmány JSON bemenetnél kihúzott a szarból.
-
Annyira nem nevezném semmirekellőnek, mert ha konkatenálni akarsz primitív konstansokkal egy konstans Stringet, akkor nem mindegy, hogy a primitívből is lesz egy String és ebből a kettőből csinál egy újat futási időben, vagy már fordítási időben megtörténik ez.
Példának okáért:
String emelet = ". emelet";
String emelet1 = 1 + ". emelet"; // bytekódban: // String emelet1 = "1. emelet"; -
WonderCSabo
félisten
Így van, ha csak egy sor összefűzésed van, akkor feleslegse SB-re cserélni, hiszen a fordító úgyis megteszi, illetve a String + operátoros verzió sokkal olvashatóbb.
(#5076) floatr: A Superhun által bemutatott optmalizációra egy valid use-case:
class Test {
private static final int max = 10;
public static void main(String[] args) {
int a = ...; // beolvasod
if (a > max) {
System.out.println("Value is bigger than " + max + "!");
}
}
}Ekkor a bytecodeban egy összefűzött String literált generál a fordító.
-
-
-v-
addikt
Ezzel annyit érsz el, hogy a println() String paraméteres verziója hívódik meg. És az azért jobb neked... mert?
"Ha van egy változód, ami akár objektum, akár egyszerű típus, akkor ez a megoldás mindig működik."A "" + nélkül is.
Ha azt mondod
System.out.println(myObject);
System.out.println("" + myObject);
és a myObject null, mindkét esetben "null"-t fog kiírni. Ha nincs felüldefiniálva a toString-je, akkor is ugyanazt írja ki mindkét esetben (MyObject@120cc56 pl ... ). Ha nem referenciatípus, hanem primitív típus, akkor sincsen különbség, println() mindenre túl van terhelve. Még mindig nem értem mire jó ez... nem kell se toString se semmi, println(amitakarszkiiratni) aztán szevasz ...
Ott van különbség ha pl. int-ek, ha nincs előtte "" akkor a + miatt összeadja mielőtt kiírja, ha meg egy ""-t odaraksz elég onnantól stringként kezeli és konkatenálgatja.. de itt most ilyesmi nem volt kérdés. -
WonderCSabo
félisten
Ha viszont nincsen saját toString metódus, akkor pointer értéket fog kiírni.
Ez nem teljesen igaz, az Object osztályban definiált toString() hívódik meg ilyenkor, ami akármit kiírhat. Általában a Java implementációkban az Object#toString() ezzel tér vissza:
getClass().getName() + '@' + Integer.toHexString(hashCode());
Ugye ez az egész csak sima dinamikus kötés.
-
MrSealRD
veterán
Köszi.
Kár, pedig éppen csak belejöttél...
Ha minden jól megy akkor jövő héten már próbálgatni fogom ezeket a dolgokat...Délutánra sikerült összeraknom "a szervert". CentOS 6.5 + jdk7_51 + wildfly8.0.0(szolgáltatásként futva)
Még az Iptables-el kell összebarátkoztatni és akkor jó lesz... -
MrSealRD
veterán
Ezt az ujratöltés bug-ot azért megjegyzem, ha előfordul valami akkor ne lepődjek meg.
Átolvastam eztHát nagyon hajlanak az ilyen könnyedebb cuccok felé. Dicsérik őket, bár a végén a JBoss nyer...
Tőlük elolvastam még a web framework tesztjüket is...na ott meg lehúzzák a Spring-et...azt elégég furcsának tartottam mikor a piaci részesedése igen magas...De jó, hogy ezt felhoztad. Az előzőbe pont kérdezni akartam, hogy több helyen olvastam, hogy a web profile részt használva kis túlzással cserélgethetem az alkalmazásszervereket mert nagy gond nem lehet belőle elvileg minimális konfiggal működnie kell...
-
MrSealRD
veterán
A vitát leszámítva akár én is lehetnék a bevezető alanya...
Ez már durvább téma volt kicsivel...viszont látom, hogy ha nálunk is ez lesz akkor tényleg ráborulok az asztalra, ahogy írod is...
Nehéz így technológiát választani, hogy nem használom készség szinten.
Ma addig jutottam az alkalmazásszerver témában, hogy JBoss és Tomcat-re szűkítettem a kört(Glassfish volt a harmadik). Nem véletlen, az egyik egy űrhajó ha másik egy vitorlázógép...
Azt gondolom, hogy ha később beesik valami nagyobb méretű dolog amihez a JBoss kéne akkor jól jön ha most bemelegítünk rajta. A másik, hogy full platform, szóval nem érhet meglepetés menet közben, hogy hopp hiányzik a Tomcat-ből valami...(Tudom ott lenne a TomEE) viszont ha változik a konfig akkor nem kell restart elég a reload...még akkor is ha ez nem sokszor fordul elő.
Néztem, hogy a memóriaigénye kb dupla az egyik oldal szerint. De hát ha az egyik 100MB-ot kér a másik meg 200MB-ot, akkor az elhanyagolható lesz az alkalmazás vagy az egész szerver méretéhez képest...Ezek miatt a JBoss felé húzok...Nem tudom mennyire teszem jól...
-
MrSealRD
veterán
Tyű...jó a stílus és emészthető volt az anyag. Amit láttam az alapján nagyon tetszik ez az eszköz...Köszi még egyszer, hogy megírtad.
Az is látszik, hogy azért kell egy-két dummy alkalmazást is összedobni majd a napokban, hogy ülepedjenek a dolgok...Ja és persze könyvjelzőbe felvéve.
-
S0m30n3
aktív tag
Köszönöm a tanácsokat.
Igen, érdekel komolyabban a programozás. Amúgy a tanárnőnk is mindig mondja, hogy a tervezés egy nagyon fontos szempont, én is így gondolom, csak adatbázisokhoz még nem sok közöm volt, pont azért is próbáltam ki a vizsgaprogramban. Nem gondoltam, hogy ennyire szerteágazó az adatbázisok világa, de legalább ez a kis fejlesztés erre is ráébresztett.
-
fatal`
titán
Akkor dob nullptrexet, ha az objektum null, aminek hívod az equals függvényét, de ez egyértelmű.
Maga az equals nem kéne, hogy nullt dobjon, csak false-al visszatérni.
(#4837) Karma : Sajnos még az egyetemeken is jellemző, hogy nem engednek listát használni, vagy nem mindig.
Én pl. csak akkor használok tömböt, ha fixek az elemek.
-
M_AND_Ms
veterán
"Valamiért nekem még mindig az volt a fejemben, hogy az equals nullptr-t dob akkor is, ha a paraméter null."
Általában elmondható az equals-re is, hogy úgy működik, ahogy megírták és azt dobja, amit nem kezeltek benne, vagy amit szándékosan dobnak.
Amúgy, a legősibb equals az Objectben van, ami nem dob null-t null bemenő esetén, csak kiad egy szép false-t.
-
Karma
félisten
Most decompiláltam az ArrayList.class-t a JDK7-ben (rt.jar):
public int indexOf(Object obj)
{
if(obj == null)
{
for(int i = 0; i < size; i++)
if(elementData[i] == null)
return i;
} else
{
for(int j = 0; j < size; j++)
if(obj.equals(elementData[j]))
return j;
}
return -1;
}Nem látom az összeomlást.
-
Karma
félisten
Nem tudom melyik forrást nézed, de az AbstractList indexOf teljesen korrekt módon kezeli a null elemeket a listában. Illetve nullra is tud keresni.
"Márpedig ahol objektumok vannak ott van null is
"
Ez egyáltalán nem biztos. Ha egy objektumlistáról nem lehet feltételezni, hogy benne objektumok vannak, ott azért vannak más bajok is, fejben
-
WonderCSabo
félisten
A Java serializáció API-ja teljességgel elhibázott, mi az, hogy be kell kopizni a függvényszignatúrákat a customhoz, és ha eltalálom jó. ha nem akkor meg se hívódik? Ehhez egy újabb interfészt kellett volna bevezetni. Van még sok dizájn flow a javában - pl. a clone() fv. az Object része, de csak akkor ok, ha az osztály implementálja a Cloneable interfészt - miért nem lehetett akkor a clone()-t eleve csak a Cloneable-be rakni...
Viszont ez a feature nagyon is jogos. Pl. van egy objektumgráfod, kétszer is hivatkozol valahol benne az objektumra, miért is mentenéd ki kétszer az értékét? Továbbá ha ciklikus referenciád van, akkor még nagyobb probléma lenne, ha mindig mentenél, mert szépen stackoverflowt kapnál.
Egyébként is, a gyakorlatban ez a példa sosem fog szerepelni (teljességgel hülyeség u.a. objektumot rögtön egymás után különböző értékekkel kiszerializálni, nem látom ennek use-caset).
A JSON meg XML valóban elterjedt, de azért ezek többet foglalnak és lassabbak is, mint a Java serializálás. Én pl. Androidon szoktam használni, ahol nem fájlba mentünk objektumokat, hanem programrészek között küldjük át szerializálva. -
-
M_AND_Ms
veterán
Azért a generics használata, főleg keretrendszereknél hasznos tud lenni. Pl.: egy rakat instanceof vizsgálattól kímél meg, viszont sokszor nagyon megnehezíti magának a generics-es kódoknak a karbantartását: nagyobb osztályhierarchián átívelő generics-ek módosításakor (pl: újak bevezetése) eléggé nehézkes az átírás, refaktor.
-
Jim-Y
veterán
Értem, az utóbbi részével nem lesz gond szerintem, előbbivel sem, mármint a kvízkérdésekkel, de attól azért félek, mert én még Nem dolgoztam java fejlesztőként, a tudásom leginkább abból áll amit a suliban tanultunk ami sokszor azért -főleg gyakorlás nélkül- nem fedi az ilyen kvízkérdéseket. Gondolok arra, hogy ha nem fejlesztek folyamatosan akkor kiesek a ritmusból, felejtek dolgokat stb. De akkor leginkább csak sűrűbben fogok foglalkozni a Java-val mint témával az interjúig és kész
Új hozzászólás Aktív témák
Hirdetés
A topicot kiemeltem. Valaki nem akar egy nyitó hsz-t írni?:))
- Csere-Beszámítás! Asus Tuf Gamer laptop! R7 3750H / GTX 1650 / 16GB DDR4 / 500GB SSD
- Csere-Beszámítás! Ryzen 9 9950X3D Processzor! 16Mag-32Szál!
- Bomba ár! Lenovo ThinkPad E550 - i5-5GEN I 8GB I 256SSD I DVDRW I 15,6" HD I CAM I W10 I Garancia
- Bomba ár! Lenovo ThinkPad T460 - i5-6GEN I 8GB I 256SSD I 14" FHD I Cam I W10 I Garancia!
- Samsung Galaxy A04 128GB, Kártyafüggetlen, 1 Év Garanciával
Állásajánlatok
Cég: PC Trade Systems Kft.
Város: Szeged
Cég: PC Trade Systems Kft.
Város: Szeged