Child pages
  • Java 7 vitafórum
Skip to end of metadata
Go to start of metadata

Ezek voltak a tegnapi Java7 vitafórum témái. Lehet folytatni!

Generikus típusok futásidőben

 if (list instanceof List<String>) { 
 ...
 }


Ez most nem fordul, pedig jó lenne ha ki lehetne deríteni futásidőben a generikus szerkezetek paramétereinek típusait.
Elvileg valami trükkel mégiscsak ki lehet szedni! Aki véletlenül tudja ezt a trükköt, ne tartsa magában!


Enum-ok ordinary értékei

Ha enum-okat definiálok, akkor az int reprezentációjuk mindig 0-tól egyesével növekszik, pedig jó lenne, ha kézzel meg lehetne adni értékeket. Pl. Utólag szeretnék beszúrni egy elemet középre. Ha simán beszúrom elcsúsznak az értékek mögötte. A program verziók nem lesznek kompatibilisek! Vagy egy meglévő rendszer konstansait szeretném beállítani az enum értékeinek.

Ez nem igazán zavart senkit, könnyen kiküszöbölhető. Pl. hibernate-ben nem a számértékeket, hanem a név-értékeket érdemes eltárolni.

Autoboxing NPE

Integer i = null;
int x = i


NullPointerException-t okoz. Tapasztalataim szerint nem könnyű észrevenni a fentinél kevésbé triviális helyzetekben.
Lehetne az NPE üzenetrészében legalább valami "autoboxing" vagy hasonló.

Ez sem zavart senkit.

Triviális kasztolások

 byte[] b = new byte[] {0xFF, 0xFF };
 byte[] b = new byte[] {(byte)0xFF, (byte)0xFF };


(Megj.: amikor alacsonyszintű Java-t programoztam (Embedded java) majdnem szétkapartam az arcomat kínomban emiatt.)

Más is találkozott már vele, ez van.

switch-be nem lehet String-et írni

switch (str) {
   case "ONE": return 1;
   case "TWO": return 2;
   case "THREE": return 3;
 }


Ezen elfilóztunk kicsit. A switch JVM utasítás belső szerkezete csak az int összehasonlításnak kedvez és tulajdonképpen egy függvénytáblát használ. Azért syntax sugar-nek meg lehetne csinálni. De akkor is, mikor használjunk equals-t és mikor ==-t?

Typedef

Ha sok helyen használunk egy adott generikus típust lehessen egy typedef-szerű dolgot megadni:

import java.util.Map<String, Integer> as CodeValueMap;


(Megj: Ha sok helyen használunk egy adott generikus típust, akkor akár külön osztályt is csinálhatunk rá.)

No way.

Rövidítés

Mi lenne, ha nem kellene kiírni a List-ben a get-et:

 List<String> list; ...
 String s = list.get(3000); helyett
 String s = list[3000]


vagy

 Map<String, Integer> map; ...
 Integer i = map["egy"];


(Mi lenne ha lenne operator overloading...)

Nem tartottuk fontosnak. Aki C#-ban akar programozni az programozzon C#-ban-ban.

Property-k

Van aki nem szeret gettereket írogatni.

public class Person {
  private String _forename;
  public property int age;
 }


(Megj.: Jobb IDE megírja öt kattintásra a gettereket. A fentinél bonyolultabb esetekben a property-knek is kell getter.)

Azért van aki mellette volt. Jobban belegondolva tényleg csak fölösleges "kódzaj" a sok getter és setter, azokban az esetekben, amikor úgyis csak beállítja-visszaadja a privát mező értékét.

BigDecimal, BigInteger

Kényelmetlen a használata: metódushívások helyett kényelmesebb lenne operátorokat használni.

 BigInteger sum = a.add(b.add(c.add(d))); helyett
 BigInteger sum = a + b + c + d;


Elvileg már tervezik.

XML support

Lehetne valami nyelvi szintű XML szolgáltatás, mint a Stringeknél.

