[Javalist] nyomják krahácsot (romlik a jáva)

2012. Május. 23., Sze, 15:02:54 CEST

2012/5/23 János Háber <janos.haber at javaportal.hu>:
> Hi!
>
> 1. De akarunk, azert mert igy eltokolhetunk 2-3 napot hibakeresessel,
> es azt jol kifizetikmajd :D
> 2. Igen java nyelv kezd elkurvulni

Ez az elkurvulas szerintem annak az eredmenye, hogy az alternativ
nyelvek viszonylag sikeresek es a java megprobal minden feature-t
valamennyire behozni.

Hat az olvashatosagnak nem hasznal sajnos ez a sokminden. Meg hat amig
idaig volt egy viszonylag egyszeru eszkozkeszletunk, most egyre inkabb
komplexxe valik, amit egyre inkab nehez lesz hasznalni, illetve
ujrafelhasznalni.

En egesz jol meglennek az operatorok es a closure-k nelkul is, ez a
tobbszoros oroklodes meg technologiai maszturbacio az elejetol fogva.
Az sokkal szomorubb, hogy a java library-k egyre kevesbe vannak jol
karbantartva - szerintem.

> 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

-- 

EOF