[Javalist] nyomják krahácsot (romlik a jáva)
istvan.ketler at lhsystems.com
istvan.ketler at lhsystems.com
2012. Május. 23., Sze, 15:40:55 CEST
Ugye a java 1.1.7a még swing nélkül volt, az 1.1.7b meg már swinggel jött. Azóta "default" a swing. Valóban, ahogy egyre inkább webre tolódik a frontend, a swinget szerintem immár lehetne ismét opcionálisan letölthető APIvá tenni, felesleges immár a JRE-ben (2D-stül).
A JSF és társai meg szerintem csak egy extra problémát hoznak be a frontendre, akkor már egyszerűbb direktben JavaScript frontendet írni. Vannak ma már nagyon jó erre szolgáló keretrendszerek (az ext.js csak egy a sok közül), amelyek szinte a swing tudását adják (és elrejtik a div-eket meg a böngészőt). Amiben egyelőre biztosan bénák, az jelenleg a dokumentáltság, és a kompatibilitás. A legtöbb fejlődik, és durván változik néha még minor release-ek között is, illetve egy csomó fícsör csak a forráskódból bogarászható ki (esetleg egy-két blogposztból), mert a doksiból nem. A mai drótvastagság mellett meg a néhány megás forrásfájlok teljesen beleférnek, századmásodperceket jelentenek csak.
Szóvak kicsit olyan érzésem van, hogy a jávát egyre inkább olyasmire akarják/akarjuk használni, amire valójában nem lenne való. A bonyolultság és komplexitás növelésével meg a nagyobb fejlesztő cégek egyre inkább az alternatívák felé fognak fordulni, mert nekik a kód karbantarthatóság és a csereszabatos fejlesztők alapvető, és legnagyobb súlyú követelmények. Szóval azzal, hogy a jáva megpróbál egyszerre minden lenni, szerintem maga alatt vágja a fát. Ami a világon mindenre jó, az valójában teljesen használhatatlan, mert semmit nem tud jól, inkább mindent valahogyan.
István Ketler
Senior Consultant
Lufthansa Systems Hungaria Kft.
Development Center Pest
Neumann János u. 1/e
1117 Budapest
Hungary
Tel: +36 1 887-2815
Fax: +36 1 887-2977
Mobile: +36 30 600-4936
Room: Infopark E, Room LH2-24
e-mail: istvan.ketler at lhsystems.com
Internet: www.LHsystems.hu
Sitz der Gesellschaft / Corporate Headquarters: Lufthansa Systems Hungaria Kft, Budapest, Fövarosi Birosag 01-09-463417
Geschaeftsfuehrung / Management Board: Monika Houck
-----Original Message-----
From: javalist-bounces at lists.javaforum.hu [mailto:javalist-bounces at lists.javaforum.hu] On Behalf Of János Háber
Sent: Wednesday, May 23, 2012 2:57 PM
To: Java lista
Subject: Re: [Javalist] nyomják krahácsot (romlik a jáva)
Hi!
1. De akarunk, azert mert igy eltokolhetunk 2-3 napot hibakeresessel, es azt jol kifizetikmajd :D 2. Igen java nyelv kezd elkurvulni 3. Nekem nincs semmi bajom az operator overloadingal. Scala-t pl imadom (reszben emiatt, reszben meg kicsit olyan mint egy tipusos ruby
:) , csak nembiztos hogy ezt java szintre le kell vinni.
4. java (es hajtasai: scala, groovy, etc...) szvsz eddigis szerver oldalra voltak valok (deszepenmegmondtam). De komolyan, eltekintve nehany ifjonti kicsapongastol (amikor pl java applet-et irtam), a java helye szamomra mindig is szerver oldalon volt. Szerintem erre tokeletes es pont. Lehet persze eclipse RPC-n alkalmazast fejleszteni (igen en is szeretem, de csak mint FEJLESZTO).
5. Amennyiben GUI reszt levalasztjak vegre javarol es maga JRE merete nem haladja meg a 10m-t. ugy lehet 4-es pontot majd felulvizsgalom :)
Peter: Gondolom ha a @CacheListener nem annotacio lenne, hanem egy interface amit implemental, esakkor mindjart implementalhatna is egy nodeEvent meg egy cacheEvent metodust (ami kicsit leiro jelleguen, pl elmeseli hogy az elso (vagy epp egyetlen) parameternek mi a tipusa, es nem dokumentacioban kell nezegetni)
b0c1
2012/5/23 Böszörményi Péter <zmblevlist at gmail.com>:
> Megkerdeznem forditva. Szerinted a lentebbi kod hogyan lenne normalis?
>
>
> On Wed, 23 May 2012 14:27:57 +0200, <istvan.ketler at lhsystems.com> wrote:
>
>> Elolvasva egy csomó hozzászólást, kicsit azért úgy érzem hogy a
>> problémák egy része mű. Ha eddig volt két interfészed, amelyekben
>> volt azonos signatúrájú metódus, akkor az implementáló osztály
>> felelőssége volt azt megoldani, hogy mindkét interfész számára érvényes megoldást implementáljon.
>> Most ha mindkettőben van default, akkor valszeg pontosan ugyanezt
>> kell tenni (és akkor gondolom a fordító nem siránkozik az ütközés
>> miatt). Szóval mi változott? Szerintem ilyen értelemben semmi, csak
>> lett egy új, az esetek 99%-ában használható lehetőség.
>>
>> Ugyanakkor azt is gondolom, hogy a Java egyre betegebb lesz. Szép,
>> tiszta volt, fordítási időben egy csomó problémát megtalált. Erre
>> jöttek először az annotációk, szétcsatolások, amik fordítási időben
>> már nehezen megfoghatók, és most halad tovább a lejtőn a C++
>> irányába. A java 9-ben gondolom már lesz operator overloading is...
>> Mondjuk látom az előnyét ennek a default törzsnek, és jutott már
>> eszembe korábban hogy de jó volna egy ilyen, de kicsit szebb, jobban
>> átgondolt tervezéssel meg tudtam oldani a problémát jávásan is. Most majd nem kell szépre tervezni, rondán is megoldható lesz...
>> :)
>>
>> Vagy vegyük a globális változót. Ez ugye kerülendő, legyen a változó
>> privát. Adjunk ezért az osztályhoz gettert meg settert, és nem
>> egyenlőségjellel módosítjuk, hanem metódussal. Kicsit jobb, mert
>> ellenőrizni lehet. Pontosabban lehetne, mert 99%-ban senki nem
>> ellenőriz, a setter sima értékadássá degradálódott. Ha már így van,
>> ne kelljen annyit gépelni, jöjjön a @get és @set annotáció a változó
>> deklaráció elé, és majd a fordító legenerálja a default gettert és
>> settert. Na de akkor már miért ne legyen globális az a szerencsétlen
>> változó, hiszen úgyis kitettük már a kirakatba típussal, mindennel
>> együtt... Csak mert az "nem OO"? Hát szerintem a nyakló nélkül használt getter és setter sem az...
>>
>> A fejlesztések háromnegyede ugye már most is webes, a gwt, icefaces
>> és társai pedig azért elég macerásak. Javascriptben, vagy - horribile
>> dictu - php-ban sokkal gyorsabban össze lehet kalapálni egy
>> frontendet (és ma már kellően jól karbantartható is a javascript, ha
>> normális programozó írja), a javanak meg, ha így rondul tovább (és
>> romlik vele a karbantarthatósága), majd marad a middleware (még egy
>> darabig, mert pl. a javascript már ott is nyomul). A jávás ejb
>> programok egyre nehezebben karbantarthatók, egyre bonyolultabbak,
>> egyre több tudás kell a működés megértéséhez - ergo valószínűleg el fognak fordulni tőle előbb-utóbb valami könnyebb irányába.
>>
>> Szerintetek ez például egy normális jáva kód? Ki a rossz nyavaja akar
>> ilyet karbantartani?
>>
>> @CacheListener
>> public class MyListener
>> {
>>
>> @CacheStarted
>> @CacheStopped
>> public void cacheStartStopEvent(Event e)
>> {
>> switch (e.getType())
>> {
>> case Event.Type.CACHE_STARTED:
>> System.out.println("Cache has started");
>> break;
>> case Event.Type.CACHE_STOPPED:
>> System.out.println("Cache has stopped");
>> break;
>> }
>> }
>>
>> @NodeCreated
>> @NodeRemoved
>> @NodeVisited
>> @NodeModified
>> @NodeMoved
>> public void logNodeEvent(NodeEvent ne)
>> {
>> log("An event on node " + ne.getFqn() + " has occured");
>> }
>> }
>>
>> Üdvözlettel,
>>
>> Iván
>>
>> István Ketler
>> Senior Consultant
>> Lufthansa Systems Hungaria Kft.
>> Development Center Pest
>> Neumann János u. 1/e
>> 1117 Budapest
>> Hungary
>> Tel: +36 1 887-2815
>> Fax: +36 1 887-2977
>> Mobile: +36 30 600-4936
>> Room: Infopark E, Room LH2-24
>> e-mail: istvan.ketler at lhsystems.com
>> Internet: www.LHsystems.hu
>>
>>
>>
>> Sitz der Gesellschaft / Corporate Headquarters: Lufthansa Systems
>> Hungaria Kft, Budapest, Fövarosi Birosag 01-09-463417
>> Geschaeftsfuehrung / Management Board: Monika Houck
>>
>> -----Original Message-----
>>
>> From: javalist-bounces at lists.javaforum.hu
>> [mailto:javalist-bounces at lists.javaforum.hu] On Behalf Of Auth Gábor
>> Sent: Tuesday, May 22, 2012 11:12 PM
>> To: javalist at lists.javaforum.hu
>> Subject: [Javalist] Java8 - Alapértelmezett metódustörzs
>> interfészekben
>>
>> Hi,
>>
>> http://wiki.javaforum.hu/pages/viewpage.action?pageId=21103888
>> --
>> http://www.javaforum.hu -=- http://www.enaplo.hu Auth Gábor -=-
>> http://www.javaforum.hu/web/10/authgabor
>> _______________________________________________
>> Javalist mailing list
>> Javalist at lists.javaforum.hu
>> http://lists.javaforum.hu/mailman/listinfo/javalist
>> _______________________________________________
>> Javalist mailing list
>> Javalist at lists.javaforum.hu
>> http://lists.javaforum.hu/mailman/listinfo/javalist
>>
>
>
> --
> Üdvözlettel,
> Böszörményi Péter
>
> _______________________________________________
> Javalist mailing list
> Javalist at lists.javaforum.hu
> http://lists.javaforum.hu/mailman/listinfo/javalist
_______________________________________________
Javalist mailing list
Javalist at lists.javaforum.hu
http://lists.javaforum.hu/mailman/listinfo/javalist
További információk a(z) Javalist levelezőlistáról