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

János Háber janos.haber at javaportal.hu
2012. Május. 23., Sze, 14:56:41 CEST


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


További információk a(z) Javalist levelezőlistáról