[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:15:58 CEST 

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



-- 

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