ls -1TörténelemHUP adás-vételNépszerű témákNépszerű fórum témákHardverAjánlott böngésző Linux Weekly NewsFreeBSD Project NewsOpenBSD Journal |
Java SE 7"A Java SE 7 hivatalosan megjelent ma. A worldwide Java közösségen belüli, közel öt évig tartó együttműködés után a Java Platform, Standard Edition letöltésre kész!" - olvashatjuk a blogs.oracle.com-on. A Java SE 7 nagyobb új funkciói:
A bejelentés elolvasható itt. Letöltés itt. További részletek itt.
»
|
KeresésNavigációBelépésHupWikiÁllásajánlatokHWSWFriss blogbejegyzések
HUP napi hírlevélLegfrissebb HUP videókLegfrissebb HUP képekLegfrissebb HUP dokumentumokSzavazásMit tudsz a B-tree struktúráról? Részletekbe menően ismerem a felépítését, funkcióját, határait és felhasználását. 10% Kevésbé ismerem, mint az első pontban, de hozzá tudok szólni a témához. 18% Használom, de nem ismerem minden részletét. 4% Hallottam már róla, minimális mértékben ismerem. 27% Egyáltalán nem ismerem. 34% Csak az eredmény érdekel. 8% Összes szavazat: 560
Új felhasználók
InformációKövess minket!Partnerünk |
"many small language changes that add up to a big boost in productivity for developers"
Big boost my ass...
----------------------
"ONE OF THESE DAYS I'M GOING TO CUT YOU INTO LITTLE PIECES!!!$E$%#$#%^*^"
Ritka sovany es szomoru feature lista az 5 evhez kepest. De majd Java 8-ban, 2023-ban! ;(
A feature listából kimaradt, hogy sikerült a sun maradékát és a JCP-t is tönkrevágni ez alatt az idő alatt.
sajnos egyet kell ertsek. viszont evenkenti rilizt terveznek, a kovetkezobe project jigsaw + closureok. Simon Ritterrel beszelgettem, o eleg jonak latta a roadmapet, bar siman lehet, h csak a fizuja miatt. :)
Egy kicsit tartok is tőle, hogy pár év alatt lemarad az ember, ha nem túrja állandóan a sok guide-ot.
welcome to the world of IT.
A legnagyobb feature az alapértelmezés szerint túloptimalizált, félrefordított ciklus:
elég gáz, de a major verziók sajnos ilyenek :)
semmi gond, megígérték, hogy bár eddig 5 év alatt nem csináltak semmi érdemlegeset, de most 1 év alatt majd fognak! :)
"The Fork/Join Framework - facilitates parallelism for multi-core processors"
...és még véget sem ért 2011! Kíváncsi vagyok, milyen technikai áttörések várnak még ránk ebben az évben.
Egyébként pedig bámulatos, hol tart már a tudomány :D
http://download.oracle.com/javase/6/docs/api/java/util/concurrent/package-summary.html
--
http://neurogadget.com/
Sajnos elég konzervatívan álltak hozzá a nyelvet érintő változtatásokhoz, pedig voltak érdekes javaslatok. Például a collection osztályok nyelvi szintű támogatása szerintem alap kellene hogy legyen minden modern programozási nyelvben.
Ebben részben egyet értek. Csak túl sok féle van ebből, és nem lehet mindegyikre külön jelölést bevezetni (mint pythonban).
Túl sok? Szerintem az összes Collection típusra használható lenne ugyanaz a szintaxis.
És a fordító döntené el, hogy melyik adatszerkezetet használja? Szerintem ez optimalizáció szempontjából visszalépés.
Lenne lehetőség a típus explicit meghatározására, mint ahogy az ebben a javaslatban is szerepel. Bár én mondjuk jobbnak tartanám a szögletes zárójelek használata helyett a tömbök inicializálására használt jelölés alkalmazását, pl.:
List<Integer> list = new LinkedList<Integer> {1, 2, 3, 4, 5};nem a Java SE része de ha neked ez kell, ott a Guava:
http://goo.gl/CVSid
//previously:
Map> map = new HashMap>();
//in jdk7, use the diamond operator. Saves typing!
Map> map2 = new HashMap<>();
List<?> list = new ArrayList<>();
Ez a honap vicce, komolyan. Gondolom mindenkinek leesik, mi tortenik itt. :((
(Hint: okos tipusinferencianak adjak el a generikus parameterek elhagyasanak lehetoseget -- a type erasure miatt siman irhatnal new HashMap()-et is)
----------------------
while (!sleep) sheep++;
.. nem nagyon vagyok benne biztos, hogy értem, mire gondolsz...
Szetszedte a tageket a forummotor. Majd bemasolom megint.
----------------------
while (!sleep) sheep++;
type erasure ide, vagy oda, attol ott Te meg nem irhatsz siman generikus tipus nelkuli konstruktorhivast.
Arra gondolok, hogy itt az egvilagon semmi szukseg nincs tipusinferenciara, hiszen forditas utan type erasure tortenik, es ha siman engedelyeztek volna a generikus tipus nelkuli konstruktorhivast, az is ugyanugy mukodott volna.
----------------------
while (!sleep) sheep++;
forditaskor, a statikus tipusellenorzeskor a generikus tipus resze a teljes tipusnak; ennek fenyeben nem mukodik az, amit irsz.
Ha mar a type inference: az auto keyword fele megoldasnak tobb ertelmet latom, mint ennek, ami bekerult.
Ez nem pont ugyanarra a célra való lenne, mint a diamond expression. Az auto keyword gyakorlatilag ugyanaz lenne, mint a C#-ban a var keyword. Viszont a diamond expression abban az esetben jó, ha a template paramétert nem akarod kiírni.
Pl. ha egy fieldet deklarálsz, és a konstruktorban adsz neki értéket, akkor az auto keyworddel nem tudsz egyszerűsíteni a kódon, a diamonddal pedig igen.
Szóval nem ugyanarra való a két dolog, de szerintem is lenne értelme az auto keyword bevezetésének.
Persze lehet talalni olyan esetet, ami a diamond operator-ral lehetseges, auto-val meg nem, de az auto lefedi a diamond operator hasznalati eseteinek jo reszet (raadasul meg rovidebb) es meg sok mast is ad, ezert szerintem jobb lett volna inkabb az auto-t bevezetni (tobb a haszna).
De talan majd a 8-ban, jovore (es most probalok komoly arcot vagni).
Nekem nem tűnik úgy, hogy behozta a C#-tól való lemaradást nyelvi szerkezetekben.
- property-k
- operator overloading (tudom, sosem lesznek, mert a java szerint 10 összeadás 7 szorzásnál érthetőbb 17 függvény hívás)
- előjel nélküli típusok (volt, hogy kellettek volna)
- signal-slot kellene listener bullshit helyett (a C# event handling is szar, nem értem, miért nem qt stílusban oldották meg)
- ...
ahahah, Geri, te vagy az? :)
http://hup.hu/node/102208#comment-1268811 (powered by hupmeme)
Ez már a KDE4?
Azért nem véletlenül nem téged vettelek feleségül. Most egész életemben hallgathatnám, mekkora hülye vagyok, mert 30 évvel ezelőtt a hup egyik fórumán leírtam egy baromságot.
Szerencsére a feleségem képes volt tovább lépni ezeken és elnézte súlyos tévedéseim a realloc-kal kapcsolatban. És még válópert sem indított, csendben szótlanul tűrte. Most képzeld el!
:)
Képzelem /o\
+1
Mind a signal-slot, mind a listenerek ugyanazok. Az Observer patternt valósítják meg, ennyi, csak más karaktereket kell leírnod, koncepcionálisan semmi különbség nincs köztük.
Ebben egyetértek, de
my @array = (1,2,3,4);
List<Integer> array = new ArrayList<>() { 1,2,3,4 };
Azért a kettő nem teljesen ugyanaz. Reflection is mindenre jó, de azért inkább a setter és getter. Számít, hogy hány karaktert kell leírnod. Az operátor overload is mezei függvényhívás, mégis nagyban segíti/gátolja az átláthatóságot.
A java-t egy typeless perl-el összehasonlítani...
"Reflection is mindenre jó, de azért inkább a setter és getter."...
Azt hinni, hogy java-ban nincs operator overloading...
Priceless
> Azt hinni, hogy java-ban nincs operator overloading...
Van? (ha igen, akkor kérlek bővebben)
Nincs, my fault, csak c# volt a szemem előtt, aztán hirtelen felindulásból írtam :)
Ha szorszalhasogatunk, akkor van, csak beepitett (String osszefuzesre a '+'), csak sajatot nem lehet definialni.
igen :)
> Számít, hogy hány karaktert kell leírnod.
Amennyire látom, mindig ugyanannyit: egy CTRL+SPACE-t... (legalábbis Eclipse-t használva) :-)
Property be volt tervezve, de majd a következőben, ha jól sejtem. Ha nagyon zavar a getter/setter írása, használj lombok-ot
Operator overloading általában többet árt, mint használ
előjel nélküli tipus tényleg hiányzik néha, egyik megoldás az eggyel nagyobb elem használata
signal-slot observer pattern, semmi különbség nincs
A signal-slot annyiban kulturáltabb, hogy szebb talán a szintaxisa, egyébként tényleg ugyanaz.
Java-ban amúgy engem ez a listener írás mindig untatott, túl sok gépelés, és szerintem automatizálható lenne. Nincs az Eclipse-nek valami automatikus listener generálója? Eddig nem találtam, bár nem is nagyon néztem.
hianyzik meg a lancolta list is, mint nyelvi elem
--
NetBSD - Simplicity is prerequisite for reliability
Nem, mert annak rossz a szerkezete :)
Set/List/Enumeration nem jo?
Gondolom arról beszél, hogy kényelmetlen.
Integer i;
i = new Integer(1);
i = 1;
A két értékadás ugyanaz, de a régi java nyelvi szinten nem engedte meg az i=1 formát.
Van javaban minden, ami kell, de szervesen nem integrálódik bele. Az i=1 helyes változtatás volt, akkor is ha a fordító new Integer-re alakítja át.
Listák esetén valami
List<Integer> t = {1, 2, 3};
mélyebb integrációt jelentene, sőt műveleteket is engedhetnél metszet, különbség,..-ra. Kicsit körülményes jelenleg.
mr. malloc osztja az eszt :)
mar hogyne lehetett volna Integer i = 1 -et irni, 5ostol kezdve. autoboxing.
Kérlek olvasd el az eredeti hozzászólást, kedves gumicsont rágó.
Azt írtam a régi java. Utólag persze rájöttem, hogy nem írtam elég érthetően, mert valakik képtelenek gondolkozni, csak akkor örülnek, ha precízen megmondják nekik, hogy miről mit kell gondolniuk.
Szerintem a régi java-ba a 0.0000001-es verzió is belefér. Sajnálom NagyZ, nem tudok a szövegértési problémáidon segíteni. Rajtad kívül 20 másik ember megértette, talán akkor ne bennem keresd a hibát.
tehat a 7es bejelentese alatt beszeljunk a 4esrol. ertem. koszonom, leulhetsz.
Ha a Java neked túl bőbeszédű, használhatsz Scala-t:
val list = List("Java", "Scala" , "Groovy" , "NET");
Egy jó cikk induláshoz:
http://www.vogella.de/articles/Scala/article.html
Pont azon ügyeskedek hogyan lehetne mixelni egy projekten belül a Javat és a Scalat (a Scala támogatná ezt de az IDE-met még nem sikerült rávennem). Unalmasabb osztályokat én is inkább Scalaban írnám meg.
Sőt, ha Swingben fejlesztenék (neaggyisten) akkor tuti Scalat használnék:
http://stackoverflow.com/questions/1570175/scala-and-swing-gui-applications
En dolgozom ket olyan projekten, amiben van scala es java is es mukodesre lehet birni, de azt szurtem le, hogy kevesebb fejfajassal jarna, ha a ket projektre lenne szedve (egy scala hasznalo, egy java hasznalo). Eleg torekeny a build (command line + 2 IDE viszonylataban).
Szia, akkor nem adom fel :)
Bár nekem úgy tűnik hogy az Eclipse Scala pluginje elég béta. Teszek egy próbát az IDEA-val.
mondjuk javaban sem sokkal csúnyább:
ArrayList t = new ArrayList(Arrays.asList(1, 2, 3));
esetleg:
ArrayList t = new ArrayList() {{
add(1);
add(2);
add(3);
}};
Remelem tudod, hogy i=new Integer(1) es i=1 nem ugyanaz.
http://pastebin.com/hrCeBS9v
Ennek a kodnak az eredmenye szerinted micsoda es miert az, ami?
Ehhez még az Integer.valueOf()-t érdemes hozzátenni és akkor már az se lesz mindegy, hogy 1 vagy 128 (vagy amit a jvm-nek a user bekonfigurál) a paraméter.
Hagyd, nem kéne összezavarni mr. mallocot.
Ezért haragszom néha a Javára. Néha meg persze örülök neki, hogy ilyen.
:-)
De kezdőként (meg villamosmérnökként, aki inkább C-zni szokott (vagy azt sem, mert Verilogban hardverezik)), ez nagyon "felkavaró élmény" volt.
Bizony, hozzá kell szokni, hogy ez nem C. Mint ahogy a Javascript is inkább funkcionális nyelv, mint OOP. Szar dolog, meg nem is, hogy a szintakszis hasonló, de a szemantika sokszor eltér.
"Remelem tudod, hogy i=new Integer(1) es i=1 nem ugyanaz."
Szerintem ugyanaz.
.
Szerinted ugyanaz, a JVM szerint meg nem. A fenti kod eredmenye true es false. Mivel ket Integer(1) hivas ket kulonbozo Integer objektumot hoz letre, kulonbozik a referencia, ezert i == j hamis lesz, de a ket objektum tartalma ugyanaz, ezert i.equals(j) igaz lesz. Amikor new operatorral hozol letre uj Integer peldanyt, az garantaltan uj objektum lesz a heapen. Mig a literalok es a valueOf eseten egy konfiguralhato meretu cachebol jon minden peldany.
http://martykopka.blogspot.com/2010/07/all-about-java-integer-cache.html
Ezt akartam írni én is de nem voltam benne biztos hogy ez nem csak String-eknél van-e így. Köszi az olvasnivalót.
az immutable stringek azert mas teszta, mint az integercache
Mármint a String literal pool és az IntegerCache? Igen, eléggé más.. Köszönöm!
ket kedvenc kerdes amit lehet kerdezni interjun, ha valami komolyabb javas pozi van, az az IntegerCache, meg a PhantomReference -re ravezeto kerdeskor ("ha cachet kene irnod...", illetve GC viselkedes, miert nem jo a finalize).