Node n = <Person><Name>Joe</Name><Country>Netherlands</Country></Person>;


(Láttam valahol egy videót, ahol 45 percen keresztül taglalja a témát egy ipse.)

Gáznak tartottuk. Ha megtalálom a videót belinkelem majd / aki ismeri linkelje be.

Closures

Belső függvények, lokális függvények. Néha jól jönnének.

(http://tronicek.blogspot.com/2007/12/closures-closure-is-form-of-anonymous_28.html)

   public class SimpleClosure {
     public static void main(String[] args) {
       // function with no arguments;
       int answer = { => 42 }.invoke();
       System.out.println(answer);
     }
   }


(Megj.: ez nem valami jó példa.)

Szintén, aki Scala-ban akar programozni, programozzon Scala-ban.

KIVÉTELEK:

Multi-catch

Ha két kivétel catch ágában ugyanazt a kódot akarjuk használni, lehessen így egyszerűsíteni:

 try {
 } catch (IOException | SQLException ex) {
 }


(Megj.: ha kiemeljük metódusba a használandó kódot az is segít.)

És akkor mi az "ex" változó típusa...?

Checked exception: Szükséges?

Kemény téma volt mindig is.

Néha úgysem tudunk értelmes catch kódot írni.
Sok helyen látok üres (vagy ami még roszabb alibi) catch blokkot.
Mi lenne, ha a checked exception kezelésének kihagyása csak warningot eredményezne?

Jó az a checked exception.


Stacktrace

 row.getPerson().getAddress().getCity();

 java.lang.NullPointerException: 
     at myprogram.Main(Main.java:365)


Jó lenne tudni a soron belül hol történt a kivétel.

Ami null, annak kiírni a típusát, vagy a metódus nevét (Delphi csinálja így?).
Megadni valahogy, hogy mi kerüljön a stackTrace-be. Valakit zavarnak a hosszú stacktrace-ek is.
Egyébként le lehet cserélni az el-nem-kapott-exception kezelőt sajátra, ami azt csinál amit akarunk
a tömbben megkapott StackTraceElement-ekkel.


Egyebek

Több értékű visszatérési értékek. Egy metódus tudjon visszaadni több értéket. (Akkor már kimenő paraméterrel is megoldható.)
return type overloading. (Biztos sok további kérdést felvet.)
JVM lassú, modularizáció elkelne. El.
GC-hez közelebbi hozzáférés. Pl. cache-ek írásánál. Néha a WeakReference sem elég.
Appletek használhatatlanok. Majd a javaFX!
Dátumkezelés lassú. Már tervezik a javítást!
String ne legyen final. No way.
Minimalista API-k. (Már nem annyira jellemző.)

      
      
Page viewed times
#trackbackRdf ($trackbackUtils.getContentIdentifier($page) $page.title $trackbackUtils.getPingUrl($page))
  • No labels

13 Comments

  1. Üdv,

    Generikus típusok: A módszert Szuper Type Tokennek hívják. A lényege, hogy egy konkrét absztakt osztályról le lehet kérdezni a futás idejű generikus típusát: http://gafter.blogspot.com/2006/12/super-type-tokens.html

    Autoboxing NPE: használjuk a FindBugs-ot!

    XML Support: http://www.parleys.com/display/PARLEYS/Integrating+XML+into+the+Java+Language

    Multi Catch: A kivétel típusa a legközelebbi közös ős, vagy simán egy Throwable
  2. Itt vannak még összegyűjtve a Java 7 cuccok jól:
    http://tech.puredanger.com/java7
  3. A Java rovancs sorozat ezekről a dolgokról szól, de ideje lenne ismét egy hírnyit összegyűjtenem. :)
  4. > Szintén, aki Scala-ban akar programozni, programozzon Scala-ban.
    Vagy épp Fortressben. Azt hiszem az XML kezelés kivételével hasonlóak a megoldásaik. (És a felsoroltak kb felére már van megoldásuk.)
  5. A Fortress is JVM alapú nyelv?
    A Scala csak egy példa volt, mást is mondhattunk volna. (A Scala JVM alapú.)
  6. Igen, a Sun először JVMre készíti el a Fortress-t, bár ott is még csak interpretert írt. A Scala viszont nem -csak- JVM alapú. Az új változat Android és (régebb óta) .NET platformra is képes kódot generálni.
  7. Unknown User (crystal)

    Amit én nagyon hiányolok még a javából: jó lenne ha lehetne primitív típusokat logikai értékként használni úgy mint c-ben. Nem hiszem hogy olyan veszettül túlbonyolítja a kódot, inkább érdekessé teszi.
  8. Amit én nagyon hiányolok még a javából: jó lenne ha lehetne primitív típusokat logikai értékként használni úgy mint c-ben. Nem hiszem hogy olyan veszettül túlbonyolítja a kódot, inkább érdekessé teszi.

    Én inkább szeretném elfeledtetni a primitív típusokat is a nyelvből. De ehhez feljettebb autoboxingra lenne szükség, mert jelenleg tízszeres-hússzoros különbség is lehet futásidőben ha primitív típus helyett az osztályt használom... :)
  9. Ami engem illet, nekem kicsit az unionok hiányoznak. Vannak helyzetek, amikor elég hasznosak tudnak lenni. Persze lehet írni hasonlóan viselkedő osztályt, de a natív támogatás egyszerűbb és hatékonyabb lenne.
  10. Szerintem java-ban nem nagyon van rá szükség.

    Ugye a lényege, hogy egy változó többféle típusú értéket tud tárolni. C struktúrákban - ahol az adatok reprezentációja helyben kerül tárolásra a struktúrán belül - szükség van rá hogy megmondd milyen típusok lehetnek ott, mert eszerint allokálja a memóriát, méghozzá a legtöbb memóriát igénylő típushoz igazítva az igényt.

    Java-ban az atomi típusokon kívül minden referenciaként van tárolva, tehát ilyen allokációra nincs szükség ebből a szempontból.

    Egyébként pedig számos eszköz van rá, hogy unió-hoz hasonló funkcionalitást csinálj. Pl. Object-nek deklarálod a változót, vagy generikusokat használsz.

    De lehet hogy nem is erre gondoltál unió alatt?
  11. Én úgy hirtelen nem is tudok olyan feladatot, amely a C union viselkedésre építene. C esetén is csak a mikrovezérlők vagy a hardver programozásnál láttam értelmes felhasználását, amikor a beolvasott 16 vagy 32 bitet egy union struktúrával szét lehetett kapni 8 bites változókra.

    Biztos van ezen kívül hasznos felhasználása, de mi? :)
  12. Unknown User (kuvera)

    És ha ilyen alacsony szinten kell dolgozni, akkor szinte biztos, hogy C vagy JNI+C a megfelelő eszköz.
    Az int/long szétszedést bitmaszkokkal meg lehet oldani, más típusokat esetleg sorosítással és byte stream olvasással, de a Java igazán nem erre való.
  13. Crystal, szerintem ez rossz ötlet. Előre lépésnek tekintem, hogy eltűnt ez a lehetőség.
    Egyrészt nagyon megnehezítené a kódolvasást (a kódelemzőket azért könnyű lenne átírni, fejben nehezebb):
    Tényleg szeretnél ehhez hasonló kódot látni (nem biztos, hogy van értelme ;-))?

     int c = 0;
     for (int i = n; i >>=  1;)// ehelyett: (i >>= 1) != 0
     {
        ++c;
     }
     


    Másrészt matematikailag a két dolognak nincs közvetlen köze egymáshoz. Természetesen lehet leképezést végezni egyikből a másikba, de erre vannak már operátorok, lehet használni az == jelet, illetve a ?: operátort. :)
    (Persze lehet, hogy bennem van a hiba. Az implicit konverziók szerintem kissé áttekinthetetlenné teszik a kódot.)