Mi lesz veled Java?
2010-01-25T13:15:16+01:00
2010-02-04T11:25:28+01:00
2022-07-25T06:57:36+02:00
  • Talan nem ott...
    Mutasd a teljes hozzászólást!
  • Talán itt válasz a topikra, itt.
    Mutasd a teljes hozzászólást!
  • Nem konkrétan language feature, de szvsz a témába illő:
    Lemondott a SUN CEO-ja
    The reasons for Schwartz’s resignation were more or less known from before; recently, Oracle has acquired Sun, and Oracle CEO Larry Ellison said in an interview last week he expects Schwartz to resign
    Mutasd a teljes hozzászólást!
  • Szerintem ha már az ember dolgozik egy adott programozási nyelvben akkor igen is vegye a fáradságot és legyen tisztában az alap dolgokkal amit sokan egyszerűen átlapoznak és egyből ott nyitják ki a könyvet hogy hogyan kell felületet készíteni a programhoz.
    Véleményem szerint ha valaki dolgozik egy adott programozási nyelvvel akkor legyen tisztában annak típusaival, eszközrendszerével, a kifejezések kiértékelésével, a precedencia táblázattal, vezérlési szerkezetekkel, paraméterátadással és satöbbi. Nekem is van olyan kollégám aki előttem 3 évvel kezdett el C#-al foglalkozni és én magyarázgatom neki a paraméter átadást... És őszintén szólva az ilyesmitől a frász kerülget.

    Amúgy hogy ne legyek offtopic, engem is érdekel hogy merre megy a java. Én valamikor az 1.5-1.6 környékén használtam utoljára akkor is nagyon kicsi feladatokhoz.
    Szerintem a javanak a legnagyobb előnye egyben a legnagyobb hátránya: az, hogy a community-nek nevezhető cloud rengeteg dolgot megcsinált hozzá. Nincs egy egységes nézet hogy merre indulj el ha mondjuk webes alkalmazást kell készítened. Még az alkalmazás szerver kiválasztása esetében egy kisebb állatkertnyi lehetőséged van és jó dolog a választás szabadsága de ilyenkor a linuxok jutnak az eszembe. Az alapja mindegyiknek ugyanaz de próbáljon meg egy közepes ismeretekkel rendelkező ember bekonfigolni egy fedorát miután csak az ubuntuhoz értett előtte. És ez csak két disztrib a megszámlálhatatlan között...


    Morzel
    Mutasd a teljes hozzászólást!
  • A signed / unsigned dolog tényleg sokkal bonyolultabb mint hiszed.

    Ez még messze nem a bonyolult kategória. A helyzet az, hogy van egy csomó algoritmus, ami unsigned intekkel működik, ahol az előjelnek semmi keresnivalója nincsen. Fusztráló dolog, hogy nincs a programozónak szabadsága ezekkel dolgozni. Sokszor egyszerűen azt csinálom, hogy a signed integert egyszerűen a 'fejemben' unsigned-nak tekintem, mert hálistennek az összeadás műveletet végülis nem érdekli, hogy kettes komplemens formájú előjeles, vagy nem előjeles számot adok neki. Aztán kiíratásnál meg ki tudom íratni az előjeles, kettes komplemenses számot, mint nem előjeles szám. Pl. -1-et mint 0xFFFFFFFF Szóval legtöbbször megoldható a dolog, csak ronda. De pl. van, amikor ez nem megy, mert pl. a szorzás már másképp működik előjelesen és nem előjelesen. (Természetesen minden processzornak van rá külön utasítása.) Vagypl. az összehasonlítás is másképp működik.

    Ha kevered a kettőt, a nyelv megoldhatja explicit cast nékül fordítási hibával, és akkor nincs hard to find bug, vagy azonnali signed-ra konverzióval. Azon lehet vitatkozni, hogy most hibaüzenet legyen-e, vagy nem, de hogy egyáltalán nincs unsigned, az szerintem igénytelenség.

    Szvsz. az unsigned int advanced feature, kezdők úgysem használnák. Akinek viszont kell az algoritmusához annak meg fusztráló, hogy nincs. Nyilván e miatt az egyetlen kis apróság miatt önmagában az ember nem fordít hátat a nyelvnek, de idegesítő, mert nem hiszem, hogy olyan nagy dolog lett volna beletenni.
    Mutasd a teljes hozzászólást!
  • - int32 + uint32 esetén mindkét tagot konvertálja int64-re. Ugyanez a lifting történik meg összehasonításkor.
    - int64 + uint64 illetve összehasonlításuk fordítási hibát okoz. Bármelyiket castolod a másik típusra, úgy már jó. Vagyis nagy disznóságot csak "ráutaló magatartással" lehet csinálni.

    Vagyis a lenti kódod eredménye korrektül 1, true lenne, ha a kiindulási típusok 32-bitesek és fordítási hiba, ha 64-bitesek.
    Mutasd a teljes hozzászólást!
  • Szerintem szégyen, hogy ennyire hülyének nézik a Java programozókat.


    A signed / unsigned dolog tényleg sokkal bonyolultabb mint hiszed. Egész pontosan akkor van gond, ha vegyíted a kettőt.

    signed int a = -1; unsigned int b = 2; printf("%d\n", a + b); printf("%s\n", a < b ? "true" : "false"); 1 false

    Ez a kód egész addig jól működik, amíg a-ba csak pozitív számot teszel. Utána meg jönnek a hard-to-find bugok.

    Azt nem tudom, hogy C#-ban hogy oldották meg ezeket a problémákat (ha egyáltalán megoldották)


    Mutasd a teljes hozzászólást!

  • A nyelv egyik architektje nő, szóval érthető valahol.


    You know, it has to be blonde and user friendly
    Mutasd a teljes hozzászólást!

  • Ha valaki találkozik Larry Ellison-nal, mondja már meg neki, hogy nagyon gyorsan tegye bele a JAva-ba az unsigned int-et.


    Azt mondta, beszelj Tom Kuriannal.
    Mutasd a teljes hozzászólást!
  • Ez az unsigned dolog nálunk sem kerek. Ugyanis nem CLS Compilant, vagyis, ha unsigned van a publikus homlokzaton egy libben, akkor nincs rá garancia, hogy minden CLS nyelv meg tudja hívni a libet. Tehát az unsigned támogatása nyelvspecifikus, a közös szabványban nincs benne.

    Mé? Idióta dolog, de komolyan ezt nyilatkozták az illetékesek:

    Egyik bajszos géniusz Redmondból:
    - A VB.NET-ben azért nincs unsigned, mert az nem CLS (common lang. spec.) kompatibilis.

    Másik bajszos géniusz szintént Redmondból, csak 2 irodával odébb:
    - Az unsigned azért nem lett benne a CLS-ben, mert a VB.NET nem támogatja.

    Halál komolyan. Há' nooormális? Igazából a VB.NET körül a kezdetektől ekkora lámerkedések mennek, és ez a mai napig semmit sem változott. A nyelv egyik architektje nő, szóval érthető valahol.
    Mutasd a teljes hozzászólást!
  • Egyébként kimaradt még egy dolog, ami nagyon nagyon hiányzik a Java-ból (és engem marhára idegesít): az unsigned típusok hiánya. Tényleg semmiből nem tartana támogatni, minden processzor tudja, de a Java elveszi a programozók elől.
    Az, hogy nincs unsafe, meg nincs yield return, meg hogy type erasure-vel megy a generic, az még ok, hát izé, nehéz lett volna beletenni... de hogy nincs unsigned int az tényleg szégyen.

    Sajnos úgy tűnik, hogy Gosling azért nem tette bele, mert a programozók szerinte úgyse értenék.

    > Q: Programmers often talk about the advantages and disadvantages of
    > programming in a "simple language." What does that phrase mean to
    > you, and is [C/C++/Java] a simple language in your view?
    >
    > Ritchie: [deleted for brevity]
    >
    > Stroustrup: [deleted for brevity]
    >
    > Gosling: For me as a language designer, which I don't really count
    > myself as these days, what "simple" really ended up meaning was could
    > I expect J. Random Developer to hold the spec in his head. That
    > definition says that, for instance, Java isn't -- and in fact a lot of
    > these languages end up with a lot of corner cases, things that nobody
    > really understands. Quiz any C developer about unsigned, and pretty
    > soon you discover that almost no C developers actually understand what
    > goes on with unsigned, what unsigned arithmetic is. Things like that
    > made C complex. The language part of Java is, I think, pretty
    > simple. The libraries you have to look up.


    Szerintem szégyen, hogy ennyire hülyének nézik a Java programozókat. Ha nem lenne az a rengeteg osztálykönyvtár, amit szeretek a JAva-ban, ha nem lenne szempont, hogy a Java annyi platformon fut, stb... és csak magát a nyelvet kellene nézni, akkor nem kérdés, hogy váltanék C#-ra.

    Ha valaki találkozik Larry Ellison-nal, mondja már meg neki, hogy nagyon gyorsan tegye bele a JAva-ba az unsigned int-et.
    Mutasd a teljes hozzászólást!
  • Rengeteg kenyelmi funkcio volt, ami nem kerult be.

    Ezek kozul az egyik leghasznosabb dolog szerintem a catch (final Exception ...) altali garanciak kihasznalasa:

    public void throwSubclassExceptions() throws SubclassException1, SubclassException2 { ... } ... public void caller() throws SubclassException1, SubclassException2 { try { throwSubclassExceptions(); } catch (final SuperclassException e) { throw e; } }

    ahol SubclassException1 es SubclassException2 a SuperclassException leszarmazottja.

    Eddigi Java verziokban ez ugye panaszkodik hogy deklaralni kell a SuperclassException-t a throws clause-ban vagy el kell kapni.

    Az uj feature utan, a fenti kod fordulna, mivel e final igy csak olyan lehet ami a blokk belsejebol hajitva volt, azok pedig deklaralva vannak.

    A tobbi uj feature-re gugli...

    Mutasd a teljes hozzászólást!
  • Erre a problémára találták fel a ZX-Spectrum emulátort
    A Z80 amúgy is minden idők legjobb processzora
    Mutasd a teljes hozzászólást!
  • amit eredetileg javasoltak Java7-be.


    Miket?
    Mutasd a teljes hozzászólást!
  • OFF

    Akkor írjál olyan asm kódot ami fut windowson (x86, ia64), osx-en (x86), powerpc-n és sparcon.


    Amúgy nem a vitához kapcsolódva, csak érdekességként írom, hogy az LLVM már kb. ez a szint. Nem vagyok a téma szakértője, meg az LLVM-ről is csak felszínes ismereteim vannak, de az LLVM az általam ismert legalacsonyabb szintű cucc, ami multiplatform. (Ez pl. a C nyelvnél is alacsonyabb szint, és amennyire persze meg tudom ítélni a JAva bytekódnál (és gondolom a .NET CLR-nél is) is alacsonyabb szint.)

    Multiplatform alatt itt azt értem, hogy támogatja a következőket: X86, X86-64, PowerPC, PowerPC-64, ARM, Thumb, SPARC, Alpha, CellSPU, PIC16 MIPS, MSP430, SystemZ, és XCore.

    Mondjuk nagyon durva lenne, ha élő ember direktben ebben kódolna. (Nem is arra találták ki nyilván.)

    ON
    Mutasd a teljes hozzászólást!
  • Es melle meg kepes a Java/.NET altal menedzselt adatstrukturakkal egyuttmukodni...
    Mutasd a teljes hozzászólást!
  • Akkor írjál olyan asm kódot ami fut windowson (x86, ia64), osx-en (x86), powerpc-n és sparcon.
    Mutasd a teljes hozzászólást!
  • Hat, majd meglatjuk.

    Az a baj, hogy relative rossz idopontban vagyunk, a Java 7 folyamatosan csuszik, nemreg lett meg egy evvel eltolva (idei ev vegeig), ugyhogy nem hiszem hogy meg egy evet tolnanak rajta.

    Viszont ebbe a kis idobe mar nem biztos hogy minden bele fog ferni abbol sem amit eredetileg javasoltak Java7-be. Remelem azok kozul a lenyegesebbeket mostmar belesuvasztjak.

    De inkabb a Java 8-al kapcsolatban legyenek remenyeid, az viszont ki tudja meg mikor jon.

    A Generics-et szinte biztosra veszem hogy nem fogjak megreformalni.

    A struct[] jellegu dolgokat en nagyon birnam, ok lehet hogy kevesbe, bar nyilvan bele lehetne illeszteni a nyelvbe valahogy, ha mast nem, egy uj operatorral, bar ettol szerintem falnak mennenek.

    Remenykedjunk...


    Mutasd a teljes hozzászólást!
  • Ja. Az assembly a legjobb a világon. Elvégre minden célra megfelel. Amit nem lehet assemblyben megírni azt nem lehet megírni.
    Mutasd a teljes hozzászólást!
  • Tudom, hogy a Javanak nem elsődleges célja, hogy az ilyen alacsonyszintű optimalizációkat meg lehessen vele valósítani,


    Ha jobban megnézed, az elsődleges célja hogy NE lehessen ilyen alacsonyszintű optimalizációkat megvalósítani.
    Egyrészt az alacsonyabb szintű kód, kevésbé hordozható. A C# nativ mem kezeléssel pillanatok alatt bele tudsz futni olyanba ami egy littleendian gépen megy, de bigendian-on nem.

    Egy olyan nyelvben amit elsősorban nagyvállalati környezetben használnak, egyáltalán nincs helye ilyennek.
    Azt senki nem vitatja hogy a c#-ban sokkal több a feature, azt se hogy a java-ból nem hiányzik semmi, de a nyelv nem ettől lesz jó.
    Attól lesz jó, hogy a célnak megfelel. A kevesebb néha több.

    Én egy olyan cégnél dolgozom, ahol még mindig használnak java 1.1-et, és nem azért mert olyan jó lenne, hanem mert a tulajdonosnak megfelel, és nem akar pénzt költeni az upgradre.
    Mutasd a teljes hozzászólást!
  • Ez az egyetlen baj a Java-val, ha engem kérdezel. Mindent tud, csak "kicsivel" (khm) többet kell hozzá dolgozni. Ez a SUN impotenciájából adódik szerintem. Már régestelen rég meg kellett volna reformálni a JVM-et. Remélhetőleg az Ora ráfekszik, és akkor (újra) lesz versenytársa a .NET-nek kliensen is, és így nem merik többet megcsinálni azt a trehány, elbarmolt, széjjelszabott, megveszekedett, félidióta, arcátlan parasztvakítást, amit a .NET 3.x-szel műveltek.

    Szóval hajrá Java! Hajrá Oracle!
    Mutasd a teljes hozzászólást!
  • Valo igaz, nem tudsz ra definialni egy struct-ot egy memoriateruletre.

    Ettol fuggetlenul egyes primitiveket el tudsz erni. Kicsit tobbet kell dolgozni

    Mindenesetre (memoriahasznalat szempontjabol) egesz kellemes Struct[] implementaciot lehet vele csinalni
    Mutasd a teljes hozzászólást!
  • Nincs C++ féle pointer és azok operátorai + nincs struktúra kezelés, lévén olyan, hogy struktúra nincs is Java-ban, így nem tudsz olyan konstrukciót létrehozni, mint egy acc. struct.

    SZERK.: Bár meg lehet vele csinálni, ahogy látom, mert meg lehet adni eltolási címeket. Bár így igen-igen marha nehéz megvalósítani, mert minden struktúra tagnak kell tudni a relatív címét, plusz ha beágyazott struktúrák vannak (acc. struct.-ban lesznek), akkor még nehezebb a címet kiszámolni. Szóval van ez, ugyan úgy, mint az iterátor, csak mivel nincs hozzá nyelvi támogatás, kész kisregényeket kell írni a legegyszerűbb használatához is.
    Mutasd a teljes hozzászólást!
  • sun.misc.Unsafe megfelel?
    Mutasd a teljes hozzászólást!
  • Volt már olyan sebességkritikus cucc, hogy nagyon jó lett volna, ha Java-ban egy memóriaterületet szabadon elérhettem volna: amikor valamit célszerű ugyan byte tömbként tárolni, de belőle bizonyos pozíciókon 32 bites integereket akarok kiolvasni, akkor szégyenletesen a byte-okból shiftelgetéssel és összeadásokkal kell kinyerni az integert-, ami nagyon béna a sima C-s int-re castolós eléréshez képest.


    Igen, ez létező dolog. Pl. a WPF belül unsafe módban kezeli a bitmap buffereket. Sőt, odáig megy, hogy maga az API is támogatja az IntPtr alapú képbufferezési kód megírását, van erre metódus, egyenesen ez a javasolt eljárási módszer C# alatt. Unsafe nélkül lehetetlen lett volna megoldani, amit a WPF tud, maximum egy natív C++ API-ra támaszkodva. Egyébként van ilyen a rendszermagban, de annak csak az a feladata, hogy biztosítsa a Direct3D - .NET marshalt.

    Mikor real_hettel nyomtuk a natív vs managed compot, akkor is teljesen memóriában turkálással - a WPF beépített lehetőségein keresztül - oldottam meg, hogy megközelítőleg egálban tudjak lenni sebességben a natív kóddal.

    Szvsz van az Ora olyan elvetemült, hogy csinál egy új JVM specifikációt, ami minden olyasmit tudni fog, ami ma még hiányzik a dologból a CLR-hez képest. Ez nem mehet a backward kompatibilitás kárára, lévén az MS is meg tudta oldani, hogy a .NET 4 (CLR4) zokszó nélkül tudja hívni a legacy DLL-eket és simán fordítja akár a C# 1.0-s kódot.
    Mutasd a teljes hozzászólást!
  • byte-okból shiftelgetéssel és összeadásokkal kell kinyerni

    És pesze a legdurvább hogy így 4 range-checkingem van.
    Mutasd a teljes hozzászólást!
  • Például raytracerekhez egy lehetséges acc. struct. a BVH Traversal. Ennek C# unsafe implementációja csak néhány órajelciklussal több mint a C++, mert a bejárás elején és a végén szólni kell a GC-nek, hogy pinnelje a tömböt.

    Tudom, hogy a Javanak nem elsődleges célja, hogy az ilyen alacsonyszintű optimalizációkat meg lehessen vele valósítani, nagyon nem, viszont rengeteg Java alapú matematikai/mest.int. lib létezik, ami sokkal-sokkal gyorsabb is lehetne, ha a JVM nyújtana lehetőséget a memóriában turkálásra is.

    Ha Javaznék, akkor tuti írnék az Oracle future Java feature request fórumra, hogy legyen ilyen is a JVM vNext-ben.
    Mutasd a teljes hozzászólást!
  • Igen, az unsafere is kicsit írígykedve nézek, amikor a C#-ot nézem.
    Nem tudom pontosan, hogy miket lehet csinálni unsafe-ben, ennyire nem ismerem a C#-ot, de feltétlezem, hogy szabadon elérhetek egy memóriaterületet, mintha csak C-ben lennék.

    Volt már olyan sebességkritikus cucc, hogy nagyon jó lett volna, ha Java-ban egy memóriaterületet szabadon elérhettem volna: amikor valamit célszerű ugyan byte tömbként tárolni, de belőle bizonyos pozíciókon 32 bites integereket akarok kiolvasni, akkor szégyenletesen a byte-okból shiftelgetéssel és összeadásokkal kell kinyerni az integert-, ami nagyon béna a sima C-s int-re castolós eléréshez képest.

    Rosszul is aludnék, ha nem lenne JNI (Java Native Interface). Ugyan még nem került sor rá, hogy használjam, de ha nagyon nagy gáz van, akkor legrosszabb esetben kisebb részeket megírhatnék C-ben JNI-n keresztül elérve. (Bár a JNI-be való átváltásnak is biztos van időköltsége, utána kellene néznem, hogy mennyi...)
    Mutasd a teljes hozzászólást!
  • Egy dolog van, amivel a Java nem rendelkezik, és rengeteget lehet gyorsítani az ilyen nagy számítási igényű programokon: az unsafe. NN bejáráshoz írtam unsafe acc. struct.-ot, amivel a számítás 1.5x gyorsabb lett. Aki ismeri az acc. struct.-okat, az tudja, hogy mit a lényege: a szekvenciális memóriában ugrálással lehet bejárni egész komoly és összetett adatszerkezeteket (pl NN irányított gráf), és a legnagyobb előnye, hogy a bejárás és a műveletvégzéshez szükséges információ a struktúra tömmben van, pointerekkel elérhető, egy darab memóriaszekvencia, így jó esélyell az egész művelet menni fog CPU cache-ből. Ha az eredeti adatszekezetet kéne bejárni, akkor a referenciák miatt 100%, hogy nem jön ki a cache lefedettség, plusz az indirekt hivatkozások és a range checking kódja is tovább lassít az acc. struct. bejáráshoz képest.

    Vagy van már valami unsafe Java-ban is? Tervezik?
    Mutasd a teljes hozzászólást!
  • Én csak azt mondom, hogy ha egy nyelvben nincs iterátor, akkor nem lesz ám az olyan magától értetődő dolog


    Aláírom, hogy többet kell szenvedni ha nincsen néhány cool dolog (pl yield return), de én, ha nagyon kell, akkor inkább szenvedek. Ha ritkán nagyon kell optimalizálni én annyira átrágom magamban a feladatot, hogy már általában a ciklusmag leredukálódik valami kikerülhetetlen iparszerű számolástengerré valami nagy tömbön végigmenve, vagy ilyesmi (ami szinte nyelvfüggetlen sebességű, eltekintve a managed nyelvek tömbindex check-jétől.) Nagyon nagy szégyennek tartanám legalábbis, ha az optimalizált kódomat 18-szorosára lehetne gyorsítani. (Szerintem nem mernék kimenni az utcára pár hónapig.)

    Az egészet egyébként csak azért tartom fontosnak, mert ez azért más jellegű, mint pl. a JAvascript és más típusnélküli/hiperdinamikus nyelvek lassúsága: Ott ha akarsz sem tudsz gyors kódot írni. Egyszerűen olyan a nyelv alaptermészete, hogy nem lehet igazán gyors kódot csinálni belőlük, a sok runtime csekkelés elkerülhetetlensége miatt. Egy kicsit követtem, hogy mit műveltek pl. a Google Chrome Javascript interpreterében: eszméletlen trükköket vetnek be, hogy nagyobb legyen a sebesség, de még így is lehetetlen elérni az erősen típusos nyelvek szintjét.
    Mutasd a teljes hozzászólást!
abcd