[Javalist] nyomják krahácsot (romlik a jáva)
János Háber
janos.haber at javaportal.hu
2012. Május. 23., Sze, 15:13:03 CEST
Hi!
- hja, javalibeket csak par csapat tartja rendesen karban, szal +1
- Az alap javaban szerintem sem feltetlenul kellene tulkomplikalni a
dolgokat, arra ottvannak a javara epulo nyelvek
- Igen az okot szerintem mindenki tudja (marmint hogy miert kurvul
el), csak a megoldast nem tudja senki (mert vannak hasznos ujitasok,
de sok ba'ba kozt elvesz a gyerek)
b0c1
2012/5/23 Laszlo Hornyak <laszlo.hornyak at gmail.com>:
> 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
> _______________________________________________
> 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