[Javalist] nyomják krahácsot (romlik a jáva)
Böszörményi Péter
zmblevlist at gmail.com
2012. Május. 23., Sze, 16:36:30 CEST
Erdekes gondolat. En szemely szerint nem feltetlen a rovid, hanem inkabb a
konnyen hasznalhato, es konnyen megertheto megoldasokat kedvelem. A
REST-es peldanal maradva, egy jetty, egy spring, es egy cxf harmas ezt
teljesen jol tudja hozni. Valoban nem lesz annyira rovid, mint amit itt
mutattal, de egy kicsike odafigyelessel jol ossze lehet fogni az ossze
tartozo dolgokat(bootstap kod, szerver konfig, cxf konfig, REST vegpont).
A JAX-RS se egy bonyolult dolog, igaz megjelenik az a problema, amit elso
korben irtal.
Szoval azert - szerintem - javaban is vannak konnyen hasznalhato eszkozok,
csak eppen nem out of the box, de en ezt nem is banom.
On Wed, 23 May 2012 15:15:58 +0200, <istvan.ketler at lhsystems.com> wrote:
> Pedig mennyivel jobb lenne, ha a java az "out of the box" megoldásokra
> összpontosítana inkább. node.js használatával max. 15 sorban beüzemelek
> egy web szervert (express), amit ext.js esetén mondjuk REST
> kommunikációval további 15 sor leírásával meg tudok szólítani (node az
> autentikációt, session kezelést, stb. is tudja adni), és adatokat tudok
> behúzni róla. Semmit nem kell törődnöm hibakezeléssel, egyebekkel,
> mindent megold. Persze ha szebb viselkedést akarok, még mindig
> elfoghatom a hibát, és kezdhetek vele valamit. Hol van ettől a jáva?
>
> Ennyi a frontend oldalon a kérés definíciója (becsomagolva az
> adatformátum leíróba):
>
> proxy: {
> type: 'rest',
> url: 'getEmployees',
> extraParams: {month: 12 },
> reader: {
> type: 'json',
> root: 'FoundPersons'
> }
> },
>
> Ez meg a kérés:
>
> var TrendData =
> Ext.ModelManager.getModel('TurnoverReporting.model.TurnoverFactsModel');
> TrendData.load(null, {
> params : {
> start : startValue,
> month : monthsValue + 12
> },
> success: function(record, operation) {
> // adat betöltve, csinálhatsz vele mindenfélét
> },
> failure: function(operation) {
> // baj van, oldd meg
> }
>
> 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 Laszlo Hornyak
> Sent: Wednesday, May 23, 2012 3:03 PM
> To: Java lista
> Subject: Re: [Javalist] nyomják krahácsot (romlik a jáva)
>
> 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
>
>
>
--
Üdvözlettel,
Böszörményi Péter
További információk a(z) Javalist levelezőlistáról