Java SE 7

Java

"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:

  • Project Coin- many small language changes that add up to a big boost in productivity for developers
  • The Fork/Join Framework - facilitates parallelism for multi-core processors
  • The New File System API (NIO.2) - provides the ability to perform many basic file system operations natively
  • InvokeDynamic - makes it easier to run other languages on the JVM

A bejelentés elolvasható itt. Letöltés itt. További részletek itt.

( atomheart v | 2011. 07. 31., v – 12:09 )

"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$%#$#%^*^"

( kirsa74 | 2011. 07. 31., v – 12:30 )

Ritka sovany es szomoru feature lista az 5 evhez kepest. De majd Java 8-ban, 2023-ban! ;(

( bervi | 2011. 07. 31., v – 13:34 )

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! :)

( thebeast | 2011. 07. 31., v – 13:58 )

"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

( therion | 2011. 07. 31., v – 19:38 )

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.

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};

( uid_15426 | 2011. 08. 01., h – 08:54 )

//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++;

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).

( Csab | 2011. 08. 02., k – 01:02 )

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)
- ...

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!

:)

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.

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.

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.

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.

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-applicat…

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