Miért nem szeretem a JAVA-t?

Java

Mostanában az életem nagy részét JAVA programozással töltöm. Valahogy úgy alakult hogy JAVA és ASP.NET életciklusaim váltogatják egymást pár hónapos periódusokban.
Rátaláltam egy cikkre: Miért nem szeretem a Java-t? Itt érhető el: http://padre.web.elte.hu/java.html

Részben osztom a cikk író véleményét és részben nem...

Kiváncsi lennék kinek mi a véleménye a cikkel kapcsolatban?

Némi .NET tapasztalattal a zsebemben feltehetném ezt a kérdést is: Miért nem szeretem a .NET-et?

Elrugaszkodva a cikk alapmarhaságaitól: ha van valakinek NEM emócionális alapon megfogalmazott objektív véleménye a JAVA és .NET témában akkor nyissa fel a szemem!

  • 17265 megtekintés

( ng | 2007. 03. 28., sze – 21:27 )

Erre én is ráakadtam. Fel is tettem magamnak a kérdést: miért nem szeretem a php-t?

az === nagyon keves, probald ki pl az alabbi kodot:

if( mysql_num_rows( $request > 0 ) ){
doSomething();
}

szandekosan irtam ilyen szellosen a zarojeleket, hogy feltunjon hol a hiba
az en kodomban kicsit kevesebb space volt, debugoltam is sokat mire ezt megtalaltam

szoval hiaba a === tipusellenorzes, ha a beepitett fuggvenyeket nem tudod rakenyszeriteni, hogy integer helyett ne fogadjanak el boolean-t
vagy korberakhatod minden fuggvenyhivasodat ellenorzes-hegyekkel, hogy sehol ne csusszanjon at rossz tipusu adat

( Emulgeator | 2007. 03. 28., sze – 21:49 )

Hat nem tudom nem rajongok a JAVA-ert, de nem is ismerem. Izgalmas cikk volt, de azert orultem volna neki ha a dolgokat peldakkal, meresei erdemenyekkel, etc... alatamasztja.
amugy IMHO minden nyelvnek megvannak az elonyei es a hatranyai. Egyszeruen nem kell egy nyelvet olyanra hasznalni amire nem valo.
------------------
Mindenre tudok magyarázatot találni, legfeljebb nem stimmel.

( Morzel | 2007. 03. 28., sze – 21:58 )

Bár én még csak tanulgatok programozni, de azért érdekes volt elolvasni ezt a cikket, úgyhogy el is mondanék egy-két dolgot, ami az eszembe jutott:

A programozói hibák kiküszöbölése:
Ebben a részben az ragadt be inkább, hogy a cikkíró szerint a programozói munka a kódolásból áll. Ezzel nem értek egyet. Már egy kissebb, egyetemi házi feladat megoldása is a tervezéssel kezdődik, és nem véletlenül. Még tervezéssel együtt is hamarabb végez az ember, és megbízhatóbb lesz a kód.
Hogy mire jó a könnyen olvasható kód? Pl. arra, ha nem egyedül dolgozik az ember, hanem egy csapat részeként. Mi van akkor, ha a csapaton belül bele kell nézned egy kódba, amiben nincs egy darab komment sem, átláthatatlan, és még ráadásul sok-sok sorból is áll?
Hogy baj-e az, hogy figyelni kell arra, hogy mit csinálunk? Nem tudom, de azért mutatok egy egyszerű php kódot: 

$n = 10;
$n = "Kiskutya";
$n = 10.0;

Alaptípusok - osztályok
Ebben a részben azért már van egy-két érdekes dolog. Mondjuk az biztos, hogy numerikus számításokra nem a javat használnám, arra ott van a C meg a C++ :))
Mondjuk az is igaz, hogy kíváncsi vagyok, hogy egy átlagos programozó munkájában milyen hatalmas mennyiségű numerikus számításra van szükség, ill. hogy azok, akik ilyen problémákkal dolgoznak, azok vajon java-t használnak-e. Szerintem nem, dehát pl. a középiskolában sem tanítanak programozást brainfuckban, valószínűleg azért, mert az nem lenne a megfelelő eszköz a tanításra.
Egyébként a skalár típusoknak van típusminősítőjük, pl: unsigned int

Platformfüggetlenség
"A Java-hívek egyik fő érve a platformfüggetlenség. Mit jelent ez? Azt, hogy a lefordított byte-kód teljesen hordozható! Bármilyen gépen lefuttathatom, ugyanazt az eredményt fogja adni."
A java interpreteres nyelv, így tehát nincs byte kód. Egyébként meg a platformfüggetlenség gyakorlatilag nem létezik, viszont az tény, hogy a java közelíti meg a legjobban.

Sebesség
A sebesség a jvm-nek köszönhetően sose lesz olyan jó, mint egy fordítóprogramos nyelvnél. Valamit valamiért. Legyen a program megbízható, vagy gyors. Ha a gyorsaság lenne az elsődleges szempont, mindenki assemblyt használna. Én személy szerint frászt kapok tőle.

Összefoglalás
Mindenkinek szíve-joga azt használni, amit csak akar. Én pl. egy vállalati rendszernek nem esnék neki se perl-ben, se pythonban, se rubyban, se asm-ben, php-ban, sőt még pl/1-ben sem.
Szerintem mindenki használja azt, amivel hatékonyan tud dolgozni.
Amúgy meg van egy kedves barátom, aki mindig ezt hangoztatja:
"A legjobb nyelv a világon az, amit a főnők mond..." :)

Morzel

Tényleg, hülyeséget mondtam, elnézést kérek. Természetesen fordít, csak nem binárisra, hanem bytekódra.
http://java.sun.com/docs/white/langenv/Security.doc3.html
Ez a just in time compiler pontosan hogy is működik?
Ha lesz egy kis időm, kipróbálom az unsignedet. Én úgy emlékszem, hogy van.

Morzel

A javac fordít forrásból bájtkódba.
Aztán a virtuális gép meg bájtkódból natívba az adott platformnak megfelelően, a virtuális gép fajtájától függően,
ezek :
-JIT (just in time)
-HotSpot ez statisztikai alapon dönti el, hogy mit fordít le és mit nem. Ha letöltesz egy jre-t a suntól
abban ilyet találsz.Ha meg akarod tudni, hogy milyen lenne egy java program ha tényleg interpretálná a
bájtkódot a jvm és nem fordítaná, akkor futtass egy java progit -Xint kapcsolóval!
Ha meg azt akarod, hogy a jvm-ed minél több dolgot fordítson le hamar, hogy aztán gyorsabb lehessen,
használd -server-rel!
-a gcj-vel pedig előre lefordíthatsz linuxon futtatható binárissá java programokat, így aztán már jvm
se kell.Azt, hogy ez melyik verziókkal megy nem tudom, de 1.4-el biztos , azzal próbáltam.

Érdemes még hozzátenni, hogy a javac által fordított bytekódot egy java processzor (picoJava, aj100, ARM926EJ-S, Komodo, Cjip stb.), ami pl. egy mobiltelefonban, vagy egy PDA-ban található egy az egyben futtat, így megközlítőleg meg20szorozza a java bytekód futtatásának sebességét a JVM-hez képest, másrészt töredéke annyi memóriát használ.
Véleményem szerint a javanak ez a legnagyobb előnye, más iterpreteres nyelvekkel szemben.
________________________________________________
Debian 4.0 - linux-2.6.20-smp - KDE 3.5.5

Kéne csinálni egyet c-re is egy procit :D (bár a c filozófiája pont fordított nem a hardvert igazitaj amgához egy vm-el hanem az fordít a hardverhez így sok értelme lenne), de így tök jól támadható majd hardveresen a gép, mert minden proci tök egyforma, és van kapu a hardvert gyilkoló vírusoknak, mint annó az őskorban volt ilyen.

Nehogy azt hidd, hogy egy C/C++ gyorsabb! A JIT tud meglepetéseket okozni. Írtam olyan programot java-ban, hogy sokkal gyorsabb volt, mint az adott "kedvenc" (egy frászt kedvenc!) operációs rendszer saját fejlesztőkörnyezetében C++-ban megírt kód. Láttál már java appletben megvalósított demo scene-t? Nagyon brutálisak, a régi K6 II 266MHz gépemen weboldalba ágyazva 3D-s introkat meg demokat nézegettem, olyanokat, amiket 386-os és 486-os időszakban még assembly-ben nyomtak. Úgyhogy az, hogy a java lassú lenne csak bullshit, városi legenda, stb. Viszont a memóriakezelése elég katasztrófa, pillanatok alatt felzabál mindent és a gc miatt nem tudsz egyenletesen gyors reagálású programot készíteni. Bár van már pár éve real time java is real time gc-vel, ki kéne próbálni.

na én ezt elhiszem neked, de még sem tapasztalom hogy asztali java alkalmazások dömpingje árasztana el. Alig tudnék néhányat említeni. ott van pl az Azureus vagy néhány appletes chat kliens. Ezeket sem nevezném tökéletesnek, sem gyorsak. ráadásul sok memóriát zabálnak, és mindegyik külön jvm-et indít, úgy hogy nem is lenne talán túl szerencsés 10 java alkalmazást egyszerre futtatni.
Ráadásul inkább könnyebb javaban programozni mint c-ben, c++-ban,mint nehezebb, így tényleg nem értem, hogy ha tényleg olyan jó a java, akkor miért nem árasztanak el a java programok.
Azért ne gondoljátok hogy nem szeretem a javat, csak magyarázzátok már el hogy akkor miért van ez így. (Azért ott van az eclipse, ami azért elég jó)

ezt a tervezes baromsagot az egyetemen vertek a fejedbe,
marmint, hogy irj le elore minden lepest, hogy mit csinal
az adott modul/osztaly, stb, stb.

a valo eletben egy BAROMSAG igy kodolni (van ahol KELL,
de ez mas kerdes, ne feszegessuk most).

mielott jonnek a fikazasok: nem azt mondom, hogy nem kell
tervezi, csak nagyon nem ugy, ahogy az iskolaban tanitjak.

ha kodolni nemtudsz, mehetsz kapalni, a tervezes nemhuzza
ki a segged a szarbol.

ezt a tervezes baromsagot az egyetemen vertek a fejedbe,
marmint, hogy irj le elore minden lepest, hogy mit csinal
az adott modul/osztaly, stb, stb.

Egy rendszer audit el sem tud indulni megfelelő tervezési dokumentáció nélkül. Ugyan ma még idehaza nem trendi, de külföldön komolyabb rendszerek minősítésénél matematikai módszerekkel is bizonyítani kell a rendszer működőképességét (pl. ITSEC, COBIT, ITIL, Common Criteria előrásai)

Csak halkan megjegyzem tapasztalatom szerint a fejlesztési munka 10-20%-a kéne hogy legyen a kódolás maga, a többi (tervezés, tesztelés, dokumentálás, audit előkészítése, stb.) ami nagyon lényeges.

Senki sem szeret nagyon dokumentálni, de enélkül és a megfelelő tanúsítványok nélkül nagyon nem lehet az üzletembereknek szoftvert eladni.

( turul16 v | 2007. 03. 28., sze – 21:59 )

Gondlokoztam, hogy újra értékelem a JAVA -hoz való viszonyom (Eddig elég negatív )
De http://hup.hu/node/36916 ezek után nincs mit ujraértékelni.

Előkeresek egy genetikai feladatot, amit pointerek nelkul sokkal lasabban lehet csak megoldani, ha nagyon ragaszkodsz hozza.

Endian konverzio elofordul, es ha olyan szepen tervezitek a programjaitokat, akkor valoszinuleg lesz egy ilyen methodus benne :)

szerk:
http://plg.uwaterloo.ca/~acm00/060930/life.html
Talan ez volt az.

>Tömb átadás, ha nem az elejétöl kell
System.arraycopy -> nem kicsit szebb

>Csinál mutatót, minden sztring minden karakteréhez
Hmm, minden bájthoz egy négy bájtos mutató?
Valami meggyőzőbbet mondj ;)

>Ha inteket mozgatsz és bytokkal dolgozol
Mindkettőt csinálhatod referenciákkal(nagybetűs verzió: Integer,Byte) is, ráadásul az 5-ös java óta az autoboxing miatt ezeken ugyanúgy tudsz műveleteket végezni, mint a primitíveken. Próbáld ki: ahol egy metódus paraméterében int van írd át Integer-re és az esetleges visszatérési értéket is!

>Nem számol referenciát.
c++ referencia != java referencia . Javaban a referencia egyszerűen valaminek a virtuális gép beli memóriacíme, nem
kell külön lépésben feloldani

>Hmm, minden bájthoz egy négy bájtos mutató?
Valami meggyőzőbbet mondj ;)

Nézd a belinkelt feladatot old meg Javában, és aztán beszélünk.
A C kódot is megtalálod az oldalon.

>Mindkettőt csinálhatod ..
Nem erről volt szó.

>c++ referencia != java referencia . Javaban a referencia egyszerűen valaminek a virtuális gép beli memóriacíme, nem
kell külön lépésben feloldani

Bizonyára amikor értéket kap egy ilyen referencia, akkor sem történik semmi :D
Vagy más VM típusoknál, szemét gyűjtéskor, minden referencia léte növeli a lefutás idejét.
C++ sem kell feloldani vagy mit..

( emberk | 2007. 03. 28., sze – 22:44 )

Én sem szeretem, hozzá teszem nem is értek hozzá, de nem a levegőbe beszélek megpróbáltam. Egyszer elhatároztam megtanulom mert dícsérik na az első inetgrál számító programomnál azt mondtam kell ez a ............-nak, Röviden. A c kód nagyságrendileg 100-200* gyorsabb volt nem túlzok tényleg c-vel 30másodperc volt, a na a java 50-perc után még izzadt ám keményen, akkor kilőttem, nem vártam meg. Egyébkén tuti van olyan hely ahol a java nagyon jó alternatíva, de matematikai műveletekre, hát, de web-es alkalmazásokhoz, ahol tényleg fontos a multiplatform, ( vagy a sok web-es alkalmazás, mobilteló játékok) nem rosz, de nekem az meg nem kell. Soha nem fogok java-web alkalmazást írni.

csak egy vélemény a Java jövőjéről, ezzel lehet egyetérteni, is meg nem is, ki hogy gondoolja

Szerintem addig van jövője a java programozásnak, a nem specifikus alkalmazásoktól eltekintve amíg a gépek teljesítményét lehet felfelé nyomni, mert a Ghz-k világában ez valőban nem túlzottan feltűnö, de el fogjuk érni egyszer a gyakorlati határt (és már nem is vagyunk olyan túl messze tőle, az egyik ismerősöm inforamtikus fizikus, ő phdzik ilenyből, nem akarok marhaságot mondani, mondott ő Ghz-et meg maximális mag számot, de nem emléxem rá), de mivel egyre többet várnak a felhasználók, egyre bonyolultabbak a programok, szóval szerintem, egyszer vége, a kényelemnek, amiért sokat áldoznak a sebességgel szemben, de ennek így is kell lenni, ez egy alternatíva, aztán leht hogy nem lesz igazam, csak példaként mondom, egy időben pl emkkora sláger volt a fortran, hihetetlen jó matematikai támogatással, aztán a számítógépek kikerültek a "felhasználók" világába, akiket nem érdekelte a matek, játszani akartak. Ki ír ma már f77, g77 kódokat, (rajtam kívül :D, mert az említett matmatikai probkémának ez a leggyorsabb alternatívája eddig, na jó assembly-vel nem próbáltam és nemvagyok elég jó még hozzá,de küzdök)

ja én is etz mondom. nekem nem jó a java, de tény hogy gyorsan kénylemesen lehet benne kódolni, ahogy láttam, és életemben X-szer (X<=10) kódolni, sokkal hamarabb megírtam a kódot mint C-ben de azért én nem fogok 1 hétig várni az eredménre hogy egyszer ne 3-napig hanem 1/2-napig kódoljak.

1) A Fortranhoz képest ennek ellenére ma már alig-alig veszít az ember, ha egy modern c++ fordítóŧ használ. Ugyanakkor, ha c++-ban fejleszt az ember egy numerikus számolást, akkor sokkal kevesebb időt tölt programhibák hajkurászásával, a kód áttekinthetőbb, a képletek olvashatóbbal. Pl. mátrizszorzás Fortranban: 


c     matrizszorzas
      do i=1,4
         do j=1,4
            c(i,j)=0;
            do k=1,4
               c(i,j) = c(i,j) + a(i,k) * b(k,j)
            end do
         end do
      end do

Ugyanez C++-ban: 


c = a*b;

Ez utóbbihoz megjegyzés nem is kellett, egyszerűen látszik, hogy miről van szó.

2) Azért láttam már olyan embert, aki Java-t hasznl numerikus feladatok megoldására. A tesztjei szerint nem (vagy nem lényegesen) marad el sebességben a C++-os verzióhoz képest, ha úgy írod meg a programot, hogy ne adj sok feladatot a garbage collectornak.

Te is kódolsz még fortranban? Egyébként én is egyre kevesebbet az áltad mutatott egy tipikus példa miatt. Már azt hittem hogy egyedül vagyok (na jó ezt nem gondoltam komolyan).
Egyébként mondom nem ismerem a javat, de akkor amikor írtam sokkal sokkal lassabb volt (vagy 3/4-éve, és ismételten mondom difegyenletet oldott meg a program rk-módszerrel, meg numerikus integrált írtam benne).

UI:
Egyébként szerintem egy java fejlesztő mindíg azt fogjka mondani hogy a java nem olyan lessú, a C fejlesztő, pedig ugyanezt fordítva, hogy a java nagyon lassú, valószínűleg az lehet az oka, hogy a java fejlesztő nem igazán tud (és lehet nem is szeret), és a C fejlesztő nem tud, vagy.nem is akar C-zni és ez az eredmény, én még nem láttam olyan programozót aki szereti a javat és az assembly-t együtt (én assembly, és C szavatok ha lehet, nekem az jobb, de ha web-et fejlesztenék akkor a jav-t választanám), erre a vitára csak annyit szertnék szólni egyébként (mnert én eredetileg csak egy saját tapasztalatot mondtam,semmi értelmét nem látom pártoskodin hogy mejik jobb), egy java fejlesztő írjon drivert, egy asm-es meg egy web-scriptet, (és most ......... bölcs voltam). Szóval ennyi.

részemről ezekhez értek, sajnos nem mindegyikben vagyok elmélyülve: ASM, C, C++, Pascal, Delphi, Java, PHP
Programoztam már mikróvezérlőt asmben és c-ben, fejlesztettem Delhpi-ben, később C++ Builder-ben, a java-t is sikerrel használtam több feladathoz is (meg kell jegyeznem tényleg vannak gondok a java-val, de a cikk írója ezekből csak egy kis részt látott meg és azt nagyon kisarkítva túllihegte). Illetve a php-vel is elég sokat foglalkoztam, de az már nem annyira fekszik nekem.
Véleményem:
- C: csak ha muszáj!
- C++: nem is annyira a nyelv és az STL megismerése a nagy feladat, hanem annak a környezetnek a megismerése, amiben/amihez használni fogod (munkahelyről munkahelyre nagyon eltérőek lehetnek az eszközök, a library-k, stb.) Az operátor overloaddal meg lehet nagyon csúnya dolgokat csinálni, amivel nagyon be lehet vinni az új kollégát a málnásba... nem beszélve olyan dolgokról, hogy egy objektum mikor szabaduljon fel és ki szabadítsa fel, mikor hogyan kell másolni az objektumot (hivatkozás szerint, érték szerint, vagy az objektum által hivatkozott másik objektumokat is másolni kell?). A C++ nagy előnye az, hogy bármit meg lehet benne csinálni és ráadásul még elegánsan is, a nagy hátránya, hogy bármit meg lehet benne csinálni akár nagyon elbonyolítva is.
- PHP: egy enyhén típusos összegányolt nyelv, amit már teljesen másra használnak, mint amire eredetileg kitalálták. Vannak benne nagyon jó dolgok is (pl. az associatív tömbök nagyon egyszerű kezelése). Nagy teret enged az egyéni kreatívitásnak, ami sokszor nem jó. Az a jó ebben a nyelvben, hogy hamar el lehet vele indulni, gyorsan tanulható.
- Java: abban igaza van a cikk írójának, hogy az ember kezét valamennyire hátraköti, de a másik oldalról meg irdatlan mennyiségű package van hozzá. Ezek ráadásul alaposan szervezettek is és nagyon erősen támogatják a módszeres csapatmunkát (csak pár név: ant, junit, maven, apache, stb.)

Egyszerűen mindegyiknek megvan a maga helye. A C++-ra, a Java-ra és a PHP-ra is találni nagyon szépen sikerült projekteket, melyek kihasználják az adott nyelv adta lehetőségeket (pl. QT, J2EE, netbeans platform, drupal)

Na ez egy objektív hozzáállás én meg nem is programozó, hanem fizikus vagyok, nekem igazán a sebesség kell(ezért döntöttem vagy 4-éve a C, és az asm-mellett, és muszájból a fortran, mert a diplomavezetőm azt preferálta, amit utólag megkedveltem az asm-et nagyon sajnálom, hogy abbahoagytam, de nem volt rá időm, pedig nekem az 1-hetes futási idők csökkentéséhez ez volna jó), na meg nem is igazán kell a programozásban túl profinak lennem, mert igazából csak néhány rutint szoktam megírni, a többi nekem a lényeg. addig eljutni(pl gui-t sem tudok írni mindet ki file-be aztán gnuplot :D ). Egyébként meg főként numerikus fizika érdekel (egyenlőre, ja és az örök téma az elektronika) most kezd vonzani a mest int + a szimulációk, most azt vettem a fejembe, hogy megírom a kvantummechanikát, mint teret, bevágok 2-3 elméletei testet egy elméleti térbe, és alakítom körülötte a fizikát, kíváncsi leszek mi jön ki belőre (mire nyugdíjas leszek kész is lesz :D, na meg leszen olyan gépek amik bírni fogják a strapát)

Nálunk a cégnél c, c++, assembly, java-ban is programoztam már. De főleg java-ban. Egyébként nagyon szeretem az assembly-t is, csak megvan, hogy mire érdemes használni, és mire nem. (én beágyazott pic szerű mikrokontrollerek programozására használtam, mert hát 2k az 2k :)) )

Szóval a feladathoz (és a lehetőségekhez) kell a programozási nyelvet választani. Hiába akarok java-s webes rendszert az ismerősöm szerverére feltolni, ha ott csak php van. Akkor oda php kerül.

ps.

Úgyhogy jól nézz meg :)))

asm, 2k: mi meg végül megvettük a HiTech PICC18 fordítóját. Ami azt illetti van benne néhány rendkívül súlyos hiba (pl. használsz egy forráskódot, benne struktúrákkal, aztán ahogy növekszik a struktúra, egyszer csak azt mondja, hogy nem tud hozzá kódot generálni. Ha egyetlen mező típusát átírod, máris tud kódot generálni, tehát nem a méret a gondja, meg hasonló finomságok. Volt olyan, hogy a fordítás rendben lement, aztán a legenerált kód volt szar). Pedig maga a fordító nagyon állat: elemzi a függvényhívásokat és annak megfelelően alakítja ki a memóriatérképet és így a 2K ellenére is képes hatékony kódokat generálni. Annyi hátránya van, hogy nincs dinamikus memóriakezelés és rekurzió. De az említett hibák miatt elég gány lehet a fordító saját forráskódja.

( zoli78 | 2007. 03. 28., sze – 22:51 )

Elolvastam a cikket és csak annyit tudok hozzáfűzni, hogy töltsön még el a cikk szerzője pár évet a homokozóban, tanulja meg a szoftverfejlesztési módszertanokat, ismerje meg alaposabban a javat (legyen egyszer szerencséje kipróbálni és ne csak a forráskódban látottak alapján ítélje meg a sebességet) és lássa meg a fényt az alagútban!

Egész konkrétan a Just In Time compilerre gondoltam. Lehet, hogy be kell csomagolnod Integer meg egyéb osztályokba az értéket (java 5-nél ha egyértelmű, akkor már automatikusan megcsinálja és így elhagyható), hogy pl. egy container-be helyezhesd, de ez egyszerűen csak egy nyelvi szerkezet, ha sokszor lefut és nem gazdaságos, akkor a Just In Time compiler egy időre leáll, optimalizáltabb kódot generál és azt használja tovább. És ezzel összefüggésbe még azt is meg kell jegyezni a java sebességéről, hogy alkalmilag elindított programok jó, hogy lassúak, hisz a JIT compiler nem fog rajtuk annyit optimalizálni. Viszont ha egy szerveren megy és éjjel nappal dolgozik, akkor már többminden optimalizáltan fog menni. Egyszerűen van egy bemelegedési idő (és memóriaigény).

( syntern | 2007. 03. 28., sze – 23:38 )

Amikor ilyen cikkeket olvasok, akkor mindig az jut az eszembe, hogy én pl. miért nem mondom meg egy repülőgép-szerelőnek, hogy a rossz csavart használ. Azért mert _nem értek hozzá_. Ugyanígy, a cikk szerzője leszól olyan dolgokat, amikhez nem ért.

Pl. a Java sebességével kapcsolat sok érdekesség jelent már meg, én pl. már sok helyen elmondtam, hogy a saját méréseim alapján időnként meg tudja előzni a natív c++-t. Jah, ez lassú, mert csak időnként, míg az összes többi perl|ruby|python hipergyors :). A Java programkódja egyáltalán nem hatékony, de hogy ne a levegőbe beszéljek, íme a hatékonyabb és egyben tömörebb kód: 


import java.util.*;

public class X {

	public static void main(String[] argv) {
		String test = "Let's count the words in this text. "
			+ "The text contains some words more than once, so their count will be more than one.";
		
		Map<String, Integer> words = new HashMap<String, Integer>();
		for (String token : test.split("\\s+"))
			words.put(token, words.get(token)==null ? 1 : words.get(token)+1);
		
		for (String token : words.keySet())
			System.out.println(token + ": " + words.get(token));
	}
}

A hatékonyság persze még egy kicsit javítható: 


import java.util.*;

public class X {

	public static void main(String[] argv) {
		String test = "Let's count the words in this text. "
			+ "The text contains some words more than once, so their count will be more than one.";
		
		Map<String, Integer> words = new HashMap<String, Integer>();
		for (String token : test.split("\\s+")) {
			Integer x = words.get(token);
			words.put(token, x==null ? 1 : x+1);
		}
		
		for (String token : words.keySet())
			System.out.println(token + ": " + words.get(token));
	}
}

A cikk szerzőjének az a legfőbb problémája, hogy a Java NAGY. És mint minden nagy és komplex rendszer, időt igényel a megismerése, és időt igényel az, hogy értékelni tudja. Neked is, és neki is azt javasolnám, hogy töltsetek el vele még 1-2 évet, tanuljatok olyanoktól, akik értenek is hozzá, és akkor át tudjátok értékelni a jelenlegi véleményeteket.

Hmm generics, ez Java 5, nem?
Mi van akkor, ha a cikk Java 1.4-körül íródott??
Amúgy a java szép és jó és fejlődik :-).
Csak minek fordítsak byte kódot, hogy aztán azt (.class) interpretálja a jvm???
Miért nem a .java kódot futtatja???
Akkor miért nem processzor specifikusan fordítok kódot???

"Hmm generics, ez Java 5, nem?"

Well, végülis csak a Java 6-nál tartunk, nem? :)

"Mi van akkor, ha a cikk Java 1.4-körül íródott??"

Akkor még kevesebb értelme van erre hivatkozva lehúzni a Java-t. De Generics nélkül is csak alig két-három sorral több, nem mintha bele kellene halni...

"Csak minek fordítsak byte kódot, hogy aztán azt (.class) interpretálja a jvm???"

1. Fordítási időben kijönnek a hibák
2. Nem interpretálja. Tudja interpretálni, az első néhány alkalommal még interpretálhatja is, de nagyon gyorsan platformspecifikus, optimalizált bájtkódként futtatja. Ha server módban futtatod, akkor még azon is igyekszik tuningolni, hogy különböző paraméterek esetén más bájtkóddal futtatja, így akár paraméterfüggő optimalizálásra is képes. Legalább olvasd el azt a linket, amit beadtam.

"Akkor miért nem processzor specifikusan fordítok kódot???"

Mert amikor írod a programot, meg amikor fordítod a kódot, akkor fogalmad sincs, hogy milyen procikon lesz futtatva. Lehet hogy 64 biten, lehet hogy pl. Sparc vagy Alpha architektúrán, esetleg ARM-on. Melyik könnyebb? Mindegyikre felkészülni és beszerezni a fordítókat, profilereket, kioptimalizálni, vagy rábízni ezt egy platformspecifikus VM-re? Na ezért :)

"Well, végülis csak a Java 6-nál tartunk, nem? :)"
"Akkor még kevesebb értelme van erre hivatkozva lehúzni a Java-t. De Generics nélkül is csak alig két-három sorral több, nem mintha bele kellene halni..."

Amikor WebSphere5-öt használ egy (nem kicsi, nem szegény) cég, és nekik fejlesztesz (1.4es IBM jdk-ra, ami azért nem egy 1000 éves cucc), tök mindegy, hogy hol tartunk, ha a nyelv eredeti speckójában nem volt benne a feature. Vagy az már nem is java?
Bár, az is igaz, hogy csak(?) az IBM szállít jdk-t a J(2)EE-jéhez :-).

Ha nincs generics, akkor castolsz, és ez volt az egyik alapvető problémája a cikk írójának hogy vannak típusaid, de a mapek, listek nem típusosak, és az alap típusok (int, float, stb) nem is tárolhatók benne...

1.) A hiba kereséséhez nagy rakat class-t generálni? Sztm felesleges, és időigényes, ha a helyigényt nem veszem figyelembe.
2.) Mi a különbség akkor a futtatás és az interpretálás között? Akkor a php-t sem interpretáljuk, hanem futtatjuk? Én onnantól nevezném futtatásnak, ha ahhoz nem kell jvm/php, hanem adott kernel által értelmezhető ~natív kódként fut. Tehát: beágyazott JRE-t mindenkinek :-D.

"Mert amikor írod a programot, meg amikor fordítod a kódot, akkor fogalmad sincs, hogy milyen procikon lesz futtatva."
Na, ilyet még nem láttam. Akkor ott nem volt tervezés...
De sztm létezik olyan megoldás, hogy írsz egy magasszintű forráskódot, amit a compiler az architektúrának megfelelően fordít.

"(1.4es IBM jdk-ra, ami azért nem egy 1000 éves cucc)"

A cég ahol vagyok, 1.3-astól 1.5-ösig mindenféle gyártó mindenféle JDK-ját használja. Nem kell bemutatni a helyzetet (igen, az 1.3-as már sehol sem hivatalosan supportált, ez ilyen...).

"Ha nincs generics, akkor castolsz, és ez volt az egyik alapvető problémája a cikk írójának"

Értem, de erre nem biztos, hogy a "felejtsük el a típusokat" a megoldás. Minden cucc fejlődik, a Java is fejlődött, tessék továbblépni :)

"1.) A hiba kereséséhez nagy rakat class-t generálni? Sztm felesleges, és időigényes, ha a helyigényt nem veszem figyelembe.

Ezt most konkrétan nem értem.

"2.) Mi a különbség akkor a futtatás és az interpretálás között?"

A JVM fogja a classodat, és elkezdi az egyes byte-code utasításokat előkeresni egy táblázatból, és végrehajtja az adott műveletet. Pl. összead két számot és lerakja a verembe. Ez az interpretálás, alapból ezt csinálja a PHP is. Fogja a forrásodat, felosztja utasításokra, megnézi a paramétereket, stb...

A natív futás az, hogy fogja a kódodat (legyen az forráskód, illetve Java esetén a .class, merthogy végső soron az számít, a .java nem), az adott gép binárisára fordítja, és azt futtatja, ami során nyilván elvesznek az eredeti utasítások, a gépi kód fut, ahogy futnia kell neki...

A JVM pont azért tud gyors lenni, mert képes az utóbbira.

"Mert amikor írod a programot, meg amikor fordítod a kódot, akkor fogalmad sincs, hogy milyen procikon lesz futtatva."
Na, ilyet még nem láttam. Akkor ott nem volt tervezés...

Jah, tényleg qrvára nem gondoltam át, hogy vajon MacOS X alatt, vagy Linux alatt fogom használni a grafikus felületet. Igazad van. Azt sem, hogy AMD64, vagy a Core Duo fogja futtatni, esetleg a server részét a Sunos Sparc szerverünkön fogom futtatni. Fejlesztéshez jó volt a saját fejlesztői gépem procija, de productionben futtatni lehet hogy inkább a Sparcot választottam volna. De nem is kellett ezzel a tervezési kérdéssel foglalkoznom, nem? :) Sokkal izgalmasabb volt még az a világ, amikor ezt el kellett dönteni, és a Makefile-okat és a C makrókat úgy kellett megírni, hogy minden platform megkapja a magáét :)

"amikor írod a programot, meg amikor fordítod a kódot, akkor fogalmad sincs, hogy milyen procikon lesz futtatva. Lehet hogy 64 biten, lehet hogy pl. Sparc vagy Alpha architektúrán, esetleg ARM-on. Melyik könnyebb? Mindegyikre felkészülni és beszerezni a fordítókat, profilereket, kioptimalizálni, vagy rábízni ezt egy platformspecifikus VM-re?"

Ezen eltunodtem kicsit.

Az elso esetben ugyebar a fejleszto forditja le minden platformra 1x, mig a masik esetben minden user ra van kenyszeritve a JVMre. Ennek persze elonye is lehet (mint mindennek), de azert elgondolkoztato.

Nem latom az elonyt miert jobb a full JVMet megirni N platformra mint N forditot hasznalni N platformra. Nekem ez hajszalra ugyanannyi munkanak tunik.

Az elony nem a JVM leteben van hanem abban hogy bizonyos forditasi fazisokat keson, modularisabban, rugalmassabban lehet elvegezni.

Nem csak fordító kell, hanem az API(k) is. Azt is vedd figyelemebe, hogy fejlesztő megírja a programot mondjuk valamilyen Linuxon és nem is áll módjába Windowsra fordítani, mert nincs neki. Javanál meg elég egyszer lefordítani és minden platformon fog menni (elvileg), ami létezik, olyan platformon is, ami esetleg nem is létezett akkor, amikor a programot írták.

En a JVM megirasarol beszeltem...

"fejlesztő megírja a programot mondjuk valamilyen Linuxon és nem is áll módjába Windowsra fordítani, mert nincs neki"
Cross compile-lal oda forditasz ahova akarsz. Azt meg ugye te sem gondolod hogy a JVMet ugy irtak windowsra hogy ki sem probaltak ott ?

"Javanál meg elég egyszer lefordítani"
Egy usernel egyszer fordul le, pontosan ugy mint maga a program.

"ami esetleg nem is létezett akkor, amikor a programot írták"
Ebben igazat adok :)

Tök jó újra-és-újra elővenni ezt a gumicsontot. :)

A statikusra fordított program csak azt az optimalizációt tartalmazza, amit a fejlesztője beleálmodott, esetleg az operációs rendszerrel szállított osztálykönyvtárak tudnak többet optimalizálni.

A JVM abban jó, hogy a HotSpot azt a forráskód részletet optimalizálja a végletekig, amelyet gyakrabban használnak. Futásidőben teszi ezt, tehát nem kell új build vagy kettő build, ha mások a felhasználói szokások, illetve változik a futási környezet.

Tipikusan arról van szó, hogy a JVM képes kevés memória esetén intenzív CPU használatra optimalizálni a futást, több memória esetén pedig nagyobb memória használatra, amely kevesebb CPU-t igényel. És ehhez se kell új build.
--
http://wiki.javaforum.hu/confluence-2.10/display/FREEBSD

És ha esetleg az olvashatóság/karbantarthatóság a fő szempont, akkor használjunk Pythont :) 

test = "Let's count the words in this text. " + \
       "The text contains some words more than once, so their count will be more than one."

HashMap = {}
for word in test.split():
    HashMap[word] = HashMap.setdefault(word, 0) + 1
print HashMap

Nem tudom hogy ez miért olvashatóbb, de bizonyára igazad van. Viszont érdekes kérdés lenne az, hogy mennyire karbantarthatóbb. Pl. elkezdünk megváltoztatni apróbb dolgokat a specifikációban:

- nem csak whitespace hanem írásjelek mentén is vágjuk a bemeneti szöveget
- a kiíráskor nem random sorrendben, hanem a map-be rakás sorrendjében írjuk ki a szöveget
- a kiíráskor nem random sorrendben, hanem abc-rendben írjuk ki a szöveget
- a kiíráskor nem random sorrendben, hanem magyar abc-rendben írjuk ki a szöveget
- a kiíráskor más formátumot szeretnénk

És az is érdekes kérdés, hogy ezek hogyan változtatják meg az olvashatóságot. Az én véleményem az, hogy nincs lényeges előnye a Pythonnak ebben, annyi meg pláne nincs, hogy ellensúlyozza a Java előnyeit. Eddigi tapasztalatom alapján a Python előnyös olyan dolgokra, amelyekre kész és tömör szintaxist nyújt a nyelv, de ez az előny hamar ködbe vész a probléma bonyolódásával. A legjobb köztes út egyébként a Groovy (http://groovy.codehaus.org/) lehet:

An agile dynamic language for the Java Platform with many features that are inspired by languages like Python, Ruby and Smalltalk, making them available to Java developers using a Java-like syntax.

Az pedig, hogy az olvashatóság eléggé befolyásolja a karbantarthatóságot szintén nyilvánvaló.

Az olvashatóság egy szempontja csak a karbantarthatóságnak. Azon kívül van még az öndokumentáltság, a dokumentáltság, a tervezés, az implementáció, a szoros formázási konvenciók, ésatöbbi.
--
http://www.javaforum.hu

# -*- coding: utf-8 -*-

import locale
locale.setlocale(locale.LC_ALL, 'hu_HU')

test = u"aba Aba álmos Álmos béla Béla béla béla"
map = {}

for word in test.split():
    map[word] = map.setdefault(word, 0) + 1

words = map.keys()
words.sort(cmp=locale.strcoll)

for word in words:
    print word, ' : ', map[word]

      

    
        

                

  

  




  



    


    
  


  

    
            
Köszönöm szépen, nagyon tanulságos. Egy kérdés még, hogy teljesen megértsem a kódot: a locale az egy singleton, vagy egy variable?



Persze úgy korrekt, ha most megmutatom a Java alternatívát, kezdjük talán a legtömörebbel:




Map<String, Integer> words = new HashMap<String, Integer>();


helyett:




Map<String, Integer> words = new TreeMap<String, Integer>(Collator.getInstance(new Locale("hu", "HU")));

De hasonlóan a tiedhez, létrehozható itt is egy külön list, ami rendezhető:




List<String> wordList = new LinkedList<String>(words.keySet());
Collections.sort(wordList, Collator.getInstance(new Locale("hu", "HU")));
for (String token : wordList)
   System.out.println(token + ": " + words.get(token));

És itt felmerül egy kérdés: amikor azt mondod hogy words=map.keys(), majd rá a sort, akkor az mit csinál? Rendezi a map alatti key kollekciót, vagy egy klónon végzi el a rendezést? Mennyire lehet így beletúrni a map implementáció alá?



És a legfontosabb kimaradt, így edit: a kódod alapján továbbra is úgy gondolom, hogy a kezdeti tömörség előnyét rögtön elveszíti a python akkor, ha kicsit megnöveljük a komplexitást. Onnantól kezdve pedig a tömörség már nem is szempont :)



      

    
        

                

  

  




  



    


    
  


  

    
            
A "locale" az egy Python modul. (http://docs.python.org/lib/module-locale.html)

A keys() a map kulcsaiból egy listát készít.

A sort() ezt a listát rendezi helyben.



Ha tömörebben akarom, akkor írhatom így is:



for word in sorted(map, cmp=locale.strcoll):
    print word, ' : ', map[word]
De azért ne keverjük a tömör kódot az olvasható kóddal. A Python olvashatósága inkább a szintaktikus "sallangok" minimalizásából adódik.

Egy szórakoztató példa tömör, de igen nehezen olvasható Python kódra: http://aroberge.blogspot.com/2005/12/journey-to-117.html

A feladat a lehető legrövidebb kóddal írni olyan függvényt, amely egy számjegyet(0-9) ír ki az LCD kijelzőkön szokásos (pálcika) módszerrel.




      

    
        

                

  

  




  




  



    


    

      

  


      
( ruczati
   | 2007. 03. 28., sze – 23:59 )

      
            
      

        
        
        
      

      
    

  


  

    
            
namost lehet összehasonlítani a perl-t meg a java-t, csak értelme nincsen...



      

    
        

                

  

  




  



    


    
  


  

    
            
A perl nagyon jó, mindent meg lehet benne csinálni. Csak nehogy használni kelljen, vagy más kódjához hozzányúlni. Én egyszer nekiálltam, de már alapjaiban nem tetszettek benne dolgok, de ettől függetlenül van, amire a perl nagyon jó és ez a nevében is benne van: Pathologicaly Eclectic Rubbish Lister, vagyis betegesen túlcicomázott szemét listázó, itt a szemét alatt a log fájlokat kell érteni, amik feldolgozására eredetileg is kitalálták. Ha pl. nagy és sok szövegfájlt kellene összetett szabályos kifejezésekkel kiértékelnem, szűrnőm, akkor nem is gondolkodnék nagyon másban, mint perlben.



      

    
        

                

  

  



  



    


    

      

  


      
( t-bee
   | 2007. 03. 29., cs – 00:17 )

      
            
      

        
        
        
      

      
    

  


  

    
            
Annyit még lefelejtettem: Nekem teccik java, de sajnos egyre inkább .NET re kényszerülök.



Nosztalgiával gondolok vissza az egykori assembly, pascal, object pascal, ANSI C, és C++ programjaimra. Régóta nem nyúltam egyhez sem. Már a Delphis korszakomban megdöbbenve tapasztaltam azt amit sokan elmondtak, hogy kínkeservel lekódolt, aztán lefordított ASM programjaim vagy C kódjaim bizony nem nagyon / egyáltalán nem produkáltak gyorsabb kódot mint a Delphi. Ráadásul a C fordítók terjengzősebb kódot produkáltak mint a korszerűbbnek tartott Delphi. Valószínűleg az architektúra bonyolultsága miatt optimálisabb kódot eredményezett a korszerűbb Delphi, mint amit Én tudtam létrehozni.



      

    
        

                

  

  


  



    


    

      

  


      
( Mico
      v
   | 2007. 03. 29., cs – 01:49 )

      
            
      

        
        
        
      

      
    

  


  

    
            
"például Perl, Python, Ruby. Bár ezek dinamikus típusrendszerű nyelvek, mégis alkalmasak minden feladat elkészítésére, melyek Java-ban elkészíthetők."



lol nekem ennyi elég volt



plane hogy az az elotti bekezdesben "Nem az a baj a Java-val, hogy lassú. Hanem az, hogy ***** lassú!".. ezek utan perl meg ruby? lol lol lol



      

    
        

                

  

  




  



    


    
  


  

    
            
ha már sebesség multkor brahiból felraktam valami yabasic (vagy mi) nyelvet, mert hogy olyan mint a c64-es basic annó 18xx-ben hogy nosztalgiázzak, mert én olyan öreg vagyok hogy abban kezdtem, hát a 3000-es gép akár egy 486-os képességeit is elérte grafikai treljesítményben :D na de csak szórakoztam.



      

    
        

                

  

  



  



    


    

      

  


      
( szdl
   | 2007. 03. 29., cs – 02:30 )

      
            
      

        
        
        
      

      
    

  


  

    
            
Jó ez a cikk. :-)



Épp most tervezünk egy programot Java-ban, ezért kénytelen voltam kissé belekóstolni a témába, ezért nem árt, ha tudunk egyet, s mást..



Amit információgyűjtésem során le kell szögeznem a következő: a Java fejlődik! Gyakorlatilag most kezd valóban felnőttkorba lépni, és a közeljövőben tovább  fog változni.



Meglévő és erősödő tendenciák:



1. - A (Java) NYELV, a (Java) Runtime Environment, a Java VM és a GUI szétválása, függetlenedése egymástól



2. - a JRE és/vagy JVM egyre inkább keretrendszer (a .Net-hez hasonlóan), mint "virtuális gép".



3. - Rengeteg alternatív (nem Sun) megoldás létezik, ami gyökeresen mássá teszi a Java megoldásokat.



Kifejtve:



Ma már erős túlzással "bármilyen" nyelven írhatunk programot, amit később java bytecode-ba tudunk fordítani!

A Jython, Jruby (vagy már régebben pl. a NetRexx) ugyebár lehetővé teszi, hogy python

vagy ruby nyelven írjuk meg a forrást, de java program legyen belőle!

Néhány crosscompiler és converter segítségével (pl. C#-ből, VB-ből is) kedvenc nyelvünkön megírt forrásunkból (minimális átalakítással) Java alkalmazást tudunk csinálni, tehát aki utálja a java NYELVET, de mégis Java alkalmazást kell csinálnia, annak ez elég nagy segítség..



Másrészt, mint említették többen, Java nyelven írt programot lehet natív (*nix) kódra is fordítani, pl.  GCJ segítségével.



De pl. az Excelsior JET is képes arra, hogy úgy fordítsa a forrást, hogy abból "natív" (win32 "exe" és linux) kód legyen + jön hozzá az Excelsior JRE, viszont JVM nincs!! Így sokkal gyorsabb tud lenni a program   ( http://www.excelsior-usa.com/jet.html ). Ld. Jalbum.



Egyébként sok alternatív JVM is létezik, némelyiknek meglepően gyors a sebessége (pl. BEA Jrockit).



A GUI tekintetében is óriási kezd lenni a választék. Aki nem szereti a Swing-et, mert kissé lomha, annak ott van az SWT (eclipse gui), ami villámgyors (mivel a natív gui-t köti a java-hoz), de ma már wxwidgets, Qt és GTk is van java-hoz, ugyanúgy mint c/cpp-hez! Ezekből a Qt a leghasználhatóbb (kde qtawt, vagy újabban trolltech QtJambi - hamarosan kijön! http://www.trolltech.com/developer/downloads/qt/qtjambi-techpreview



Mindenesetre mégis csak a Swing-ről mondható el, hogy a legtöbb platformon van, és mindenütt ugyanazt nyújtja! Ez egy fontos érv mellette. Ilyet a python,  Ruby, Perl nem tud, ezek rá vannak utalva a GUI binding-jaikra. Persze jython és jruby esetén ezek a nyelvek is tudják használni a Swing-et..



Tehát összefoglalva: egyáltalán nem rossz döntés a Java _platform_, bármibe kezd is az ember manapság..




      

    
        

                

  

  




  



    


    
  


  

    
            
Csak hallkan megjegyzem, hogy a swing több dologban is nagyságrendileg maga mögött hagyja az awt-t. Ennek egyik oka az, hogy awt esetén az alatta lévő grafikus rendszerben (Windows GUI, X11, stb.) is létre kell hozni az adott objektumokat, ezek adatai párhuzamosan vannak kezelve a java objektumban és az alatta lévő natív guiban, míg swing esetén csak a nehézsúlyú komponensek számára kerül bármi is lefoglalásra az alatta lévő ablakozó rendszerben. A nehéz komponensek azok, amik külön ablakot igényelnek (pl. egy combobox legördülő listája, ha kilóg a formbol, amin rajta van). Amikor mérőrendszert valósítottam meg java-ban, akkor swinget használtam felületnek és meglepődtem, hogy a szövegdoboz képes volt valós időben kihányni a rengeteg adatot (sokezer sort), miközben ugyanezt awt-ben, illetve delphi-ben megcsinálva a szokásos síralmas windows-os eredmény lett. Ennek egyszerűen az az oka, hogy a swing és a java magában elintézte, amit el kellett és csak az eredményt nyomta ki az ablakba (csak a rajzolási kérelmet jelezte az operációs rendszer felé).



Sajnos a swingnek vannak dög lassú részei is. Főleg splitter alkalmazásakor érezni, amikor több objektumot át kell méreteznie, újrarajzolnia.



Én kb. háromnegyed éve próbálkoztam java-ban rad szinten gui alkalmazás készítésével, kimondottan jól, gyorsan és kényelmesen használható vizuális komponenseket keresgéltem. A JDesktop nyerte meg legjobban a tetszésemet, de erősen fejlesztési állapotban volt még. Ekkor úgy döntöttem, hogy még mindig nem jött el a java ideje a hatékony desktop fejlesztésre, de már közel van! Azóta lehet, hogy el is érkezett.




      

    
        

                

  

  




  





  



  




  



    


    
  


  

    
            
amióta benne van a netbeans-ben az új gui tervező (matisse), azóta teljesen más élmény ilyen alkalmazásokat csinálni. A Swing-nek egyébként valóban fel lehet róni, hogy "lassú" viszont mindenhol ugyanúgy működik és -néhány gixertől eltekintve- elég jó API-ja van (sokkal jobb mint pl az SWT-nek). A komponensek rengeteg dolgot tudnak, pl JTable... néhány dolog viszont bonyolultabb (pl drag and drop), viszont a bonyolultabb dolgok is legalább logikusak, ha felfogtad, hogyan működik a swing



      

    
        

                

  

  




  





  



    


    
  


  

    
            
ez azért szerintem kicsit már parasztvakítás



jobb SOA támogatás viszont jobb lenne, mármint úgy értem, web service-ok, a hívások hibakezelése stb. Ki a halál éri el a kliens alkalmazásból az adatbázist direktben? Sokan de ezt a delphi is tudja. Web service-okra volt/van néhány koncepció, az IDE-be integrálásra, az összes az event dispatch thread-ből akarja őket meghívni.. lol. Nem onnan csinálva meg "pain in the ass" a hibakezelés.. erre csinálhatnának valami fasza libraryt.



      

    
        

                

  

  



  



    


    
  


  

    
            
Egy-két érdekesség Swing és SWT ügyben:



Az SWT és a Swing kombinációi!:



SwingWT:



- SWT, kiegészítve Swing widgetekkel, vagyis Swing elemek SWT "fölött"



Cél: sebességnövekedés + a bővebb Swing elemek lehetősége (viszont csak azon a platformon érhető el, ahol van eredetileg SWT).



http://swingwt.sourceforge.net/



Ugyanez "fordítva"!:



SWTSwing:



- Az SWT számára a Swing jelent "natív" felületet: tehát SWT Swing fölött!

- Így azokon a platformokon is elérhető az SWT, ahol eredetileg nincs megvalósítva. Ez a célja.



http://www.nextencia.net/projects/swtswing/

http://swtswing.sourceforge.net/main/index.html



Szóval van egypár trükk..




      

    
        

                

  

  




  




  



    


    
  


  

    
            
Szerintem az ilyen compilerek előnye az, hogy nem kell előre telepített JRE a futtatáshoz, és nem a sebesség.. be lehet paraméterezni a JVM-et hogy ugyanúgy ne egyen annyi memóriát stb. A gyorsaság másik forrása lehet a saját runtime library, ami viszont rengeteg kellemetlenség forrása is lehet (ilyen NIO-s szerver alkalmazásnál nagyon megszívtam).



Ezzel csak azt akarom mondani hogy nem attól lesz gyorsabb, hogy "natívra" fordítja.



      

    
        

                

  

  




  



  





  



    


    
  


  

    
            
Nekem nem jön le ebből a marketing bullshitből, hogy a _natívra fordítástól_ konkrétan mitől lesz gyorsabb. A startup time-on kívül! A Sun JVM ugyanis ezt a fordítást megcsinálja, tehát ugyanaz vagy hasonló "natív" kód fut.



A többit azt értem, optimalizált, kisebb méretű, platformfüggő libeket pakol az alkalmazás mellé, de ez nem a "natívra fordításhoz" tartozik - bármilyen JVM-el lehetne optimálisabb libeket használni.




      

    
        

                

  

  




  



    


    
  


  

    
            
Szerintem nem pakol platformfüggő lib-eket (kivéve, ha a Sun JRE-ben lévő java*.dll-t is platformfüggő lib-nek nevezzük vindózon..).

A lényeg - ahogy látom - leegyszerűsítve: egybecsomagolja a cuccot egy "saját gyártmányú", de kompatibilis JRE-vel - a JVM pedig el van felejtve.



Egyébként érdekelne a tapasztaltak véleménye erről. Én csak rátaláltam erre, nem próbáltam..




      

    
        

                

  

  



  



    


    

      

  


      
( _Franko_
      v
   | 2007. 03. 29., cs – 10:58 )

      
            
      

        
        
        
      

      
    

  


  

    
            
Elfogult leszek, de néhány észrevétel.



A vitaindító cikk alapján úgy tűnik, hogy az írója összevadászott egy csomó 8-10 éves Java problémát, és szembehelyezte vele a Ruby és Perl nyelvek előnyeit.



Egy szót nem szólt például a memória-menedzsment problémáiról, pedig a Java programoknak manapság ez az egyetlen nagy problémájuk, a JVM a HotSpot és JIT okán képes natívan fordított C++ nyelv sebessége felé emelni a Java teljesítményét. Feltéve, ha nem kell gyakran új példányokat létrehozni, ha mégis, akkor tudunk objectpool-t használni. Mert gyakori példányosítás-eldobás esetén a GC belefullad a munkába.



További probléma a JVM memóriafelosztása, amely alapvetően három részre osztja a memóriát: óvoda, felnőtt és örökéletű. Valamilyen oknál fogva ez utóbbiba kerültek a String-ek, ami nem volt gond, de nagytömegű XML feldolgozás esetén betelik és a JVM közli: Out of PermGen space...



A GC egy nagy előnye és nagy hátránya is a Java programoknak. Bár GC-ből is van már több féle... választhatunk, hogy melyiket és miként akarjuk használni... :)



A mit és milyen röviden írunk le programként, az eléggé farokméret-versenynek tűnik: semmi értelme, egy jó IDE a Java kód felét kitölti magától (tessék megnézni e tekintetben a 6.0-s NetBeans-t, most jön ki az M8 belőle).



Másrészt, a Perl eléggé gyenge ott, ahol a Java erős: a vállalati szektorban. Hol van a Perl-nek vagy a Ruby-nak olyan tudása, mint egy GlassFish EJB3-al?



Aztán néhány reakció az írásokra:

===

A c kód nagyságrendileg 100-200* gyorsabb volt nem túlzok tényleg c-vel 30másodperc volt, a na a java 50-perc után még izzadt ám keményen, akkor kilőttem, nem vártam meg.



Tedd közzé a forrást és kapásból mondunk egy tucat hibát, amit elkövettél a Java program írása során. Aki jó C/C++ nyelvben, iszonyat szar Java programot szokott írni. És viszont.



Ki ír ma már f77, g77 kódokat, (rajtam kívül :D, mert az említett matmatikai probkémának ez a leggyorsabb alternatívája eddig



Próbáltad már a Fortress nyelvet? http://www.javaforum.hu/?newsId=213#newsBody Nézd azért meg. Hátha megtetszik.

===

Nekem teccik java, de sajnos egyre inkább .NET re kényszerülök.



Nagyon jogos. A Javafórum cikkei, hírei között egy csomó ezzel foglalkozik, hogy a .NET néha jobb és sokszor kényelmesebb. Viszont nincs .NET enterprise környezetre és nincs .NET mobilra se, kivéve, ha Windows fut a mobilon, mert akkor Java nincs...



Igazán nagy .NET projekt alig van, a .NET leginkább VB.NET az esetek nagy részében... persze van példa már nagyobb webes rendszerekre .NET alatt, de annak nincs túl nagy előnye a Java-hoz képest.



A Sun jobban tenné, ha belehúzna, mert éveket ült a seggén, és semmit nem dolgozott a Java környékén. Most meg kapkod, és nyomja ki tízhavonta a major Java verziókat.

===

én még nem láttam olyan programozót aki szereti a javat és az assembly-t együtt



Én jó leszek erre? :)

Mindehol Java, kivéve mikrovezérlők, ahol C vagy Assembly.

===



Néhány fórumadalék a témában:

http://www.javaforum.hu/forum?categoryId=25&topicId=226

http://www.javaforum.hu/forum?categoryId=25&topicId=169

http://www.javaforum.hu/forum?categoryId=25&topicId=191

http://www.javaforum.hu/forum?categoryId=25&topicId=250

http://www.javaforum.hu/forum?categoryId=25&topicId=211



Regisztráció nélkül is írhatók, ha valaki reagálna egy ottani témára.

--

http://www.javaforum.hu



      

    
        

                

  

  




  



  



    


    
  


  

    
            
"További probléma a JVM memóriafelosztása, amely alapvetően három részre osztja a memóriát: óvoda, felnőtt és örökéletű. Valamilyen oknál fogva ez utóbbiba kerültek a String-ek, ami nem volt gond, de nagytömegű XML feldolgozás esetén betelik és a JVM közli: Out of PermGen space..."



umm, milyen xml parser volt ez? meg úgy az egész



manapság már az internált stringek is GC-ződnek amúgy



      

    
        

                

  

  




  




  



    


    
  


  

    
            
Egy szót nem szólt például a memória-menedzsment problémáiról, pedig a Java programoknak manapság ez az egyetlen nagy problémájuk, a JVM a HotSpot és JIT okán képes natívan fordított C++ nyelv sebessége felé emelni a Java teljesítményét. Feltéve, ha nem kell gyakran új példányokat létrehozni, ha mégis, akkor tudunk objectpool-t használni. Mert gyakori példányosítás-eldobás esetén a GC belefullad a munkába.



Teljesen egyetértek.



További probléma a JVM memóriafelosztása, amely alapvetően három részre osztja a memóriát: óvoda, felnőtt és örökéletű. Valamilyen oknál fogva ez utóbbiba kerültek a String-ek, ami nem volt gond, de nagytömegű XML feldolgozás esetén betelik és a JVM közli: Out of PermGen space...



Melyik JVM? A SUN-féle?




      

    
        

                

  

  




  



    


    
  


  

    
            
"Mert gyakori példányosítás-eldobás esetén a GC belefullad a munkába.




Teljesen egyetértek."



Egyébként pont nem... A gyakori példányosítás-eldobás (= rövid életciklus) a young-generation-ön belül történik, aminek a GC-futtatása nagyon gyors, és ha még a parallel-gc-t is bekapcsolja valaki, akkor szinte észrevehetetlen, kb. a referenciaszámlálós C++ megoldásokkal versenyzik...



Az igazi GC gond a közepes életciklusú objektumokkal van, mert ott végig kell nézni alaposan az objektum-gráfot, és az időigényes. Ilyenek lehetnek általános esetben pl. a saját-barkács-mostdejólmegcsináljuk memória-cache-ek, illetve specifikus esetekben is kialakulnak hasonlóak...



      

    
        

                

  

  




  



    


    
  


  

    
            
Egyébként pont nem... A gyakori példányosítás-eldobás (= rövid életciklus) a young-generation-ön belül történik, aminek a GC-futtatása nagyon gyors, és ha még a parallel-gc-t is bekapcsolja valaki, akkor szinte észrevehetetlen, kb. a referenciaszámlálós C++ megoldásokkal versenyzik...



Tiszta esetben igen, de sok esetben nem... és sokszor nagyon nehéz ránézésre megmondani, hogy egy példány melyik generációban van... ezért mondom mindig, hogy a GC legalább annyit segít, mint amennyit árt. :)

  Eszméletlen mennyiségű "memory leak" programot látok Java alatt is, egyszerűen azért, mert sok példány átcsúszik a következő kategóriába és ott meg "foggal-körömmel tartja" magát... :)

--

http://www.javaforum.hu



      

    
        

                

  

  




  



    


    
  


  

    
            
Tiszta esetben igen, de sok esetben nem... és sokszor nagyon nehéz ránézésre megmondani, hogy egy példány melyik generációban van... ezért mondom mindig, hogy a GC legalább annyit segít, mint amennyit árt. :)



Jah, a kalapács is jó eszköz, csak éppen ha az ujjadra csapsz vele, az fáj :). De a kocsihoz is azért jó a jogosítvány, hogy legyen valami minimumkövetelmény, hogy valamennyire talán érts hozzá. Ugyanígy a Javanak is vannak különböző szintjei, de pl. a GC az az, amivel nem a fejlesztőnek, hanem az architektnek és a profile-olónak kell foglalkoznia...



Eszméletlen mennyiségű "memory leak" programot látok Java alatt is, egyszerűen azért, mert sok példány átcsúszik a következő kategóriába és ott meg "foggal-körömmel tartja" magát... :)



Azért az, hogy valami úgy viselkedik, ahogy a programozó leírja, ne a nyelvet okoljuk már :). A gondolatomat szerencsére egy programozási nyelv sem fogja kitalálni, és ez így jó... :)



      

    
        

                

  

  




  




  



    


    
  


  

    
            
Tiszta esetben igen, de sok esetben nem...



Ezzel mindent elmondtál.

És rendszerint nem lehet előre látni, hogy a kód annak a bizonyos "sok eset"-nek az egyike.

Persze olyan nagy baj nincs. Ha egyszer belefutottunk a hibába, föl kell venni egy objectpool-t, és minden megoldódik. De butaság ezért a Java nyelvet hibáztatni.



      

    
        

                

  

  



  



    


    
  


  

    
            
Na azért kérdeztem, hogy melyik JVM-mel, mert ha jól emlékszem, a SUN-é azt csinálja, hogy a GC fut időnként (mondjuk 10 mp-enként), továbba akkor, ha elfogyott a RAM. Az utóbbi esetben nyilván nagyon sokáig fog futni, mert azért fogyott el a RAM, mert rengeteg objektumot hoztunk létre. És ennek a sok objektumnak a fölszabadítása sokáig tart. Vagyis hülyén megírt programot onnan lehet megismerni, hogy néha hosszú másodpercekre befagy, majd megy tovább, mintha mi sem történt volna. De olyat még nem láttam, hogy iediglenesen fölvett String-ek miatt a JVM kiírta volna, hogy "out of memory".



      

    
        

                

  

  




  





  





  





  




  





  





  



    


    
  


  

    
            
Meg mielott barki felreertene. A permgen egy teljesen masfele memoria terulet. Ez maguknak az osztalyok a leirasanak tarolasara szolgal. Azaz, ha egy osztalybol letezik legalabb egy peldanyod a heap-en vagy stack-en, akkor magat az osztalyt leiro adatstruktura bekerul a permgenbe.



En arra jutottam, hogy programmal ezt megtolteni nem nagyon tudod, legfeljebb, ha nagyon sok-sok libet hasznalsz egyszerre.



Ha jol tudom, akkor string konstansok egyebkent ugyanitt tarolodnak.



Ha egy nagy szovegfaljt toltesz be egy stringbe az a heap-re vagy stackre kerul, annak fuggvenyebe, hogy az adott string-et hogy hoztad letre.



      

    
        

                

  

  



  



    


    
  


  

    
            
Sosem mondtam hogy én irtam azt a kódot, én csak 2-kódot írtam java ban de nem tetszett, rohadt sok memóriát evett, nem használtam semmire, így már a kód sincs meg (lehet hogy meg van valami ősi cuccon de ha nem haragszol nem keresem), a c-kód az megvan, nekem az elég. De ezt már kitárgyaltuk, hogy a feladathoz kell választani a nyelvet, és soha nem mondtam azt hogy a java rossz nyelv lenne, cask én nem használom, de nem zárkózom el tőle hogy egyszer megtanulom minél többet tud az ember annál jobb. 



      

    
        

                

  

  


  



  



    


    
  


  

    
            
"natívan fordított C++ nyelv sebessége felé emelni a Java teljesítményét."



Ha java kódot átírod egy az egyben C++ , mezei -O2 vel forgatva jol közelíti, (java indulási időt levonva).



Azért,ha C/C++ -osan gondolkozol már nem biztos, sőt.



A kérdés az, hogy megéri-e: "It's worth spending eight hours trying to make something load 20ns faster".



Ha öszzes felhasználó, emiatt elvesztett idejét összehasonlítjuk a plusz fejlesztési munkák idejével, és az előbbi lenne a megasabb akkor igen.

Vagy, ha hasonlóan fejlesztésiköltséget hasonlítjuk a + vas árával.



      

    
        

                

  

  



  



    


    

      

  


      
( emberk
   | 2007. 03. 29., cs – 14:47 )

      
            
      

        
        
        
      

      
    

  


  

    
            
Arra azért kíváncsi volnék, ha egy csapat nekiállna annak hogy a C-fordítót sebességoptimalizáció szempontjából rendberakja akkor mi jönne ki belőle. Mert a c-ben is lehetne sokat fogni még, (sőt szerintem iszonyat sokat pláne a 64-bites megoldásoknál). Ja egy kérdés, javasok, lehet a javaban 128-bites, vagy 256-bites lebegőpontos ábrázolást írni,vagy belrakni a kódba assembly-kódrészletként, de lehetőség szerintz ne kelljen már az egész számot mozgatnom a memóriában, mert az rohadt sok munka, hanem egy pointerrel hivatkozni (vagy valami más specifikus megoldás, ami benne van a javaban mert ahoz hülye vagyok) (ja ez nem értelmetlenségből kell, mert csak egy pontossági határon belül nem szál el a közelítésem), mert fontolgatom én is a java tanulást, egyre jobb, és hát ........ sok pénzt lehet vele keresni.



      

    
        

                

  

  




  





  



  





  



    


    
  


  

    
            
Vagy a csatolt differneciálegyenletk megoldása, ahol nem a gyorsaság a leg döntőbb (ha rá érsz heteket várni :D ) de nagyon fontos, ahol ha az első lépésben van egy hiba az a 2. lépésben exponenciális ugrással jelentkezik ...... szóval ennyi ehez kell a pontosság (nekem, aztán biztos van más terület is).



      

    
        

                

  

  



  



    


    
  


  

    
            
GCC belső lelki világával elég sokat ismerkedtem és azt kell, hogy mondjam, hogy nagyon alaposan tud optimalizálni, csak ehhez ismerni kell alaposan a fordítóprogram képességeit (gcc esetén ez sem kis feladat). Persze bizonyos dolgokat nem fog a fejlesztő helyett megtenni (pl. egy laza stílusban rosszul megírt rekurzív megoldást, amire van jobb teljesítményű iteratív megoldás is, nem fog a fordító iteratívra optimalizálni).



      

    
        

                

  

  




  



    


    
  


  

    
            
na persze ez természetes nekem volt egy kódom ami fortranban volt, de még egy ilyen lassú kódot nem láttam átírtam c-be nem mintha itt bármi is múlna ekkora m,értékben a fordítón, de 4-5ször gyorsabb lett azzal hogy beraktam + 4 sort, mert addig úgy működött, hogy minden kapcsolatot 2-lépésben talált meg a részecskék között, de könyörgöm, ha f-r között kapcsolat van akkor miért kell az r-f iránytz is külön levizsgálni. szóval ennyi, ez már kapásból sebességduplázás.



      

    
        

                

  

  



  



    


    
  


  

    
            
A BigDecimal és BigInteger osztállyal tudsz tetszőleges méretű számokkal dolgozni. (persze csak addig tetszőleges amíg van ramod:)

Egyébként pedig van lehetőséged c vagy assebly kódot felhasználni a java-ban, ha egy függvény elé azt írod, hogy native akkor a javah paranccsal generálhatsz hozzá .h fájlt amit implementálhatsz és a programod azt fogja használni.



      

    
        

                

  

  


  





  




  





  



    


    
  


  

    
            
Ja, én is. Jól meg lehet élni belőle és az ember mindig tanul valami újat:)



Egy szoftver fejlesztésénél meg qrvára nem a nyelv számít úgysem, hanem a programozók egyéni és csapatbeli minősége + a kialakult működési rend ("módszertan"), unit testing, continuous integration használata, verziókontroll, stb...



Kedvenc a témában: http://www.agilemanifesto.org




      

    
        

                

  

  




  





  





  





  



    


    
  


  

    
            
Az ember cseszheti a szép, egyszerű és hatékony, jól olvasható nyelvét, ha az ügyfele által támasztott követelményeket, megszabott idő-, tér- és pénzbeli határokat betartva kell az ügyfél üzleti problémáját elfogadható módon megoldó szoftver letennie az asztalra. Ebben a szituációban nem az számít, hogy valami.getName()-et kell írnod, vagy valami.name-et... Az számít, hogy milyen módszerekkel fejlesztesz és mennyire összeszokott csapat az, aki az egészet csinálja - milyen szakmai szintre értek el és mennyire tudnak jól együttdolgozni. Az számít, hogy milyen fejlesztést segítő eszközöket használsz (automated testing, continuous integration), tisztában vagy-e a refaktoring jelentőségével egy több iterációt magában foglaló projekt közben - egyáltalán az alkalmazott eszközrendszer (nyelv + fejlesztőeszköz + build környezet + verzóiókontroll + issue tracking + futási platform) mennyire támogatja a refaktoringot, a folyamatos build-eket, az automatikus build-eken futtatott automatikus teszteket és azokból automatikus report-ok készítését, milyen debug lehetőségek vannak (Java-ban (jdk6) csak egyet mondok, amitől seggreülnek sokan amikor először megmutatom: úgy hívják, hogy jhat: egy futó java processről készített memoria snapshot-ot dolgoz fel és teszi ki egy porton a webre az egészet szépen navigálható formában - a már feljebb sokak által emlegetett "nem tudod kontrollálni a memóriahasználatot" típusú problémál (amik igazából a legtöbbször inkább  "nem vetted a fáradtságot, hogy megtanuld kontrollálni Java-ban a memóriahasználatot" tipusú problémák) esetén tud sokat segíteni...



      

    
        

                

  

  


  



    


    
  


  

    
            
1. Mit jelent a jól olvasható? Ez olyan szubjektív fogalom, van aki a perlt is tudja olvasni, lelke rajta...



2. Hiába találkozol a tökéletes nyelvvel, ha minden API-t magadnak kell megírni. Vegyünk egy egyszerű példát, SHA-1 számítás. Hiába jól olvasható egy nyelv, ha épp erre van szükséged, és nincs rá kész támogatás, akkor meg kell írni, és nem biztos, hogy csak 10 perc lesz... Aztán vehetünk egy bonyolultabb problémát: szinkronizálni kell az adatbázis és a message queue tranzakciót :)... Az API fontosabb, mint a nyelv szintaxisa...



      

    
        

                

  

  




  



    


    
  


  

    
            
1. Egy embernél szubjektív. Sok embernél statisztikusan már objektív.

Ha számokat akarsz látni, kiírhatsz pl. szavazást a fenti Java/Python kódokról.



2. Ebben teljesen igazad van, ha csak az ipari/üzleti fejlesztéseket nézed.

Viszont szoftevereket fejlesztenek más környezetben is, például FOSS, kutatás, belső céges felhasználás. Itt már sokkal többször fog szerepet játszani a nyelv választásánál az egyéni ízlés, vagy más egyéb körülmény.




      

    
        

                

  

  




  



    


    
  


  

    
            
1. Azért nem hiszek a szavazásdiban, mert húszmillió légy sem tévedhet... De mondjuk hívjuk segítségük a Google-t? :) (java) 278,000,000 : 92,100,000 (python) results



2. Tehát ami pénzt termel, arra jó a Java, ami meg nem termel pénzt, arra meg megteszi más is? :) Mert most kb. azt mondtad, hogyha pénz múlik rajta, akkor jó a Java, ha meg nem, akkor jöhetnek az egyéb szempontok :)... (mellékesen: ha komolyan veszi magát egy cég, akkor a belső céges felhasználást is üzleti fejlesztésnek tekinti, sőt, ha nem akadémiai kutatgatásról beszélünk, akkor én a kutatást is üzleti fejlesztésnek tekinteném... - és hogy a sértődéseket elkerüljük, elég sokat dolgoztam kutató környezetben, tudom mi megy ott)



      

    
        

                

  

  




  



    


    
  


  

    
            
Ha nagyongyorsan össze kell ütni valamit, akkor java(egyszerű dolgokat RAD-ban könnyű), 2.0 meg már normális nyelven lesz, és nem lesz szarlassú + feature-öknél sem kell azon filózni, hogy mi az amit enged a nyelv nagy kegyesen.



Ha meg ráérsz, minek szopnál a dzsávával?



--

"SzAM-7 -es, tudjátok amivel a Mirage-okat szokták lelőni" - Robi.




      

    
        

                

  

  




  





  



    


    
  


  

    
            
Ez az "ismerd meg, mielőtt fikázol" jó próbálkozás. Az a gond, hogy egy év elég volt az api megismeréséhez és megutálásához. Kínkeserves "ezt lehet csak ide használni, de mégsem jó" -k sorozata után inkább feleannyi szenvedéssel és doksiolvasással megoldom gyorsabban más nyelven, gyorsabb futást és kevesebb memóriát etetve fel.

Ugye, minek a 10 szerver, ha EJB nélkül nem kéne az a 10 szerver? ;-)



--

"SzAM-7 -es, tudjátok amivel a Mirage-okat szokták lelőni" - Robi.




      

    
        

                

  

  




  



    


    
  


  

    
            
Ha egy év alatt sikeresen megismerted az API-t, akkor gratulálok, nagyon-nagyon ügyes gyerek vagy! Én a magam részéről évek óta tanulom, és a mai napig tudok újat tanulni... Az 5-ös Java API-ja, csak az amit a Suntól le tudsz tölteni, több mint 8000 osztályt és interfészt tartalmaz. Ha ezt így egy év alatt sikerült elsajátítanod, magadévá tenned és a működését is kiismerned, akkor te minimum zseni vagy, kérlek oszd meg velünk azt, hogy melyik 7500 az, ami a Java nyelvben rossz, és pl. a pythonban jó :)



A viccet és a nyilvánvaló iróniát félretéve... A Java nyelv nagy, nagyon nagy, és néhány év alatt is legfeljebb egy kicsi részét kiismerve tudsz bármit is mondani róla. Elhiszem, hogy vannak rossz tanárok, rossz résztechnológiák, de azért ne jelentsük ki egy év után olyant, amit esetleg később megbánunk...



      

    
        

                

  

  




  



    


    
  


  

    
            
[Flame vergődés detected: Másik észbeli képességeinek fikázása és newbie-nak való feltételezése]



Az a 8000 az vadiúj osztály? Hát persze.



Figy. Használd. Biztos te is találsz majd befektetőket az iwiw méretű szerverpark összeadására. :)



Ne feledd: ha nincs EJB, nem kell hozzá 10 szerver.



Ja. Ezek szerint te java profinak tartod magad. Az iwiw ugye javaban van, mert az az egy igaz nyelv.

1. miert kell memcached alá? Pedig az nem javaban irodott, hanem a fujfuj C-ben...

2. miert van tele xml errorokkal? (Lasd errol szolo topicok itt, a hup-on) pedig a java tokeletes, nem? Mert en csak ezt hallom.

--

"SzAM-7 -es, tudjátok amivel a Mirage-okat szokták lelőni" - Robi.




      

    
        

                

  

  




  



    


    
  


  

    
            
[Flame vergődés detected: Másik észbeli képességeinek fikázása és newbie-nak való feltételezése]

Az a 8000 az vadiúj osztály? Hát persze. 



Figyi, te mondtad, hogy megismerted az API-t egy év alatt. Én ebben kételkedtem, de végülis naponta 21 osztály átnézésével egész jól megy, igazad van... Az hogy megutáltad, az egy dolog, de nem a Java API-t utáltad meg, nem is a Java nyelvet, hanem ha jól vettem ki, akkor az EJB-t. Képzeld el, hogy éppen egy olyan cégnél dolgozok, akik szinte minden szerver oldali throughput alapú feldolgozó alkalmazását Java-ban írja (1200+ Java programozó), és nem használ EJB-t. Ez is egy út, csak megjegyzem :)



Az iwiw-vel egyébként félelmetesen jó pontra akadtál, merthogy én még részt vettem abban az invite-only teljesítményelemzésben, amit még a nagy T* felvásárlás előtt végeztek. A teljesítményének kevés köze volt a platformhoz, sokkal inkább a session-routerhez, és ha már itt tartunk, akkor a memcache-t is irtó pocsékul, feleslegesen használták. Arról nem is beszélve, hogy teli volt a kódjuk synchronized blokkokkal (hogy a memcache forrása vagy az iwiwé volt, nem emlékszem), ami webes környezetben a legkönyebb út az öngyilkosság felé. És mivel általános célú nyelv, még azt is megengedi, hogy a hibaüzenet megjelenjen :P El lehet ezek után képzelni azt, hogy egy lassú alkalmazás nem feltétlen a nyelv hibája? Azt tudtad pl., hogy a Google Adwords is Java-ban íródott? Az mégsem lassú :P



      

    
        

                

  

  



  



    


    
  


  

    
            
Valamit tisztazzunk mar. A nyelv != az APIkkal. Az egy dolog, hogy gyarilag adnak hozza "8000 osztalyt" amiben rengeteg irrevelans resz is van. Szerinted hany C library letezik egy atlagos UNIXon? Mindet kivulrol fujjak az emberek? Dehogy, van manual. Doxygen, stb (Java is ezt hasznalja..). Es szerinted az a normalis hozzaallas, hogy egy Java fejleszto bemagolja a 8000 osztalyt? Ekkora baromsagot.




      

    
        

                

  

  




  




  



    


    
  


  

    
            
Az a gond, hogy egy év elég volt az api megismeréséhez és megutálásához.



Vannak jelentős problémák mind a Java nyelvben, mind a Java implementációkban. Ezek egy részére születtek 3rd megoldások, más részére workaround-ok, harmadik része megoldatlan maradt.



Még mindig sok probléma van, holott a Sun most legalább beindult és nyomul, mert bizonyos dolgokban sarkában a .NET, bizonyos dolgokban pedig már pár éve csak a .NET hátát látjuk. Lenne mit csinálni és változtatni.



Kínkeserves "ezt lehet csak ide használni, de mégsem jó" -k sorozata után inkább feleannyi szenvedéssel és doksiolvasással megoldom gyorsabban más nyelven, gyorsabb futást és kevesebb memóriát etetve fel.



Igen, de ekkor rosszul választottad meg először a nyelvet, vagy rosszul mérted fel a tudásod. Az viszont érdekes, hogy a sok ilyesmi hozzászólás okán gyakran kiderül a szájhősködés. A Java egyik legnagyobb erőssége, az, hogy a sokkal gyorsabban és kevesebb munkával lehet benne fejleszteni. Ez azokra a fejlesztésekre érvényesek, ahol a Java már megvetette a lábát: web, visual-web, jópár típusú alkalmazás, J2ME.



Ugye, minek a 10 szerver, ha EJB nélkül nem kéne az a 10 szerver? ;-)



Mert 10 szerver olcsóbb, mint 2 programozó egy éves bére. És amit lehet géppel csinálni, azt csináljuk géppel, akkor is, ha sok-sok programozó órával kisebb gép is elvinné.

--

http://www.javaforum.hu



      

    
        

                

  

  




  



    


    
  


  

    
            
Szopó, mert nem én választhattam nyelvet... szóval jogos.



A szajhoskodes meg mar akkor kiderul, amikor azzal indokoltak a java-t, hogy mertcsak.



A 10 szervert meg szorozd fel 2 évre az elhelyezési költségekkel meg ilyesmikkel :)

--

"SzAM-7 -es, tudjátok amivel a Mirage-okat szokták lelőni" - Robi.




      

    
        

                

  

  




  



    


    
  


  

    
            
Szopó, mert nem én választhattam nyelvet... szóval jogos.



  Mindegy, valaki rosszul döntött.



A szajhoskodes meg mar akkor kiderul, amikor azzal indokoltak a java-t, hogy mertcsak.



  Ez a "mert csak" nem egészen stimmel. Lehet, hogy nagy cégek nagy vezetői csak úgy szórják a pénzt, és az is lehet, hogy nem értenek hozzá, de egyre inkább Java-t választanak, mert olcsóbb. Vagy meggyőzőbb. Minden program elér egy olyan szintet, ahol nem tud tovább fejlődni, nem lehet már átlátni és ekkor elég jelentős paradigmaváltás lesz szükséges. 10-15 éve az OOP szemléletre váltás volt szükséges, különben tele lett volna minden elmegyógyintézet megőrült programozókkal, mert akkora kódmennyiséget nem lehetett a régi módszerrel karbantartani.



  Most ismét szükséges egy ilyen paradigmaváltás, mert a webes rendszerek minimum két oldalon futnak: a szerveren és a kliensen, de néha már bejön az adatbáziskezelőben írt PL/Java (vagy PL/* :) kód is. És ehhez nincsenek most még eszközeink. A GWT egy út, de nem új paradigma.



  A Java azért jó, mert ad egy "full-stack" futtatási lehetőséget mikrovezérlőktől kezdve, mobiltelefonokon és PC-n át a mainframe gépekig. És elég egy nyelvet ehhez megismerni, csak más framework-öt kell hozzá használni. Erre jelenleg csak a Java képes, nincs más technológia vagy nyelv.



A 10 szervert meg szorozd fel 2 évre az elhelyezési költségekkel meg ilyesmikkel :)



  Azé' 10 szerver üzemeltetése se olyan eget verő. Negyed annyi, mint egy programozó költsége. Természetesen lehet azt mondani, hogy 10 traktor helyett fizessünk 1000 kapást...

--

http://www.javaforum.hu



      

    
        

                

  

  




  



    


    
  


  

    
            
"és elég egy nyelvet ehhez megismerni, csak más framework-öt kell hozzá használni. Erre jelenleg csak a Java képes, nincs más technológia vagy nyelv."



s/Java/C/g



De hordozható zártforrású kódok számára, még mindig a JAVA -t ajánlom mobil eszközökre. (jazelle okán többek között)



      

    
        

                

  

  




  





  



    


    
  


  

    
            
WinCe nagyábbol win32 API-t használ.

GTK van winCE -re ... stb.

cegcc C forfító jól megy wince -re.



Irjál PIC -re AVR8-ra java kódot , erről beszéltem.



PocketPC+ARM  (wince 4.2 vagy újabb)-ra milyen JVM van ?



sizeof(long) , sizeof(void*) ami eltérő. (sizeof(long)==sizeof(void*) )

egyes esetkben a sizeof(long double) , De meg lehet írni úgy a kódot, hogy ez ne okozzon problémát.



szerk:

Félreértés ne essék, mobil eszközökre JAVA -t tartom legjobbnak, ha az a cél, hogy minden mobil eszközön menjen, és meze user ne fordítással tököljön.

De Pl. Camera kezelés mennyire megoldott benne ?



      

    
        

                

  

  




  



    


    
  


  

    
            
AVR8-ra én assembly kódot írtam, mert még a c kód is túl nagy volt.  De ez egy nagyon-nagyon speciális eset. Egyébként létezik avr (most gondolom az atmel cég pic szerű cuccairól beszélünk) - hez java "virtuális gép" is, de ezt max. az atmega sorozathoz használnám, amikor már van bőven hely.



      

    
        

                

  

  




  




  



    


    
  


  

    
            
WinCe nagyábbol win32 API-t használ.

GTK van winCE -re ... stb.



  Hát. Ebben mennyire vagy biztos? Még .NET programokkal is iszonyú szopás van, ha egy programot ki akarnak adni PocketPC-re is, akkor azt inkább újraírják (még). Talán a következő generációs PocketPC oprendszer megoldja ezt a problémát...

  Szóval próbáltad a GTK-t PocketPC-n? Kérdezd meg erről a FreeCiv fejlesztőket, mennyit szoptak azzal, hogy átportolják a FreeCiv-et PocketPC-re. Még mindig nem tökéletes, pedig ANSI C, és GTK.



Írjál PIC -re AVR8-ra java kódot , erről beszéltem.



ATmega mikrovezérlőkhöz van JVM, sőt, a 32 bites mikrovezérlőben van Java Acceleration Layer is.

http://www.javaforum.hu/?newsId=200#newsBody



PocketPC+ARM (wince 4.2 vagy újabb)-ra milyen JVM van ?



http://www.javaforum.hu/?newsId=305#newsBody



De Pl. Camera kezelés mennyire megoldott benne ?



A JSR 234-et már igen régóta támogatják a mobil oprendszerek.

--

http://www.javaforum.hu



      

    
        

                

  

  




  



    


    
  


  

    
            
Elég biztos vagyok benne. Egy pár függvény nincs, másiknak Ce -vel kezdődik a neve.

ANSI C cumók is meg vannak.

Nem csak GTK+C re deppendel nálam a FreeCiv, meg ugyebár a képméretek is mások.

gcc -> VS -nél lehetnek alapból gondok. De van cegcc.



8 bittröl volt szó.

Én C kód hasznalát is meggondolnám ilyen eszközöknél, nem hogy interpretáljak byte kódot, minimális API val.

De elomondhatod, hogy ez is van :)



thx. JVM-ért.



JSR 234 , thx.



      

    
        

                

  

  



  





  



    


    
  


  

    
            
Karenin ötlete nyomán (http://problemjava.blogspot.com/2007/04/klub_03.html) a fanatikus Java programozókhoz intézem most beszédem... :)



Mit gondoltok egy olyan összejövetelről, ahol nem az ivászat a fő cél, hanem egy fanatikus párbeszéd és előadások Java témában. Ha van erre kedvetek, akkor jelezzétek, ha van észrevételetek vagy kritikátok, akkor is... http://www.javaforum.hu/forum?categoryId=10&topicId=320

--

http://www.javaforum.hu



      

    
        

                

  

  




  




  



    


    
  


  

    
            
"A Java azért jó, mert ad egy "full-stack" futtatási lehetőséget mikrovezérlőktől kezdve, mobiltelefonokon és PC-n át a mainframe gépekig. És elég egy nyelvet ehhez megismerni, csak más framework-öt kell hozzá használni. Erre jelenleg csak a Java képes, nincs más technológia vagy nyelv."



http://www.python.org/download

http://www.python.org/download/other/



      

    
        

                

  

  



  



    


    
  


  

    
            
Java egyik legnagyobb erőssége, az, hogy a sokkal gyorsabban és kevesebb munkával lehet benne fejleszteni. Ez azokra a fejlesztésekre érvényesek, ahol a Java már megvetette a lábát ...



Megint egyetértünk. Azzal a kitétellel, hogy a Java mindenhol jó (jobb, mint pl. a C++), ahol van elég RAM. Attól, hogy valamely területen a Java még nem vetette meg a lábát, még nem biztos, hogy ott nem válna be. Egyszerűen csak más nyelvek lépéselőnyben vannak, és az embernek nincs kedve az idejét ennek a lépéselőnynek a behozására elpocsékolni.



      

    
        

                

  

  



  





  



    


    
  


  

    
            
És ha én a másikat állítom, akkor tévedek? Ha 100 ember velem szemben állítja akkor tévedek? Ha 100 ember veled szemben, akkor te tévedsz? Ha 100-100 ember van, akkor kimennek a rétre és leverik egymáson?



Van egy csomó szempont, ami nem mérhető, ilyen az olvasottság is. Ami egyértelműen mérhető, az a pénz. Pénz az, hogy kiképzik az embert a feladatra, de amire egy céghez kerül, ez csak a fizetésben tisztul le: a nehezebben megtanulható dolgokat kevesebben fogják tudni, azonos egyéb (ez fontos hogy azonos egyéb!) feltételek esetén a kevesebb ember több fizetést kaphat. Pénz az, amíg a program elkészül, idő*fizetés. Aztán a program működik, de nincs hiba nélkül, vagy csak változnak a körülmények, és bele kell nyúlni, módosítani. Idő*fizetés.



A Python 1991-ben jelent meg, a Java hivatalosan 1995-ben. Igazi ipari támogatottsága 1999 előtt nem volt. Most mégis az az egyik legelterjedtebb fejlesztési platform. Nem mondható rá az, hogy azért mert előbb volt ott. Nem mondható rá az, hogy nem fejlődött az idők során, lásd pl. a generics a leglátványosabb új nyelvi elem. És a cégek sem azért használják, mert trendi, hanem mert alapvetően olcsóbbá tett nekik egy csomó dolgot. Ha a fejlesztő fizetését konstansnak veszed, akkor pl. lerövidítette az időt... vagy valahogy valami jobb lett...



És akkor amit mondtál:



Előzmény: "Akkor még nme találkoztál szép, egyszerű és hatékony, jól olvasható nyelvvel..."

Én: "Az API fontosabb, mint a nyelv szintaxisa..."

Te: "Ebben teljesen igazad van, ha csak az ipari/üzleti fejlesztéseket nézed."

Én: "Tehát ami pénzt termel, arra jó a Java, ami meg nem termel pénzt, arra meg megteszi más is? :)"



Szerintem beszéljük meg egy sör mellett... :)



      

    
        

                

  

  




  



    


    
  


  

    
            
"És akkor amit mondtál:

Előzmény: "Akkor még nme találkoztál szép, egyszerű és hatékony, jól olvasható nyelvvel..."

Khmm. Ezt nem én mondtam, hanem gthomas.



Én ezt írtam:

"1. Akkor szerinted, ha az emberek azt állítják, hogy számukra az egyik nyelv olvashatóbb a másiknál, akkor bizonyára tévedek. "

Erre te:

"És ha én a másikat állítom, akkor tévedek? Ha 100 ember velem szemben állítja akkor tévedek?"

Felhívnám a figyelmedet a _számukra_ szóra.



A két nyelv elterjedtsége közötti különbséget senki sem vitatja.

Az oka nagyrészt a mögöttük lévő/nem lévő világcég(pénz) megléte. Jó példa erre a hasonlóan egyetlen üdvözítőnek és legjobbnak kikiáltott c# és .NET platform.

Érdekes lesz ennek fényében néhány év múlva megnézni, hogy mennyire változik majd a Python elterjedtsége, az IronPython Microsoft általi felfuttatása után.




      

    
        

                

  

  




  



    


    
  


  

    
            
Ocaml sem terjed, pedig van pénzes cég áll biz. implementáció mögött.



Ha már itt tartunk, JAVA -hoz viszonylag sok ember ért, sok ember tanult C -t mégsem tud rendes kódot írni, de JAVAban tud, mert a nyelv elveszi tőle azokat ez eszközöket amivel lábon tudja lőni magát...



A kód olvashatóságát, a beszélő azonosítók ill. megjegyzések befojásolják.

Matematikai részeknél az operátor tulterhelés segít.



Valamint a jó megjegyzések, pl mehódus/függvény esetében

- Mit vár a bementként

- Mi a feladata

- Mi a kimenete

- Mi a mellékhatása, ha van

I/O akkár Hoare formulaként :)




      

    
        

                

  

  




  



    


    
  


  

    
            
A Python hivatalos része az újabb Apple oprendszereknek.

Az IronPython egyenlőre nem része a Windows-nak, de ha a Microsoft komolyan gondolja (különben minek fizeti a fejlesztőit), akkor még sokat fogunk hallani róla.

Vagy nem :) Majd meglátjuk.



A Java nyelv előnyeit nem kell ecsetelned. Nem azért vitázom syntern kollégával, mert nem szeretem a Java-t, csupán egyetlen tulajdonságával(olvashatóság) kapcsolatban vagyunk más nézeten. Bár szerinte ez a tulajdonság nem is létezik :)



Olvastad fentebb a két kódrészletet? (Java/Python, kommentek nélkül.)



      

    
        

                

  

  




  



    


    
  


  

    
            
Igen olvastam.



Egy bonyolultabb algoritmus olvashatósága nem a nyelven múlik. (Szeretem, ha bonyesz rész tanulmányozása közben nem kell sokat scrollozni, ha hasonló részek defineolva, vagy inline függvényként vannak..)

De bonyolult dolog, akkor is bonyolult :)



python és testvérei híresek az áttekinthetőségről és egyszerűségükröl.

És erőforrás zabálásbol milyenek ?



      

    
        

                

  

  


  



    


    
  


  

    
            
Az olvashatóság szerintem az eszköz támogatottságon is múlik. Javában vagyok otthon, nem tudom, hogy Pythonban hogy működik az ilyesmi, de egy példa:



Eclipse alatt betöltve egy forráskódot, ha a függőségeket kifésültük, hogy minden infó benne legyen a projekt definícióban, akkor minden azonosító linkként működik az eszközön belül, ami a forráskódra navigál. Miután a Sun már az 1.5 forrását is kiadta, akár a könyvtári metódusok forrásába is belelátunk, sőt a JavaDoc-ot is gyorsabb így elérni, mint weben. A másik irány is működik. Egy változónkra, vagy metódusunkra kattintva lekérdezhetjük, hogy honnan hivatkoznak rá. Ez csak egy példa arra, hogy milyen "varázslatok" vannak egy-két kattintásnyira a kezünkben, ha Javát használunk.



Én az ilyen eszközök miatt szeretem a Javát. Persze ilyet nyilván lehet más nyelvekhez is csinálni, de Javahoz a nagy támogatottsága miatt könnyen elérhetőek ezek az eszközök.




      

    
        

                

  

  




  



  




  



    


    
  


  

    
            
Khmm. Ezt nem én mondtam, hanem gthomas.



És én tudatosan nem is azt írtam, hogy Te: hanem azt hogy Előzmény. Akkor most hogy tisztáztuk a tudatosságot...



Felhívnám a figyelmedet a _számukra_ szóra.



Értettem én, sőt azt is megértem, ha valaki brainfukkban vagy whitespace-ben (utóbbihoz van syntax highlight is) akar kódolni, attól még van egy olyan dolog, hogy általános használhatóság. Van, aki tökéletesen elégedett az assemblyvel, van akinek ez nem elég, van aki csak modell alapú kódgenerálás kell, van akinek valahol a minden közben. Ha megkérdezel 100 asm és 10 Java programozót, akkor azt szavazzák meg, hogy az asm a világ legolvashatóbb nyelve, fordított arányoknál nyilván fordítva. Azonban az általános használhatóság az az, amit az elterjedtségi adatok is mutatnak, teljesen mindegy, hogy én vagy te mit gondolunk ezekről...



Juteszembe: ezt már nézted? http://www.jython.org/

"Jython is an implementation of the high-level, dynamic, object-oriented language Python written in 100% Pure Java, and seamlessly integrated with the Java platform. It thus allows you to run Python on any Java platform."



Hajlandó lennék segíteni egy olyan teljesítménymérésben, amelyik egy bonyolultabb python kódot futtat Java-ban és natívan (jelentsen ez bármit, itthon egy Debiant tudok ajánlani a futtatáshoz). 



      

    
        

                

  

  




  



  



    


    
  


  

    
            
Mégegyszer idézek tőled:



"És akkor amit mondtál:



Előzmény: "Akkor még nme találkoztál szép, egyszerű és hatékony, jól olvasható nyelvvel..."



Kicsit mulatságos, hogy olyasmiről is akarsz velem vitatkozni amiről én semmit sem írtam. Mégegyszer leírom. Tisztában vagyok a Java és Python elterjedtsége és sebessége(teljesítménye) közti különbségekkel. Ezen ne erőlködj tovább :)

Az _olvashatóságról_ nem egyezik a véleményünk. np




      

    
        

                

  

  




  





  




  




  





  



    


    
  


  

    
            
Igen, éreztem, h kéne valami jó példát is felhozni, de maradtam az SZVSZ-nél. :-)

De szerintem Te is beismered azt, hogy vannak olyan problémák ahol nagyon fontos az, hogy milyen nyelvet használnak.

Hozzászólásodból ítélve picit többet többet programoztál csapatban mint én.

Egy példa: egy nagy és összetett problémát nem assemblyben ír meg valaki, bármilyen összeszokott csapatban is programozik, ám olyan (rész)problémát ahol nagyon nagyon fontos a futási idő, nem pl javaban, hanem assamblyben írnak. Szerintem.

----

Bárcsak...



      

    
        

                

  

  




  




  




  



    


    

      

  


      
( bocs
   | 2007. 03. 31., szo – 14:58 )

      
            
      

        
        
        
      

      
    

  


  

    
            
akkor a sok szószaporítás helyett számok:

http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=java&…



itt a Java HotSpot(TM) Server VM (build 1.6.0-b105, mixed mode) és gcc c++ van összehasonlítva, külön kezelve a startup kérdését.



sebességre: az átlag kb 2 (ennyiszer gyorsabb a c++)

memóriára:  az átlag kb 8 (ennyiszer kevesebb memóriót eszik a c++)



kösz, még egy kicsit várok az átállással, nálam bizony memória is, cpu lezabálás is számít



      

    
        

                

  

  




  



    


    
  


  

    
            
Két megjegyzés:



1. Egy ilyen statisztika csak akkor ér valamit, ha -client opcióval is futtatják a Java-t, ugyanis előfordulhat, hogy még be sem indult a HotSpot, vagy a 7-8 másodperces futásidő (pl. rekurziós példa) egy jelentős részében az interpretálásról áll át bináris kódra. Úgy általában akkor van értelme sebességről beszélni, ha van egy programod, és azt _sokáig_ futtatod.



2. Senki nem mondta, hogy minden példára gyorsabb a Java. Én már belinkeltem több olyan példát is, amire gyorsabb, most van olyan, amire nem. A lényeg, hogy átlagosan összemérhető a sebességük :)



      

    
        

                

  

  




  





  



    


    
  


  

    
            
És a harmad-negyedannyi fejlesztési időt?:) Mert igazából ez az, amiért ma az üzleti fejlesztések nagy része inkább Java-ban (C#-ban, Ruby on Rails-ben, akármi magasabb szintű nyelvben) folyik és nem C,C++-ban.



1 normális fejlesztő 1 hónapban teljes munkaidőben belekerül az embernek közel 500e-1M HUF-ba (padavanok kevesebbe, jedi masterek többe:). Ilyen piaci árakon nagyon nem mindegy, hogy egy sw funkcionalitását két hét alatt lehet összerakni, vagy két hónap alatt.



Ha Java-ban feleannyi idő alatt megvan a projekt, és a fennmaradó pénzből ki lehet fizetni a kétszer annyi CPU-s és 8x annyi memóriát tartalmazó gépet (mert mondjuk épp van még ilyen gép a piacon, és olcsóbb, mint a fejlesztés költsége), akkor Java-ban kell fejleszteni.



A Java feleannyi ideje pedig nem nyelvi érdem - sokkal inkább az elérhető API-k és open source lib-ek tömkelegének köszönhető, mint a nyelv fantasztikus lehetőségeinek. 



      

    
        

                

  

  




  



    


    
  


  

    
            
Teljes mértékben egyetértek veled, de én jobban hiszek abban hogy megfelelő mennyiségű fejlesztésidő, humán erőforrás és pénz biztosítása egy projecthez elengedhetetlen. Mert a JAVA alapvetően nem a szomszéd Pistike személyes portáljánál kerül előtérbe, hanem üzleti portálok, és vállalati rendszereknél. Egy ilyen projectnél nem csak a fejlesztők szólnak bele, vagy leginkább azok nem szólnak bele a rendelkezésre álló eszközök megválasztásába, hanem a managment.

Az időfaktor általában valós problémát jelent, de az anyagi források szerintem csak a kis cégeknél bírnak befolyással a használt rendszer megválasztásánál (de róluk inkább ne beszéljünk, mert nem hiszem hogy biztonsággal végig tudnak vinni egy nagyobb JAVA vagy .NET projectet).

Nálunk pl. fejlesztési konvenció egyértelműen tiltja a open source lib-ek használatát, aminek jogi, etikai, garanciális, biztonsági stb. okai vannak. (Nyilván nem jól jönne ki ha egy Brand alatt egy GPL licenc állna)

De hozzáteszem még az Internet, és a USB drive is korlátozva van ebből a szempontból. Az is nagy eredmény, hogy elértem hogy a HUP letölthető... :(



      

    
        

                

  

  




  



  



    


    
  


  

    
            
Nálunk pl. fejlesztési konvenció egyértelműen tiltja a open source lib-ek használatát, aminek jogi, etikai, garanciális, biztonsági stb. okai vannak.



  Ez azért már a ló túlsó oldala... :)

  Egy csomó dolgot fel tudnék sorolni, amiből nincs színvonalas kereskedemi megoldás.

--

http://www.javaforum.hu



      

    
        

                

  

  




  



    


    
  


  

    
            
Ez azért már a ló túlsó oldala... :)

Na ez is igaz, de azt mondják elsődleges szempont a biztonság, mert kb. 1500 ember melózik az irodákban 3 műszakban, tehát ragaszkodnak a High-availability fenntartásához. Ha valami nincs akkor fejlesszünk! Vagy ha az IT -nek nincs rá kapacitása, akkor az alvállakozók... Ők csinálhatnak akármit, ha át tudják nyomni az auditoron, de álltalában belátják hogy érdemes saját kódot beszállítani mert a g..i auditor különös érzékkel tud kellemetlen kérdéseket feltenni :)

Volt már olyan is hogy fejlesztettünk valamit, aztán mégsem került bevezetésre :D




      

    
        

                

  

  



  



    


    
  


  

    
            
Klasszikus Not Invented Here szindrómát érzek, úgyhogy el ne mondd a managementednek, hogy már a java is open source:) Rúghatnák ki az 1500 embert...



A jogi okokat még csak-csak értem amúgy, de mi köze mindennek az etikához? Az open source de jure etikus imho.



Weblogic 10-be glassfish-ból emelt át a BEA komplett .jar-okat. Akkor az most etikus? Igen az. Lehetnek jogi nehézségek? Nem, mert a licencet elolvasták és az engedi. Lehetnek garanciális-biztonsági okok? Lehetnek, azért van gondolom sok száz programozójuk, hogy ezt megoldják.



Ez a kategórikus tiltás imho orbitális, kapitális baromság. Természetesen a gondolkodás nélküli átvétel is az. De meg kell találni a kettő között az egyensúlyt és létrehozni egy normális process-t open source licencű könyvtárak átvételére.




      

    
        

                

  

  



  



    


    
  


  

    
            
nézd, nagyjából egyetértünk: right tool for the right job.

a pénz és a technológiai korlátok szabják meg az eszközt.

Mondjuk én olyan környezetben dolgozom, ahol éppen a 8 x sok memória az már túlsok (annyi már nem férne el az ügyfél gépében) - ugyanígy a 2xCPU is.



off

De azért rendkívüli módon utálom a tohonya szörnyeteg programokat, amelyekről becsukott szemmel megmondom, hogy javas/NET alapon készültek, annyira a használhatatlanság határát súrolják.

on



      

    
        

                

  

  



  



    


    
  


  

    
            
Minden nyelven lehet memoriazabalo programokat irni.

Lehet tudni a java-ban is, mire figyelj, es akkor nem lesz gond. Az, hogy itt a memoriat a vm kezeli helyetted, az csak a moricka programozas szintjen igaz. Baromi konnyu ottfelejtett korkoros referenciakkal memory leak-et gyartani. Altalaban sikerul is, aztan jon a profiler, es meg kell keresni.

A masik ok legtobbszor az agyatlan mennyisegben lefoglalt, es rogton eldobott objektumok. (pl. s1=s1+s2; lehetoleg 10000-es for ciklusban, de meg lehetne ragozni.)



Azonban a memoria zabalas legfobb oka, hogy a java mindent 8 byte-ra illeszt. Igy lehetseges, hogy szerencsetlen ures string 48 byte. (4 mezo, +egy pointer a tipusra.) Nem tudom 64 biten mit csinal, de az meg lehet ennel is rosszabb.

Ez tenyleg kapitalis okorseg, de ugy latszik nem ertekelik komoly problemanak, illetve a processzor vegrehajtas szintjen szereti.

Persze ha annyira fontos, lehet irni sajat string osztalyt, amihez foglalsz egy byte vagy int tombot, es abbol osztod neki a memoriat. Ha kritikus a string, es egyaltalan a valtozo meret, nem hiszem hogy van mas ut.

De en ilyet nem csinalnek:

1, ha a user szam magas, akkor clustert kell epiteni

2, ha a feldolgozando adatok mennyisege nagy, akkor fel kell darabolni a problemat, vagy nem veszodni vele java-ban, hanem irni ra egy tarolt eljarast.




      

    
        

                

  

  




  





  





  





  



  



    


    
  


  

    
            
ugye ha a c++ fejlesztő hibázik, és leakel a dolog (ami ugye a c++ smart pointer korában majdnem kizárt), akkor néhány kivételes esetben néhány memóriablokk leakel. Az összes többi meg abban a pillanatban megpusztul, amikor nincs rá szükség.



A Java-nál pedig felfogás kérdése, hogy a default viselkedést úgy hívjuk-e hogy "semmi sem leakel" vagy úgy hogy "minden lefoglalt blokk leakel" (8-szoros memóriafoglalás).




      

    
        

                

  

  



  



    


    
  


  

    
            
high-end: a megoldásoddal a hardver architektúra korlátait feszegeted (nem zéró költségkeret mellett).



Nálunk az adott vasba nem tudsz annyi memóriát belerakni, amire Java-nak szüksége van (néha esetleg nem is elég neki, ki tudja), más megoldással viszont (c++) vígan elfut a dolog.



off

hát igen, a felfogás nem ismeretlen számomra: vegyünk N olcsó Java-s programozót, csináltassuk meg velük a rendszert. Ha falnak ütközünk (mert a Javas újonsoknak fogalmuk sincs róla, mi az hogy pointer), akkor hívjunk 1-2 c++ gurut, és írassuk velük újra a rendszert, aminek egy nagyságrenddel jobb lesz a teljesítménye.

Elismerem, hogy gazdaságos, csak az én mérnöki szemléletemnek ez gusztustalan.

on



      

    
        

                

  

  




  



    


    
  


  

    
            
high-end java-s olvasatban: skálázódnia kell nem meghatározott számú felhasználóig. Meg lehet csinálni (lásd pl e-bay). Kicsit talán ez okozza a szemléletbeli különbséget - az egész Java platform abból indul ki, hogy a hálózati, elosztott működés adottság és nem luxus (persze, tudom van CORBA C++-ban is).



Ezen a 8x-os memórián lépjünk túl - egy jvm process alapvetően annyi memóriát használ, ammenyit adsz neki (ha csak 64m-át akkor annyit). Az alap GC pedig úgy működik, hogy csak akkor van garbage collection, ha a heap egy bizonyos területe betelik (és akkor is alapesetben csak azon a területen fut gc - ami pl a young generation esetében egy nagyságrenddel gyorsabb algoritmus, mint a tenured gen esetében - megintcsak alapesetben). Kevés heap -> több gc -> kisebb throughput természetesen igaz lesz, de a túl nagy heap sem feltétlenül jó dolog. De feladata válogatja, és heap tuninggal (-Xmx, -Xms, generation ratio-k állítgatása, GC algoritmusok kapcsolgatása) rengeteget lehet változtatni egy java program memória és/vagy cpu használatának karakterisztikáján. Lassan egy külön szakma lesz ez is. Gigabyte-os memóriaméreteknél pedig nem hiszem el, hogy van olyan feladat, amit C++-ban meg lehet csinálni, de Java-ban pedig nem.



Olcsó java programozók: ma a magyar piacon jó Java programozót vagy olcsó java programozót tudsz venni. Ez a kettő diszjunkt halmaz. Nem véletlenül. Ha csináltál egy Java-s projektet és teljesítményproblémáid vannak, inkább Java gurukat hívj - talán többet tudnak segíteni (nem, nem csak a gc-t fogják tunigolni...). És ott is meg lehet csinálni a nagyságrenddel jobb teljesítményt.




      

    
        

                

  

  




  



    


    
  


  

    
            
A mai napig nem értem, mi szükség van a GC-re? Néhány egyszerű alapelvet kell betartani a C++ program fejlesztésekor és sosem lesz memory leak-ed.

Sok éve programozom C++-ban és még soha nem kellett memory leak-ekkel vesződnöm. Számomra a GC-nek semmi értéke sincs.

És sok olyan C++ programozó van, aki inkább tartja magát néhány egyszerű alapelvhez, amit 5 perc alatt fel lehet fogni és nem bízza a programja felügyeletét egy kiszámíthatatlan rendszerre.

Szerintem ez a GC csak egy rossz workaround egy nem létező problémára.



A másik problémám, hogy már a felsőoktatásban is Javát tanítanak. Ennek az az eredménye, hogy ezek az emberek soha, vagy csak komoly szemléletváltás után lesznek képesek használható C++ programot írni. Ezért aztán jelenleg C++ programozóból egyre nagyobb hiány van, márpedig olyan területeken, ahol a determinisztikus eszközök használata megkerülhetetlen, nem lehet ilyen GC-s megoldásokat használni.



      

    
        

                

  

  




  



    


    
  


  

    
            
A mai napig nem értem, mi szükség van a "class"-ra. Néhány egyszerú alapelvet kell betartani a C program fejlesztésekor, és sose lesz rá szükséged. Sok éve programozom C-ben, de egyszer nem hiányzot a class. Számomra semmi értéke sincs. És sok olyan C programozó van, aki inkább tartja magát néhány egyszerű alapelvhez, amit 5 perc alatt fel lehet fogni és nem bízza a programja felügyeletét egy ilyen mechanizmusra (virtual? blah - pointer függvény rulez).



Szerintem ez a class csak egy rossz workaround egy nem létező problémára.



A másik problémám, hogy már a felsőoktatásban is C++-t tanítanak. Ennek az az eredménye, hogy ezek az emberek soha, vagy csak komoly szemléletváltás után lesznek képesek használható C programot írni. Ezért aztán jelenleg C programozóból egyre nagyobb hiány van...



de lehetne s/c/asm/g is...



      

    
        

                

  

  




  



  





  





  




  



    


    
  


  

    
            
A helyzet nem ilyen egyszerű, ugyanis a Java a C++ erős lebutításával jött létre. Akkoriban (kb. 15 éve) sok progbléma volt a C++ használatával, mivel nem voltak kiforrott metodológiák, fejlesztőeszközök, osztálykönyvtárak stb. A fejlesztőeszközök továbbá nem nyújtottak semmilyen megoldást a memory leak-ek azonnali detektálására sem.

így aztán a C++ nyelvből kihajítottak minden elemet, ami akkoriban veszélyesnek számított, hozzácsapták a GC-t, a VM-et és a reflection-t és készen lett a Java.

Ma viszont egészen más a helyzet. Ha normális fejlesztőeszközt használsz, nagyon hülyének kell lenned, hogy elkövesd azokat a hibákat, amire a Java megoldást akar nyújtani. Az egyetlen hátrány, hogy reflection nincs C++-ban, de az esetek többségében egészen jól meg lehet lenni nélküle.

Viszont C++-szal megmarad a natív kód sebessége, a memóriafogyasztás tizedakkora és még a kódolás is sokkal egyszerűbb, a forrás átláthatóbb, mert nem kell a Javából hiányzó nyelvi elemek miatt nyakatekert kódokat írkálni.



      

    
        

                

  

  




  



    


    
  


  

    
            
[b]A helyzet nem ilyen egyszerű, [...] nem kell a Javából hiányzó nyelvi elemek miatt nyakatekert kódokat írkálni.[b]



Hmm... mi lenne ha megnéznél néhány linket a témában, mielőtt ilyesmi - amúgy teljesen légbőlkapott - okfejtésekre szánod el magad? :)



Mutass már egy C/C++ nyelvű EJB3.0 és JPA jellegű tudással egy rugalmasan használható rendszert. Marha kíváncsi vagyok, de ezt már írták előttem itt ezen a fórumon. Ahogy azt is, hogy a C/C++ projektek mozgástere folyamatosan szorul vissza, és jön fel a Java (és a .NET). Tény. Nézz körül.

--

http://www.javaforum.hu



      

    
        

                

  

  


  




  



    


    
  


  

    
            
A mai napig nem értem, mi szükség van a GC-re? Néhány egyszerű alapelvet kell betartani a C++ program fejlesztésekor és sosem lesz memory leak-ed.

Sok éve programozom C++-ban és még soha nem kellett memory leak-ekkel vesződnöm.



  Mennyi az az idő, amely a programjaid átlagos futásidejét jelentik?

  Olyan projektek, mint a FireFox, vagy az Apache eléggé memory-leak gyanús programok. Az Apache 2.x esetén szögeltek ezen, de az 1.3 széria például azzal oldotta meg a memory-leak problémát, hogy X időnként főbelőtte a worker child processzt, és reménykedett benne, hogy még időben lőtte fejbe.



Szerintem ez a GC csak egy rossz workaround egy nem létező problémára.



  A GC nagyon jó dolog. Sőt, nem is egy GC algoritmus van, hanem több. Sőt, lassan eljutunk oda, hogy adhatunk annotációval tippet a GC-nek. De a GC nem felejt, nem megy kávé vagy cigiszünetre, nem hívják fel telefonon, és nem is bámulja meg a titkárnő melleit. A legtöbb memory-leak ezekből következik ebben a sorrendben.



Ennek az az eredménye, hogy ezek az emberek soha, vagy csak komoly szemléletváltás után lesznek képesek használható C++ programot írni.



Miért kellene C++ programot írniuk? A trendek szerint megy minden a web irányába. Ott pedig nem létezik C++ jelenleg és nem is fog. Windows-ra C#.NET, UNIX-ra mehet még a C++, de már ott erősödik a Java (és a .NET). A C++ egyre szűkül, azokra a feladatokra, amire jó (database core, opsys kernel, opsys driver, stb) pedig megvannak a programozók. Egy éve még kevesebb Java projekt volt a FreshMeat-en, most már jóval több, mint C++ és a C projektek száma is stagnál. Nem mondom, hogy tendencia, de logikus dolog.



ahol a determinisztikus eszközök használata megkerülhetetlen, nem lehet ilyen GC-s megoldásokat használni.



Ezt mesélted már azoknak a mérnököknek is, akik RealTime Java-t csináltak RT-GC-vel? Az pedig determinisztikus. Másrészt a GC egyébként se úgy megy, hogy dob egy kockával a JVM és aztán csinál egy véletlenszám alapján történő memória felszabadítást. A lokális változók mindig felszabadulnak, kivéve, ha referenciaként egy ilyet ad vissza a metódus. Aztán ha a meghívó metódus nem adja vissza ezt a referenciát, akkor a GC ezt meg fogja szüntetni. C++ esetén külön szopás ezt nyilvántartani, hogy mit adtál át cím szerint és hol lehet megszüntetni, mikortól nem használja már a programod. Ebből adódnak a memória-leak-ek, nem abból, hogy blokk vagy metódus végén felszabadul-e a memória.

--

http://www.javaforum.hu



      

    
        

                

  

  




  





  




  



    


    
  


  

    
            
Azt hiszem, más a működési területünk, azért látjuk ezt ennyire máshogy.



nekünk /majdnem online képfeldolgozás, MB/s-os nagyságrendben/ sokszor csak a scaling up marad - kizárt az elosztott rendszer: elavul az adat, mire etherneten odaér.



Egy üzleti alkalmazásnál a továbbítandó adatmennyiség nem kritikus, ott az egyidejű kliensek száma a fő korlát: ehhez tökéletes az elosztott rendszer, hiszen szinte költség mentesen kiskálázható.




      

    
        

                

  

  




  




  



    


    
  


  

    
            
Jo, ha tenyleg olyan a problema, hogy az adott(vagy meg inkabb a letezo) hardver keretek kozott rezeg a lec, akkor tenyleg jobban jarsz a c++-szal.

De ez iszonyu ritka.

Azonos tudasu embereket feltetelezve(mert te valamiert azt hiszed, hogy minden c++-os profi, es minden javas hulye), a java projekt hamarabb elkeszul, es egyszerubb megerteni, karbantartani, ne adj isten portolni.

Ja, es nem tudom hol allnak a c++-os fejlesztoi kornyezetek, de java-hoz nagyon profik leteznek. (inkrementalis forditas, azonnali kodellenorzes, refaktorok tomegei, kodkiegeszitesek, kodminoseg ellenorzes, profiler ...)

Minden relativ egyebkent, aki python-ban vagy php-ban dolgozik, ugyanazt mondja a java-ra, mint a javasok a c++-ra: korulmenyes, lassu a fejlesztes, es sok IQ kell hozza.



En elsosorban uzleti szoftverben utazom, ott kizart hogy megerje. Eddig minden esetben az adatbazis volt a szuk keresztmetszet, nem a java.

Persze az ostobasag nem hianycikk, jo pelda erre a rettenetes EJB szabvany, meg azok, akik esz nelkul alkalmazzak. Alkalmazni pedig muszaj, mert a fejlesztes kereteit egyre inkabb az ostoba managerek hatarozzak meg, meg azok, akik szeretnek megelni az uj buvszavakbol, a programozo meg szopjon, eroszakolja meg az egeszet, hogy a vegen nagy buszken ki lehessen jelenteni, hogy milyen szabvanyos rendszerunk van.



Ha mar valaki bele akar kotni a java-ba, akkor az apik, es foleg a J2EE kornyeket kapargassa meg. Egy mero borzalom. Szabvanyositottak nehany oltari hulyeseget, hogy ugymond barki tudjon vele dolgozni. A vege az lett, hogy nem az api ismerete a tudas, mert az semmi. Hanem azt kell tudni, hogy az adott megoldas/eszkoz milyen feltetelek/terheles mellett szarik be, mi a hulyesege, es esetleg hogy lehet megkerulni.



off

a java programozo nem olcso, hanem kimondottan draga. Uzleti szoftver kornyeken talan csak az SAP-sok keresnek jobban.

on



      

    
        

                

  

  




  



    


    
  


  

    
            
"Ha mar valaki bele akar kotni a java-ba, akkor az apik, es foleg a J2EE kornyeket kapargassa meg."



Azt is 1.4-ig. EE 5 jó lett, kifejezetten használható a korábbiakhoz képest. Persze ha valaki elment Spring irányába, annak édesmindegy, mert úgysem lehet "visszacsábítani" az EE technológiákra...



"egyre inkabb az ostoba managerek hatarozzak meg"



Ez itthon sajnos általános dolog. Próbálom hinteni az igét, hogy Agile methods, agilemanifesto.org és társai - meglássuk mi lesz ebből.



"Uzleti szoftver kornyeken talan csak az SAP-sok keresnek jobban."



Maximálisan igaz.



      

    
        

                

  

  


  



    


    
  


  

    
            
"Minden relativ egyebkent, aki python-ban vagy php-ban dolgozik, ugyanazt mondja a java-ra, mint a javasok a c++-ra: korulmenyes, lassu a fejlesztes, es sok IQ kell hozza."



Az oldalamat php-ban kezdtem el írni, mert hú de gyorsan meg lehet benne csinálni az oldalt. Aztán szép lassan egyre bonyolultabb lett, egyre több mindent tudott, végül úgy éreztem, ez már átláthatatlan, és nem igazán programozás már ez, sokkal inkább gányolás, ezért elkezdtem átírni javára az oldalt. No persze servlet, jsp, stb, és no EJB. Az úgyis csak lassít, és nem tudom kihasználni az esetleges előnyeit.



Ismerem a javát és a C++-t is, a feladathoz választom a nyelvet - egyikben sem könnyebb, mint a másikban. Javában pl. nehezen tudnék elképzelni egy visszázó rendszert (partíció visszatöltése, ilyesmi), míg C++-ban pl. egy webes alkalmazás megírása lenne körülményes.



      

    
        

                

  

  



  



    


    
  


  

    
            
Nálunk az adott vasba nem tudsz annyi memóriát belerakni, amire Java-nak szüksége van (néha esetleg nem is elég neki, ki tudja), más megoldással viszont (c++) vígan elfut a dolog.



Ismét csak azt tudom mondani, hogy hibás szemlélettel készült el a Java program. Profiler mit mondott, hol történik azonos algoritmussal ez a "nem tudsz annyi memóriát belerakni" esemény? Valami konkrétumot szeretnék látni ezügyben... C++ jellegű kódolással látatlanban borítékolom, hogy elfogy a memória. Java metodikával ugyan annyi elég, mint a C++ programnak... csak C++ esetén figyelni kell a felszabadításra, Java esetén ismerni kell a GC észjárását.



N olcsó Java-s programozót



Olcsó Java programozó? A Java programozók jelenleg az egyik leginkább megfizetett IT szektor...



"hát igen, a felfogás nem ismeretlen számomra: vegyünk N olcsó C++ programozót, csináltassuk meg velük a rendszert. Ha falnak ütközünk (mert a C++ újonsoknak fogalmuk sincs róla, mi az hogy programozás), akkor hívjunk 1-2 Java gurut, és írassuk velük újra a rendszert, aminek egy nagyságrenddel jobb lesz a teljesítménye."



  Kb. ennyit írtál, csak fordítva hangzik. Valami tény? Tényszerű? URL?

--

http://www.javaforum.hu



      

    
        

                

  

  



  



    


    
  


  

    
            
A felszabadítás lehet, hogy determinisztikus, azonban a foglalás nem az... Tördelés miatt a blokk foglalás ideje egyáltalán nem determinisztikus, sőt akár úgy is lehet sikertelen, hogy a hely rendelkezésre áll, csak darabokban. Ilyen Javában nem fordul elő.



Szóval minden relatív.



      

    
        

                

  

  


  



  



    


    
  


  

    
            
A C++ irto determinisztikus, kulonosen memoria modell nelkul, tobb cpu-s kornyezetben. De meginkabb ugy, hogy mind a fordito, mind a cpu valtoztathat az utasitasok vegrehajtasi sorrendjen [1]:



Az aktualis c++ spec az alabbiakat specifikalja:



-it only specifies the behavior of memory operations observable by the current program.

-it doesn't say anything about concurrent memory accesses when multiple processes access the same memory (there is no notion of shared memory or processes).

-it doesn't say anything about concurrent memory accesses when multiple threads access the same memory (there is no notion of threads).

-it offers no way to specify an ordering for memory accesses (compiler optimizations include code motion and recent processors reorder accesses, both can break patterns such as double checked initialization).



[1] http://www.hpl.hp.com/techreports/2004/HPL-2004-209.html

[2] http://www.hpl.hp.com/personal/Hans_Boehm/c++mm/mmissues/

[3] http://www.open-std.org/JTC1/sc22/wg21/docs/papers/2007/n2197.pdf

[4] http://stackoverflow.com/questions/220752/what-is-the-c-memory-model



      

    
        

                

  

  




  



    


    
  


  

    
            
Ez felremagyarazas, de sztem te is tudataban vagy. Ahol kell, ott mindent olyanna szabnak hogy megfelelo legyen. Akar java akar c++. A csupasz nyelv onmagaban szart nem er, ez teljesen vilagos.



Eppen ezert van az, hogy sok realtime OS eros tamogatast ad ilyen jellegu feladatokhoz. Minel tobb nyelvi kornyezetet tamogatva, annal jobb, nyilvan (pl c/c++ es java).



      

    
        

                

  

  



  



    


    

      

  


      
( szdl
   | 2007. 04. 02., h – 01:25 )

      
            
      

        
        
        
      

      
    

  


  

    
            

Fentebb írtam már, többen is említették ezeket, de azért érdemes összefoglalni (magam mostanában néztem körül e téren, ezért megosztom azokkal, akik nem tudnák - akik ismerik, bocs):



1.) Ha utálod a Java nyelvet, de Java alkalmazást akarsz (vagy olyat kell készíteni), nem csak Java nyelven írhatod!



Néhány példa:



GROOVY - egy új, de "könnyített" Java-szerű nyelv:



http://en.wikipedia.org/wiki/Groovy

http://groovy.codehaus.org/

http://www-128.ibm.com/developerworks/java/library/j-alj08034.html



Vegyesen használható "igazi" Java-val is:



http://groovy.codehaus.org/Mixed+Java+and+Groovy+Applications



Python hívőknek:



Jython:



http://en.wikipedia.org/wiki/Jython

http://www.jython.org/Project/index.html

http://wiki.python.org/jython/



Nem csak interpreter, java class-ba fordító is..



Ruby hívőknek:



JRuby



http://en.wikipedia.org/wiki/JRuby

http://jruby.codehaus.org/



(fordító folyamatban (?))



Meg ilyen is lenne:



http://en.wikipedia.org/wiki/C_to_Java_Virtual_Machine_compilers



Egyéb nyelvek JVM-re:



FORTRESS:  Fortran-szerű új nyelv (JVM fölött):



http://fortress.sunsource.net/

http://www.javaforum.hu/?newsId=213#newsBody



SLEEP: Perl-szerű (szkript)



http://sleep.hick.org/index.html

http://en.wikipedia.org/wiki/Sleep_programming_language



Régebbről:



JaCL (TCL-Java):



http://en.wikipedia.org/wiki/Java_Tcl

http://tcljava.sourceforge.net/docs/website/index.html

http://sourceforge.net/projects/tcljava/



Ilyen is volt: NetRexx (Rexx-Java):



http://en.wikipedia.org/wiki/NetREXX

http://www.ibm.com/software/awdtools/netrexx/



stb..



Hasonlók bővebben:



http://www.robert-tolksdorf.de/vmlanguages.html

http://c2.com/cgi/wiki?OtherLanguagesForTheJavaVm



stb.



Vagy:



Microsoft világból:



- Grasshopper (ASP.Net (C# és VB.Net) alkalmazások Java-ba fordítása!):



http://dev.mainsoft.com/Default.aspx?tabid=130



- C# és VB.Net _forráskódból_ Java _forráskód_!: net2java (NetBeans plugin):



https://net2java.dev.java.net/

https://net2java.dev.java.net/GettingStarted.html



- VB ("normál") forrásból Java forráskód,

(továbbá: ASP, Access, VB alkalmazásból Java (vagy HTML, vagy XUL! alkalmazás)):



http://www.diamondedge.com/products/Convert-VB-to-Java.html

http://www.diamondedge.com/



2.) Ha "utálod" a JVM-et, de a Java nyelvvel nincs bajod, akkor fordíthatsz natív (gépi) kódra. Nem kell JVM a java-hoz!



Pl.



- GCJ - GNU Compiler for Java - gépi kódba is fordít:



http://gcc.gnu.org/java/index.html



- Excelsior JET Optimizer & Runtime:



(Win32 és Linux natív executable-be "fordít" (optimalizál) + saját Java Runtime-ot kínál, de JVM nélkül!):



http://www.excelsior-usa.com/jet.html



(Egy cikk:



http://www.programmersheaven.com/2/Convert-Java-to-EXE )



Szóval ilyesmik..




      

    
        

                

  

  




  



  





  




  



  



    


    

      

  


      
( emberk
   | 2007. 04. 12., cs – 16:03 )

      
            
      

        
        
        
      

      
    

  


  

    
            
Biztos marhaság amit kérdezek, de hátha nem. Lehet java-ban oprendszert írni? Erre kíváncsi lennék, ja és ha lehet van értelme, nem lesz tetű lassú? (Csak mert még nem ismerem egyáltalán a java-t mondjuk nem is nagyon akarok megtanulni, jó nekem a C úgysem vagyok programozó, de kíváncsi vgyok).



      

    
        

                

  

  




  





  





  





  



    


    
  


  

    
            
Akkor gondolom ez csak részben java. Tehát tisztán java-ban nem lehet os-t írni.



  Mutass egy pusztán C nyelvű oprendszert. Ha nem tudsz, onnan már csak hitvita és szócséplés a mikrokernel nyelve, illetve a mikrokernelre épített réteg nyelve és ezek határvonala.

--

http://www.javaforum.hu



      

    
        

                

  

  




  





  



    


    
  


  

    
            
Már írtam nem vagyok programozó (csak c-ben tudok programozni de ott is csak matematikai problémák megoldására kell nekem, max file kezelés, bár tetszik élvezem a c-t jó agyalós nyelv, és gyors kódot is eredményez szeretnék benne továbblépni, de most nincs rá időm) érdeklődtem mert mindenhol java-val találkozok, és azt mondják hogy univerzális nyelv csak kíváncsi voltam hogy mennyire.



      

    
        

                

  

  




  



    


    
  


  

    
            
Ahol nem igazán lehet használni a java-t:



- nincs elég hely (pic kategória)

- nincs elég sebesség (386-os gépek)

- nincs elég / nem bővíthető memória (megintcsak pic kategória)

- nincs jvm az adott architektúrán

- tipikusan alacsony szintű feladatok (irq, stb.)

- nagyon gyors válaszidőre van szükség

- hülye megrendelő



Van még néhány eset, ahol nem érdemes, a többinél nyugodtan lehet

javazni.




      

    
        

                

  

  




  




  



    


    
  


  

    
            
És semmi nativ bináris hivogatásosdival.



  Semmi bináris hivogatósdi. A JVM megoldja ezeket a feladatokat. Vagy ez nem ér?



  Miért kell ennyire gyerekeskedni? Írd meg assembly nyelven, de semmi CPU mikrokód hívogatósdival.



  Solaris alatt vannak Java nyelven megírt device driverek is például.

--

http://www.javaforum.hu



      

    
        

                

  

  


  





  



    


    
  


  

    
            
Ha már regisztereket macerálgatunk, akkor úgyis otthon kell lenni gépikódban....erre való. Miért kéne C-ben regisztereket matatni ? Miért kéne C-ben protected módba váltani ? Azt már bootoláskor el kell intézni és akkor futhatnak a szálaid, amelyeket akár C-ben is írhattál....de hwközeli dolgokat továbbra is assemblyben programozol le. A C fordító - és minden natív kódot eredményező fordító - végső eredménye gépi kód...és a gépi kód legalacsonyabb, ember számára emészthető reprezentációja az assembly kód.



Éppen ezért a felvetés, hogy JAVA-ban oprendszert kéne írni, kicsit eszement dolog. Persze lehet, biztos létezik a java-hoz is compiler, ami tud belőle natív kódot generálni, csak a java talán nem tartalmazza az eszközöket az alacsonyszintű műveletekhez, tehát minek ?




      

    
        

                

  

  



  




  



    


    
  


  

    
            
Ami kritikus egy oprendszernél:



- taskok között gyors váltás

- megszakítások gyors kezelése



oprendszert lehet írni, mint később írták, de pont ezek a dolgok lassúak

lesznek. Lehetni lehet, de minek.



Inkább device drivert lenne értelme java-ban írni, illetve  pl. létezik olyan mikroprocesszor,

ami java bytekódot futtat. Annak az oprendszere is nyilván java-ban van írva.



      

    
        

                

  

  




  



    


    
  


  

    
            
ARM hez csak egy extension ,a jazelle . Nem JAVA OS szokott ezeken lenni.



A fentiekhez: aki OS-t akkar irni JAVA+JIT -el az forduljon orvoshoz.

Az alacsony szitű részeket egy részét mindenkep asm -ben kell megírni. JIT-VM -eket se jávában szokás írni, ha jól tudom.

Utánna lehet poénbol (működő)Java kernelt, java drivert írni, de nincs sok értelme.

Tehát csak cool factor miatt jó.



      

    
        

                

  

  



  



    


    

      

  


      
( tomi66
   | 2010. 01. 01., p – 19:02 )

      
            
      

        
        
        
      

      
    

  


  

    
            
Szép szál....Engem a JAVA előnyei is érdekelnének, mert nem látom őket. Sajnoshálaistennek elkerült a JAVA.

A hordozhatóságot ne hozzuk fel, ha lehet...még windows alatt sem mindegy, hogy sun jvm vagy microsoft....hát még platformok között.



Eredeti felvetésre, nekem nem emészthető, hogy írunk egy VM-et azért, hogy egy rendes vason egy operációs rendszer futtassa a virtuális masinát, amin fut a bytekód....




      

    
        

                

  

  




  





  





  



    


    
  


  

    
            
Windows családon belül is érthetjük, mert nem triviális dolog, hogy egy program ha fut adott Windowson, akkor másikon is fog. GUI és fájlrendszerek amit írtam pont az általad felsorolt OS-eknél sérül, nem Windowsok között. Azt sem felejtsük el, hogy nem csak x86-on futhatnak ezek az OS-ek.



      

    
        

                

  

  



  



    


    
  


  

    
            
keress vissza, mar szamtalan hosszu postot irtam arrol, hogy miert Java. a lenyeg: az ecosystem. mindenre van mar letezo megoldas, ha meg nincs, akkor egy kis burkolassal teljesen jol megoldhato a dolog (es meg OO-t sem sertesz).

sebessegben nem marad el c++ kodtol a hotspot, es eleg nagy helyeken is hasznaljak.



kivancsi lennek ki hany sorban hozna ossze egy felig-meddig mukodo JMS megoldast pl c++ban...



      

    
        

                

  

  




  



    


    
  


  

    
            
Amit irsz az a virtualis gepnek koszonheto, nem a nyelvnek. Ha a HW fejlodes a virtualis gep fele menne vagy egyseges OS API lenne (ami persze sosem lesz, teljesen ertheto modon), akkor nem lenne sok elonye.



A mindenre meglevo megoldas valoban csabito, amennyiben nem szamit az, hogyan van az implementalva. Ez persze mas libekre eppen ugy igaz. :)




      

    
        

                

  

  




  





  





  



    


    
  


  

    
            
a feladat adott, kerlek, meselj milyen szerverplatform van meg, amiben ezt mondjuk meglehet gyorsan csinalni...



(meg amugyis kivancsi vagyok Te mit tekintenel szerverplatformnak. ismerek par nyelvet, ismerek par kornyezetet, es nem talaltam meg megfelelo alternativat /nem csak a munkahelyem miatt vedem :-)/)



      

    
        

                

  

  




  



    


    
  


  

    
            
Hat mondjuk csak igy kezdetnek:



http://www.infoq.com/articles/vinoski-erlang-rest



A vicc az, hogy mas nyelvekben megirt modulok is kepesek erlang modulnak latszani, tehat nem kell az egeszet erlangba megirnod.



A livejournal-fele perlbal architektura er?



http://www.danga.com/perlbal/



A legfobb problemad amugy te is tudod, a cache-reteggel lesz, ez lehet pl. memcached, vagy nagyobb meretekben coherence.



Pelda coherence-php parositasra:

http://blogs.oracle.com/felcey/2009/11/caching_php_http_sessions_in_c.h…

http://209.85.135.132/search?q=cache:6y0ubo6NiQ4J:blogs.oracle.com/felc…



Kozbe keresem neked a flickr prezijet, azok se java-t hasznalnak.



En azt latom, mindezt ugy, hogy a titulusom senior java engineer, es mellettem fejlesztik a vilag 10 legnagyobb website-janak egyiket javaban, hogy a vilag megelozte a javat, es barmiben el lehet erni azokat a ficsoroket, amik kezdetben csak - de vagy 5-10 eve - javaban voltak elerhetoek.



      

    
        

                

  

  



  





  



    


    
  


  

    
            
nem ez volt a kerdes. adott feladat, valassz nyelvet (tolem irhatod javascriptben is, bar kivancsi lennek, szerver oldalon demonkent mivel futtatod :-)), aztan megnezzuk ki a gyorsabb... Jerseyvel par perc az egesz + egy kis BL hogy RR legyen.



(okosabb LBhez mar kell trukkozni, dehat mindennek ara van.)



      

    
        

                

  

  




  



    


    
  


  

    
            
Ja, ezt? PHP-ban, apache2 rewrite rule-okkal ket sor a roundrobin load balance.



Ha cache-retegnek eleg az APC/memcached paros, akkor az, a REST-feluleteket osszeirin mondjuk  par perc, de ha biztosra megyek, akkor a zend frameworkben ott az egesz, es nekem igazabol egy db. osztalyt, az uzleti logikajat kell letrehozni, meg a roundrobinhoz beallitani azt a ket sort.



(na jo, meg beconfigolni, hogy lassa a memcached szerveremet)



Szumma, ha ezek mind telepitve vannak, olyan 2-3 perc szerverujrainditassal (ill. configolvastatassal, nem full restart) egyutt, a forditas JIT fog megtortenni az elso hivaskor (nincs compile time, nincs deploy time)



      

    
        

                

  

  




  



  



    


    
  


  

    
            
Ehhez meg annyit fuznek hozza hogy termeszetesen leteznek nem nyitott platformok is, amik szoba johetnek illetve leteznek. Iparaga es cege valogatja hol mit talalsz.



Az emlitett feladatok ezekben is meg vannak oldva, a java pedig szoba sem kerult a fejlesztesnel (ez termeszetesen jopar eve volt, ma nem tudom mi lenne a dontes, nem is szivesen talalgatnek, mert ma masok mar az uzleti celok is).



Nekem a roppant altalanos implementaciokkal (javaban es mashol is) egy gondom van: konkret feladatnal szinte biztosan lehet optimalisabbat kesziteni mint amit az altalanos nyujt, sokszor nem kicsit jobbat. A java eleve tobbet csinal mint egy nativ nyelv (ezert szeretheto is, ha eppen erre van szukseg), de termeszetesen ennek ara van. A hibaizolaciorol nem beszelve. Vagy a kiszamithatosagrol (meretezes).



Abban a szegmensben ahol fejlesztesi koltseg fontosabb mint a legjobbnak lenni, ott termeszetesen sok elonye van a javanak es a kornyezetenek, de nem biztos hogy mindig a legjobb valasztas ha ez a prioritasi sor mas.



      

    
        

                

  

  



  



    


    
  


  

    
            
Oke, ezt elmondhatod ma mar a rubyrol, a php-rol, a pythonrol, es lassan a javascriptrol is.



Na es akkor most hirtelen hasonlitsuk ossze az azonos problemak megoldasakent eloallo:

- LOC

- Ido

- Szukseges tanulas



fuggvenyeket... :)



(Java-PHP vegyesprojekt, ismert nagy cegnel... Ugy dontenek, X modul java stilusu lesz PHP-ben (tehat a nyelv adott, csak arrafele nehez php-st talalni (nem magyarorszag), oreg programozo ingatja a fejet: "ezt nem ertem... ketszerannyi ido volt, ketszer olyan hosszu, es ketszer olyan lassu")



      

    
        

                

  

  




  



    


    
  


  

    
            
php, python, uristen. hagyjal mar.



a ruby webre jo, de hogy mint szerveroldalon hasznaljam... hagyjuk. a javascriptet meg veletlen sem tekintenem normalis nyelvnek, hanyinger.



Javaban pikkpakk lehet fejleszteni, az idot nem ertem. a LOC az egy dolog, mostanaban egyre kevesebb a boilerplate, ami meg kell, szepen ki lehet altalaban factoralni (pull up+generify). tanulni.. mit nem kell tanulni manapsag? a phpt. ezert vagyunk egymillio php programozo orszaga...



es nem, _ruhellem_ a webet. nem erdekel, hogy phpban milyen gyorsan lehet webet fejleszteni. hatterrendszerek fejlesztesevel foglalkozom epp special (meg beagyazott rendszerekkel), de mondjuk egy ertelmes JMS alternativat sem lattam phpben, csak egy egyet emlitsek (JXTA pythonban?)



      

    
        

                

  

  




  



    


    
  


  

    
            
Oke, ebben a preziben egy gramm web nincs:



http://www.infoq.com/presentations/javascript-in-the-enterprise



(Komolyan, jo, rhino, sz'al van benne java)



A helyzet az, hogy manapsag mar a hatterrendszereket se javaban irjak. A rubyt meg marha ritkan hasznaljak kliensoldalon (kb egyaltalan nem, nincs is hozza GUI framework vagy alig), az ugyanaz, mint a J2EE, web meg ejb-container gyakorlatilag, tipikus szerveroldali nyelv.



Elosztott tranzakciok pythonban MQSeries felett; http://packages.python.org/pymqi/



(AMQP, STOMP, illetve mindenfele REST-es protokol meg mindenre van, ha MQ-t akarsz kezelni, igaz, utobbi sokszor gyartospecifikus)



(Eleg regota foglalkoznak ezzel, 2002-es levlistat talaltam, de nem derul ki szamomra, ez itt mikori.



IBM cikk: http://www.ibm.com/developerworks/websphere/library/techarticles/0708_s… )




      

    
        

                

  

  


  



    


    
  


  

    
            

es nem, _ruhellem_ a webet. nem erdekel, hogy phpban milyen gyorsan lehet webet fejleszteni





Erre egy picit: teny, vannak olyan dolgok, amiket PHP-ban nem irnek meg, az eltero eletciklus model miatt, bar speciel a webszolgaltatasok pont nem ezek, de van azert olyasmi.



De amikor webfejlesztesrol beszelunk, akkor ez manapsag - talan a bankok kivetelevel, meg nagyon nagy enterprise-ok kivetelevel - magaban foglalja a teljes hatterrendszert, a hatterjoboktol kezdve az MQ -ba adatokat szolgaltato node-okon at, egeszen a legalso adatretegekig.



Amit meg kene erteni, hogy ma a java egy opcio erre a sok kozul. Teny, hogy miota vannak annotaciok, kevesbe hanyinger az egesz (ha mar a kedvencemet lehanyingerezed :), de azert messze van egy dinamikus nyelv olvashatosagatol (a javascriptben egyetlen boilerplate letezik: a function kulcsszo. A funkcionalis nyelvek baromira tomorek, es nem kell kerulgetni bennuk semmit) vagy egy funkcionalis nyelv hatekonysagatol.



A PHP -t kell tanulni, evekig, ugyanugy be kell vesni a SOLID-ot, ugyanugy be kell vesni (vesni, nem tudni, vesni) az MVC-t, az osszes architekturalis mintat, az osszes trukkot, hogy hogy kell programozni, raadasul ki kell tudni kerulni az eletciklus-modellt, ha a szukseg ugy hozza, tudni kell skalazni, tudni kell egy csomo szoftver (a mysqld-n es a memcached-n keresztul a libpcre bugjain at az IE6 belso implementacios nuansznyi hibaiig bezarolag), ugyanugy kokemeny tervezesi folyamatokat kell vegigcsinalni, sot, gyakran le kell ulni, es javat kell programozni (vagy barmit, amihez epp kapcsolni kell a rendszert).



Egy webes architectnek nagyon sokmindent kell atlatnia, amihez kepest az MQ-alapu java backendek nagyon konnyunek tunnek, eppugy, mint a backendeseknek a webfejlesztes.



A kulonbozo cegeknel pedig nagyon sok nagyon gyenge tudasu java programozot lattam mar, es azt hiszem, meg lehet feleltetni a buta php programozot a buta java programozonak. Az egyiknek nincs mersze megtanulni a 'komoly' nyelveket es abban ganyol, a masiknak meg nincs fantaziaja kilepni az egyetemen tanult nyelvbol, pedig adott problemakat sokkal konnyebb lenne megvalositani, ha poliglot lenne, es magasabb absztrakciokban gondolkodna.



Szoval ez nagyon nem platformfuggo. Ez pusztan a rendszer komplexitasatol fugg, es az manapsag mar ott van a dinamikus nyelveken irt cuccoknal is. 



      

    
        

                

  

  



  



    


    
  


  

    
            
A cégek fizetnek azért, hogy jms-t fejlessz? Szerintem nem. A cégek a mindennapi, nem elvont, konkrét problémák megoldásáért fizetnek. Nekik web kell, az user tudjon klikkelni, vásárolni, kifizetni. A cégek vízióiban ezek a problémák szerepelnek, nem a J2EE meg a JMS.



Le tudsz programozni jávában egy jms-t? rossz kérdés. A helyes kérdés az, hogy le kell-e  programozni jávában vagy c++-ban a jms-t? Ha shell scriptben vagy php-ben programozol, egy csomó megoldandó feladat fel sem merül, amire jávában enterprájsz eszköz-hegyek vannak.  KISS: keep it stupid and simple. Nekem még mindig ágyúval (ágyúval??? atommal szőnyegbombázásnak) tűnik ez az egész jáva miskulancia.



      

    
        

                

  

  




  



    


    
  


  

    
            
Tegyuk hozza: altalaban nekem azert kell javahoz nyulnom, mert a cegek vizioiban J2EE szerepel, meg JMS. Az energiaim jelentos resze arra megy el, hogy elmagyarazzam, miert nem kell felhuzni az adott problemahoz JMS-t.



Elkepesztoen sok CTO (meg fejleszto) kepzeli azt, hogy az EE kifejezes konkretan jelent is valamit. A Sunnak egy elonye van a dinamikus nyelvekkel szemben, ez pedig az, hogy nagyobb a marketingosztalyuk koltsegvetese.



Iz it enterprajz redi?  (magamba: ju mean, meg lehet-e oldani az egyetemrol frissen a ceghez kerult, kizarolag az egyetem fo nyelvet ismero, olcso, tomegesen fellelheto vallalati programozokkal oldani a problemat, akik szinten nem kepesek minosegi kodot eloallitani, plane nem gyorsan, mert attol, hogy az api-k kenyelmetlenek, meg nem lesz benne jobb dolgozni, csakhogy sikitofraszt kapjon abban a 10 evben, amig a rendszer eletciklusa tart,mindenki, akinek kiadjatok, mert belulrol gany lesz, de ez nem fog megjavulni, mivel a rendszer a boilerplate-ektol eleve atlathatatlan, te meg el fogsz zarkozni attol, hogy atirjak alapjaitol valami atlathato nyelven?) je, sor.



      

    
        

                

  

  



  



    


    

      

  


      
( ssikiss
   | 2010. 01. 01., p – 22:43 )

      
            
      

        
        
        
      

      
    

  


  

    
            
Munkatársaim körében nem egy-két éve tudott dolog, hogy nem szeretem a Java-t, de ha valaki megkérdezné, hogy miért, most már nem nagyon tudnék rá mit (komoly indokot) mondani. Ha tud mutatni nekem valaki egy JEE szolgáltatási halmazt megvalósító (kiforrott, stabil) technológia kupacot más programozási nyelv alapon, akkor kicsit boldogabb lennék. Az már a gyönyör netovábbja lenne, ha esetleg egy tipikus feladat megoldási ideje is jobb tudna lenni, mint Java-ban.



      

    
        

                

  

  


  



    


    

      

  


      
( Finder
   | 2010. 01. 02., szo – 03:49 )

      
            
      

        
        
        
      

      
    

  


  

    
            
Én csak azt akarom mondani, hogy szeretem a Java-t. Lehet vele dolgozni klasszul, a hordozhatósága kiváló, nem lassú és majd' a teljes kód visszanyerhető ha elhagynám a forráskódot. :P



      

    
        

                

  

  


  



  



    


    

      

  


      
( gejzir
   | 2010. 01. 02., szo – 11:44 )

      
            
      

        
        
        
      

      
    

  


  

    
            
Én nagyon szeretem a java-t. Sok nagy projektet csináltam C++-ban, java-ban mostanában néha C#-ban.



Nem tudom, hogy aki panaszkodik az API-kra mit használ, de az eddig általam látott legjobban használható API-k a következők voltak:



-java. a legtöbb standard API jól átgondolt és kiforralt, a legtöbb open source framework szintén (ezeknél is felfedezhető tervezés és szabványosítás. sokszor egy os kezdeményezés lesz az alapja a "hvatalos" szabványnak). Persze van olyan ahol egy-egy API részt már meghaladott az idő, de ott is logikus a folytatás vagy az új verzió. Nekem már az első EJB is tetszett, bár kétség kívül bonyolult volt, de 2 nap könyv olvasás után érthető volt, hogy mit miért csinál. Az új EJB pedig egy tök jó komponens készlet és nem utolsósorban szabványos, gyártó és platform független framework, amit másról így hirtelen nem tudok elmondani.



-Borland Delphi/C++Builder (kár, hogy nagyjából befuccsolt)



-QT (ez kezdi megközelíteni, vagy néhol már már el is hagyta az egykori Borland API-kat



      

    
        

                

  

  




  



    


    
  


  

    
            
Fajl letoltese HTTP-rol:

- PHP-ban:



echo file_get_contents('http://php.net/'); // tudom, egyesek szerint insecure, valojaban config kerdese





- Pythonban





import urllib2

response = urllib2.urlopen('http://python.org/')

print response.read()





- Rubyban:



 require 'net/http'

 Net::HTTP.start( 'www.ruby-lang.org', 80 ) do |http|

     print( http.get( '/en/LICENSE.txt' ).body )

 end



Java: (nem masolom be, mert hosszu): http://www.devdaily.com/java/edu/pj/pj010011/



Ideznem azert az aljat:




Listing 1 (above): The JavaGetUrl.java program shows how easy it is to open an input stream to a URL, and then read the contents of the URL.





Nyilvan ez egy kiragadott pelda, de url-eket mondjuk sokkal tobbet szoktam megnyitni, mint vilagoknak koszonni,  es nyilvan a tipusossag rejlik a dolog mogott, de szoval ez:



new DataInputStream(new BufferedInputStream(is));





Bocs, de ez nekem boilerplate. Nekem nem streamek kellenek, en egy sztringet kerek. Ha ez nincs meg 20 karakterbol, az gaz.



Pontosan tudom, hogy mitol ilyen hosszu, hogy mit jelent az InputStream, de ezek olyan reszletek, amiket a felhasznalo - azaz a programozo - elol a legtobb nyelv elrejt. Nyilvan nem veletlen, hogy az ecmascript-alapu flash szinte nulla ido alatt soporte ki az appleteket a piacrol. Nem tud tobbet, csak elrejti.



      

    
        

                

  

  




  



    


    
  


  

    
            
jaja, de akkor már inkább assembly, 256 bytban directx nélkül 3d-s animációkat lehet..

remélem nem félreérted:)



de ha valakit zavar a java "beszédessége" (hajh van aki a akár az általad említett nyelvekbe is élvezettel ír hieroglifákat), egy-két saját könyvtárral le lehet rövidíteni, sőt ha már unod a gépelést ott a scala



      

    
        

                

  

  




  




  



    


    
  


  

    
            
Ahha... idéznék egy példakódot:




HttpClient client = new HttpClient();
HttpMethod method = new GetMethod("http://www.apache.org/");
int statusCode = client.executeMethod(method);
if (statusCode != HttpStatus.SC_OK)
{
  System.err.println("Method failed: " + method.getStatusLine());
}

byte[] responseBody = method.getResponseBody();
method.releaseConnection();
System.out.println(new String(responseBody));

Ugye a többi példa egészen addig triviális, amíg nem kell hibakódokat és esetleg timeout-ot kezelni, az újrapróbálkozásról nem is beszélve. Esetleg egy 2-4-8GBájt a letöltendő méret és akkor nem memóriába kellene tölteni, hanem stream-et kérni, ésatöbbi.



Az a baj a script-programozókkal, hogy egy ideális világban élnek, ahol nincs hiba, amit le kell kezelni... és a kis programjaik is egészen addig működnek jól, amíg nincs hiba, ha van, akkor pedig kideríthetetlen, hogy mi okozta és miért... :)

--

http://wiki.javaforum.hu/confluence-2.10/display/FREEBSD



      

    
        

                

  

  




  



    


    
  


  

    
            
Ennek a programnak az a lenyege, hogy URL-t olvasson be, egy adott cimrol.



"Az a baj a java programozokkal", hogy tulzott altanositasokban gondolkoznak, igy nem veszik eszre, hogy az url-ek tartalmanak merete itt jol predikalhato - valoszinutlen, hogy a php.net vagy a python.org fooldal gigakra nojon - valamint azt sem, hogy a hibauzenet kiirasa egyenlo lenne egy runtime exceptionnel, csak mashogy formazva (es mivel miatta nem latnad a stack trace-t, addig nem derulne ki, mi van, amig ki nem veszed a catch-phrase-t)



En alapvetoen azt gondolom, ketfele exception van: van a recoverable, meg a non-recoverable. A recoverable exceptionokre nyilvan fel kell keszulni rendesen, hisz a felhasznalonak meg kell adni az eselyt, hogy folytassa a munkat.



A non-recoverable exceptionoknel viszont ki kell rakni egy oldalt, hogy 'szolj a programozoknak', es el kell menteni a logokba a stack trace-t hogy mi tortent, es ennyi, mert ugyse tud vele mit kezdeni, es a muvelet vegrehajthatatlan. Ezt egyesevel lekezelni badarsag.



En is irok javat ha kell, csak nem szeretem; felre ne erts, nem script-stilusban irok se javat, se php-t, ezek jo resze lespecifikalt, megtervezett es terv alapjan megirt programok, es  fel vannak keszitve az ertemes hibahelyzetekre, biztonsagi beprobalkozasokra stb.



Nyilvan a scriptjeim nem ilyenek, hisz van valasztasi lehetosegem, hogy mit akarok lekezelni.



(Hany ures catch-t lattam java-programozok "tollabol"!)



Az elmult masfel evet java-php vegyes rendszerekkel toltottem. Termeszetesen ertek mindket nyelvhez, de fokozatosan ra kellett jonnom, hogy nem hatekonyak a java megoldasok, nem puszta teljesitmeny, de kodkarbantarthatosag, fejlesztesi koltseg szempontjabol, es nem azert, mert olcsok a szkriptkiddik (mindenki kivetel nelkul java programozoi statusban van a php-saink kozul), hanem mert egyszeruen keves a nyelvi ficsor, a libek meg tulaltalanositottak, nem kezelik jol a default eseteket,  mindent egyformanak neznek.



Ez persze aki evek ota ki se mozdult a java libekbol, annak nem tunik fel. Akkor szokott feltunni, amikor jon egy dinamikus nyelves hatteru architect vagy lead developer, a java programozok ra vannak szoritva a nyelvre, folyamatos code review van, es hoppa, minden gyorsabban kesz lesz meg rovidebb meg hasonlok.



NEM a script kiddie nezopontjabol itelem el a javat, hanem a tobbszazezer soros java-php vegyes rendszereket fejlesztve.



      

    
        

                

  

  




  



    


    
  


  

    
            
"Az a baj a java programozokkal", hogy tulzott altanositasokban gondolkoznak, igy nem veszik eszre, hogy az url-ek tartalmanak merete itt jol predikalhato - valoszinutlen, hogy a php.net vagy a python.org fooldal gigakra nojon - valamint azt sem, hogy a hibauzenet kiirasa egyenlo lenne egy runtime exceptionnel, csak mashogy formazva (es mivel miatta nem latnad a stack trace-t, addig nem derulne ki, mi van, amig ki nem veszed a catch-phrase-t)




Hogy is mondjam. Az általam említett program tudja három sorban azt, amit a három soros perl program. Ha nem kell arra figyelni, hogy esetleg nem 200-as választ kapunk a kért oldalhoz. Az tiszta sor, hogy a php.net vagy a python.org főoldala erős közelítéssel előre sejthető méretekkel bír, de úgy gondolom, hogy ha hasznosat szeretnénk csinálni, akkor van esély arra, hogy - ha nem is GBájt méretben, de több száz kBájt fog érkezni és ekkor nem mindegy, hogy memóriába olvassuk és onnan írjuk fájba, vagy stream módban olvasunk írunk, esetleg a kettőt kombinálva blokkokat olvasunk és kiírás közben feldolgozunk.



Az Exception említését nem értem, én egyszerűen csak a HTTP válaszkód kezelésre gondoltam, mint hibaág, hiszen előfordulhat, hogy a még oly stabil oldalak, mint az apache.org is hibát adnak vissza a kérésre. És akkor vagy megdöglik az egész program futása, vagy úgy csinál timeout után, hogy üzemszerűen nem jött válasz a kért oldalról. Persze ez is egy szemléletmód. :)



A példában azt kell észrevenned, hogy Java esetén se kell többet gépelned ahhoz, hogy HTTP protokollon át megkapd a szükséges tartalmat. Sajnálom, hogy ezt nem vetted észre (vagy nem akartad észrevenni).



Az elmult masfel evet java-php vegyes rendszerekkel toltottem. Termeszetesen ertek mindket nyelvhez, de fokozatosan ra kellett jonnom, hogy nem hatekonyak a java megoldasok, nem puszta teljesitmeny, de kodkarbantarthatosag, fejlesztesi koltseg szempontjabol, es nem azert, mert olcsok a szkriptkiddik (mindenki kivetel nelkul java programozoi statusban van a php-saink kozul), hanem mert egyszeruen keves a nyelvi ficsor, a libek meg tulaltalanositottak, nem kezelik jol a default eseteket, mindent egyformanak neznek.




Én az elmúlt 6-8 évben Java-php-perl és pár egyéb scriptnyelv (például PL/SQL) fejlesztésével töltöttem. Mindegyiknek megvan a maga helye. Úgy érzem, hogy Java esetén nem sikerült a nyelvben és a technológiákban meglátni az OOP lényegét és működését, különben nem írnád azt, hogy a Java nem hatékony, és nehezen karbantartható, illetve magasak a fejlesztési költségei... pont ezekben van az előnye. Valami, valahol elveszett nálatok - például az, hogy kb. 5-10e LOC alatt nem kezdünk Java programnak... kivéve, ha van már egy saját FW, amelyre építeni lehet a modult. 5-10e LOC felett pedig nem állunk neki scriptnyelvet használva.

--

http://wiki.javaforum.hu/confluence-2.10/display/FREEBSD



      

    
        

                

  

  




  



    


    
  


  

    
            
Van egy problémám, kellene rá egy program. Van egy haverom, vérprofi jávában. Odaadnám neki a problémát, 38.4 másodperc alatt tervezne egy 4000 objektumból álló objektumstruktúrát, amihez 6 programozó 3 hónapig csak a getter setter funkciókat írogatná. Amiket ugye valaminek utána végre is kell hajtania.



Ha meg nekiállsz netbeansben, akkor egy egyszerűbb jsp-ből lesz egy 5000 soros kód, amiből kb. 4700 gettersetter, objektum kreálás, meg a többi, még jó, hogy a kódgenerátor a nagyrészét megfaragja helyetted. De attól azt a kódot még valaminek le kell fordítani, futtatni, stb.



5000 loc-ot egyáltalán nem kunszt összehozni egy ilyen rendszerben, gyakorlatilag még nem csináltál semmit, de már 5000 sor fölé értél.



Ezek után jönnek a jáva programozók nagyágyúi, akik még orrot törölni sem tudnak egy xml meg valami hozzá tartozó objektumfa nélkül és így lesz egy olyan kódból, ami bash-ban 15 sor, jávában 800. Mivel a kód nagyra sikerült, nem elég hozzá egy gép, hanem rendes load balance-olt clusteren lehet csak futtatni, most, vasal, tereget, mindent csinál, csak éppen a te problémáddal csak minimálisan foglalkozik. Mivel clusteren fut, clustertűrő adatbázis kellene hozzá, ettől hirtelen odagyógyul két nulla a költségvetés végére. De ha már clustereztél, akkor legyen elosztott csilivili messaging is benne, meg akkor már húzz fel mellé egy ldap szervert, ahol konfigokat lehet tárolni, meg stb.



És mivel a kód nagy,rakj alá svn-t, de használj hozzá minimum antot vagy mavent, hogy lehessen buildelni. Releaseld néha a kódot, amihez jó kis maven plugin van, többnyire rendesen meg is csinálja a release-t az svn-ben, kivéve, amikor nem. Olyankor takarítás van kézzel. Na, ha megbuildelődött a csomag, akkor kezdheted nyomozni, hogy a glassfish aktuálisan használt verziója éppen mitől hasfájós, hogy lehet úgy deployolni, hogy az tényleg működjön is, stb. stb.



Az se baj, ha van kéznél közben legalább egy hudson vagy egy continuum, meg akkor már kell hozzá egy mantis is. Meg szerverek, szerverek, szerverek és szerverek.



Ja, meg szerverek.



Ehhez kell egy halom ember meg egy halom tudás. Aki minden alkalmazott cuccnak a dolgait ismeri és tud rá gyógymódot.



Ehhez képest ha nem jávázol, ismerned kell az aktuális php verzió hülyeségeit, pár biztonsági kérdést, az apacsot és kész. Elfut egy szerveren, ha be akarsz kérni egy adatbázis táblát, nem kell contextet meg statementet buzerálni, hanem bekéred egy tömbbe oszt bakfitty. Nincs folyamatos integráció, agyalás, hogy most éppen ki sz.rt bele a levelsbe, hanem kicsit döcögősebben, de minden elkészül és működik.



Erre az egészre egy jó kifejezést tudok: bloatedware.



Kétségtelen tény, jávában lassan mindenre van megoldás. De ebbe a mindenbe nagyon sok olyan dolog tartozik bele, ami jáva nélkül nem merül fel kérdésnek. Hudson, maven és társai.




      

    
        

                

  

  




  



    


    
  


  

    
            
igazad van, jobb a php, amíg valami kicsiről van szó vagy nem számít ha nem működik



bemennél-e egy olyan felhőkarcolóba mit "evolúciósan" építettek, tehát ahol egy kicsit megroggyant ott jobban alátámasztották, az építés idejének körülményeinél még talán meg is áll, esetleg még szél is fújt, egyenletesen

vagy egy olyanba ami.. meg lett mérnök által tervezve



      

    
        

                

  

  




  




  



    


    
  


  

    
            
multkor halozati guru voltal. mostmar a programozokat is oltod? ;-)

ha nemtetszik, ne hasznald. nem kenyszerit senki fegyverrel szerintem...



aki meg epit ra, es mukodik (nagy rendszerek), koszonik szepen jol vannak..



(lehet kis es gyors kodot irni par objektummal, ami aztan sok mindent csinal. hidd el. csak erteni kell hozza. sajnalom, ha nem talalkoztal meg javas gurukkal, csak junior koderekkel akik most este ki az egyetemrol...)



      

    
        

                

  

  




  



    


    
  


  

    
            
Én meg sajnálom, hogy úgy reagálsz hsz-re, hogy nem emlékszel rá, mit olvastál benne.



Szerk: persze nem lenne rossz, ha a konkrétumokra is reagálnál, a netbeans által generált 5000 soros kódra meg a többire. Ja, hogy kiderülne, az eredeti hozzászóló véleményében sok az igazság?



      

    
        

                

  

  




  



    


    
  


  

    
            
attol fugg mit akarsz csinalni. a setter/getterek boilerplateknek hihetoek (a legtobb kodban az is), de megvan a maguk haszna.



h kell-e cluster, es ha igen, hogy, meg ldap, meg MQ szerver, meg ilyenek, az a feladattol fugg. nem kell mindig agyuval verebre. en uzemeltetek ilyen architecturaju rendszereket (es fejlesztek is ra...), es nem latok sok gondod. OpenMQ + OpenDSt hasznalunk, a tobbi mar sajat libbol megy.. (clusterezes is, bar Shoallal eleg gyorsan ossze lehet kalapalni vmit, ha vkinek az kell).



de tenyleg, ha Te ezeket hatranykent eled meg, akkor maradj a phpnel :-) en szeretem, hogy mindenre van kulon "felelos", nincs osszehanyva az egesz, es tudom skalazni.



      

    
        

                

  

  




  





  





  




  





  



  



    


    
  


  

    
            
a postgres jdbc drivereiben pl. nincs implementálva a (és ezért a következő hibaüzenet jön dögivel): 6c0fe6d08;|RAR7115: Unable to set ClientInfo for connection

java.sql.SQLClientInfoException: Not implemented.

lásd még:

org.postgresql.util.PSQLException: Method org.postgresql.jdbc4.Jdbc4Connection.getClientInfo() is not yet implemented.



Erről a dologról én két éve tudok. Majd eldöntöd, hogy ezt a dolgot te hibának, fícsörnek, vagy minek nevezed.



Más.

Nem teljesen világos, más is panaszkodott már rá, hogy miért nem lehet a postgreses mezőknek null értéket adni. Ez például a serial tipusú mezők kezelését meglehetősen miskárolja.(optimális esetben ha appendelek egy új rekordot egy dataproviderhez, akkor null-nak definiálva a primary key mezőt, ha az serial, miért nem szedi fel a megfelelő értéket?)(utána meg jön a nem teljesen szakszerű jáva programozó (nem én), és kér a kontextből egy kapcsolatot, bekonnektál újra a postrgresbe és egy statetemnttel beletolja a rekordot a táblába. full fapad, ehhez felesleges rowset meg dataprovider)



Más:

miért fekszik le egy glassfish, ha a hozzá kapcsolt adatbázisban egy táblához hozzáadok két mezőt? .



      

    
        

                

  

  




  





  



    


    
  


  

    
            
Őszintén, attól használhatóbb lesz a rendszer, hogy tudom, ki a felelős érte? A jáva önmagában nagyjából semmit nem ér, erről szól itt a thread, ha nem teszed mellé azokat a dolgokat, amiket már kifejlesztettek hozzá (akár a glassfisht, akár a mavent, akár az összes többi hasonló cuccot nézed). A jáva, mint programnyelv, nulla, a jáva, mint alkalmazásfejlesztési környezet eszközrendszer ér valamit. És ebbe a környezetbe beletartozik a jdbc is, ugyanúgy, ahogy más, nem a jáva fejlesztők által összerakott cucc.



      

    
        

                

  

  




  





  



    


    
  


  

    
            
Konkrétan nem érdekel, hogy kinek a hibája. A teljes rendszer lett ettől használhatatlan.

És mivel ez nem hivatalos jáva hibabejelentő fórum, nem igaz az az állítás, hogy ott panaszkodok a postgres miatt, ahol csak a jáva miatt lehetne pabnaszkodni, hanem ez egy mindkettőtől független fórum, nem érzem hibának ezt.



Ha most a maven hülyeségeiről kezdenék panaszkodni, ami szintén a jáva eszközrendszer része, de nem core jáva cucc, akkor arról sem lehet itt szót váltani?



Szerk: ez pont olyan érvelés volt tőled, mint amit a windows fanok szoktak mondani, ha valami hardverhez nincs rendes driver.



      

    
        

                

  

  




  



    


    
  


  

    
            
"Konkrétan nem érdekel, hogy kinek a hibája. A teljes rendszer lett ettől használhatatlan."



Lehet pl. Oracle adatbázissal vagy IBM DB2-vel is dolgozni, nem kötelező a PostgreSQL-hez ragaszkodni. De tudok jobbat: a PostgreSQL nyílt forráskódú, nyugodtan kijavíthatod a hibát. Ha ennyire fontos ez a probléma, akkor megéri a fáradságot.



      

    
        

                

  

  



  



    


    
  


  

    
            
Az elsővel még csak MySQL-nél találkoztam, Postgresnél mi jdbc3 drivert használunk. De rákerestem, látom hogy létezik a bug 2006 óta. Mondjuk valós funkcióbeli problémát nem okoz, de kétségkívül idegesítő, mikor ilyeneket látsz a logban.



A második egyszerűen nem így van, pont úgy használjuk a postgrest ahogy leírodés nálunk működik. glassfish+postgres, serial mezők, új objektumnál null értékkel inicializálva. Definíció szerint így kell használni.



Harmadik: szerintem nem a glassfish fekszik le, hanem az alkalmazói program valami hiba miatt.



Egyébként nem fekszik le. Én olyat is szoktam csinálni teszt rendszeren, hogy nem állítom le a glassfisht, hanem droppolom a public schema-t majd importálom a lementett induló teszt adatbázist (vagy újra létrehozom kicsit módosított szerkezettel). Ha az adatmodelled változik és ez a java oldali alkalmazás modelljét is érinti, akkor nyilván azt is újra kell deployolni, de pont a JPA miatt ez általában nem nagy változtatás, csak a program 1 osztályát érinti. De ha az alkalmazás modelljét az nem érinti, akkor simán hozzáadhatsz egy új oszlopot a táblához gond nélkül, ezt is csináljuk napi szinten.



      

    
        

                

  

  




  



    


    
  


  

    
            
Nekem az valós funkciós bug, hogy van a server logban 200 mega ilyen bejegyzés, és közte elszórva pár másik, amit látnom kellene, de ezt töménytelen mennyiségű locsogás közül kell kikaparni.



Szívesen megnéznék egy egyszerű példát arra, hogy dataprovideren keresztül hogy inicializálod null értékkel a serial mezőt. JPA-t nem tervezek használni, úgyhogy anélkül érdekelne. Annál is inkább szívesen megnézném, mert ez a probléma már volt itt téma és akkor sem sikerült megtalálni a jó megoldást.



Az adatmodellem változik, de az alkalmazás eddig sem használta azokat a mezőket (mert nem voltak), ezután sem használja (mert nem deployoltam újabb verziót), akkor mitől száll el? Nem logikus.



      

    
        

                

  

  




  



    


    
  


  

    
            
Mifőként JPA-val használjuk, de az egyik projektben találtam egy adatbázisba logoló kódot ami standard JDBC volt. Kicsit átalakítottam (pár oszlopot kivettem) remélem nem rontottam el semmit. Az id meg sem jelenik az SQL-ben.



Remélem segít.




    public synchronized static void log(int log_level,
            String message,
            String user_id,
            String company_id) {
        PreparedStatement preparedStatement = getPreparedStatement();

        try {
            preparedStatement.setInt(1, log_level);

            preparedStatement.setString(2, message);

            if (user_id == null) {
                preparedStatement.setNull(3, Types.VARCHAR);
            } else {
                preparedStatement.setString(3, user_id);
            }

            preparedStatement.setTimestamp(4, 
                new java.sql.Timestamp(System.currentTimeMillis())
            );

            preparedStatement.execute();
        } catch (SQLException sQLException) {
            Logger.getLogger(DBLogger.class.getName()).log(Level.SEVERE, null, sQLException);
        }

    }

    static PreparedStatement getPreparedStatement() {

        if (staticCommonPreparedStatement == null) {
            try {
                staticCommonPreparedStatement = getConnection().prepareStatement(
                        "insert into log_table (" +
                        "log_level," +//1
                        "message," +//2
                        "user_id," +//3
                        "log_time" +//4
                        ") values(?,?,?,?)");
            } catch (SQLException ex) {
                Logger.getLogger(DBLogger.class.getName()).log(Level.SEVERE, null, ex);
            }
        }

        return staticCommonPreparedStatement;
    }

----------------------------------------------------
A tábla:


CREATE TABLE log_table
(
  id bigserial NOT NULL,
  log_level integer NOT NULL,
  message character varying(1024) NOT NULL,
  user_id character varying(500),
  log_time timestamp without time zone NOT NULL,
  CONSTRAINT log_table_pk PRIMARY KEY (id)
)




      

    
        

                

  

  




  




  



    


    
  


  

    
            
Nekem az valós funkciós bug, hogy van a server logban 200 mega ilyen bejegyzés, és közte elszórva pár másik, amit látnom kellene, de ezt töménytelen mennyiségű locsogás közül kell kikaparni.



Ok, ezzel egyetértek.

Olyan tekintetben nem tartom funkciós hibának, hogy az adatkezelést nem érinti. A glassfish valamiért állandóan hívogatja ezt a getClientInfo() függvényt, ebből adódik a folyamatos log.



      

    
        

                

  

  



  



    


    
  


  

    
            
Most viccelsz? Abban annyi konkrétum volt, mintha felolvasnék a Münchausenből :)

4000 objektum és 5000 soros kód. Objektumonként 1 sor néha 2? Mindezt gettersetterrel?



Milyen modell az, mit te megcsinálsz php-ban kevés sorból, de java modellhez 4000 objektum kell? Milyen haver az, aki 4000 objektumos modellt csinál és te nem csapsz a kezére. Mindezt feltételes módban és túlzásokkal("ha odaadnám", "38.4s alatt")? Ha pedig a modell megkívánja és te egy script fájlba belekódolod, akkor lelked rajta.



1. Ha idegesít a gettersetter használj public változókat :). Viszont egyik OO nyelvben sem ajánlják a member változók publikus közvetlen elérését, mindenhol csak függvényeken keresztül (sokszor még az adott osztályban is érdemesebb függvénnyel elérni). A property kezelés tényleg elegánsabb C#-ban, ha csak visszaadod nem kell függvény, de ha már logikát írsz, ott is gettersettereket írsz, max. máshogy hívod. Viszont egy gettersettertől nem lesz lassabb egy rendszer.



2. Mindazok az elemek, amiket leírtál (jóval több van) nem feltétlenül szükségesek egy rendszerhez, hanem lehetőségek. Viszont platformfüggetlen (windows, linux, sokféle unix) és gyártófüggetlen (IBM, Oracle, (most még SUN), Redhat (JBoss), Jonas, Apache és még sorolhatnám) lehetőségek. Ráadásul készen vannak és a dolog tényleg működik. Ha odafigyelsz nem kell újraírni, csak configurálni és csomagolni.



Tudom, hogy sokan úgy gondolják, hogy majd ők ha odakerülnek megírják az adatkezelési réteget, tranzakciós réteget (nem az adatbázisban), (distributed) session kezelést (nem az adatbázisban), multithreadinget, distributed cache-t, MVC-t, komponens réteget és a többit.



Még többen azt gondolják, hogy soha nem is lesz szükségük rájuk.



3. Viszont mindezeket (2.pont) nem kötelező használni. Nekiállhatsz bármit lightweight programozni és van hozzá egy kiforrott tiszta nyelved.

Nem kell alkalmazásszerver, írhatsz saját programot, akár szervízt, de ha kell van 15 . Nem kell O/R mapper (bár meglehetősen kényelmes, kontrollálható és gyors), használhatsz JDBC-t natív SQL-ekkel, olyan "táblázatos" eredményhalmazzal (resultsettel) amilyet akarsz. Teheted a logikát JSP-be (bár normális helyen letörik a kezed), különálló objektumokba vagy használhatsz MVC frameworköt, templating engine-t (és ekkor még tényleg csak a webpage-ekről beszéltünk).



Látod én nem fikázom felületes tudás alapján a PHP-t mert bár szívtam már vele és kellett kiváltanom, nem ismerem olyan mélyen.



      

    
        

                

  

  




  





  




  





  




  



    


    
  


  

    
            
Van egy problémám, kellene rá egy program. Van egy haverom, vérprofi jávában. Odaadnám neki a problémát, 38.4 másodperc alatt tervezne egy 4000 objektumból álló objektumstruktúrát, amihez 6 programozó 3 hónapig csak a getter setter funkciókat írogatná. Amiket ugye valaminek utána végre is kell hajtania.




Akkor a haverod nem vérprofi, hanem alkalmatlan.



ami bash-ban 15 sor, jávában 800




Vannak ilyen feladatok. De hogy a zöme ilyen lenne, azt nem hiszem, de tegyünk próbát. Mondj feladatot, és nézzük meg, hogy mennyi idő, hány sor Java-php-bash megvalósításban, illetve milyen a kódminőség (pár testcase üzemszerű működésre illetve hibás működésre), aztán persze megterheljük. Várom a specifikációt a 15 soros bash programra... :)



A többi fröcsögésed a fentihez hasonlóan egyértelmű túlzás és sarkítás, azzal nem foglalkozom, álljunk meg itt egyelőre.

--

http://wiki.javaforum.hu/confluence-2.10/display/FREEBSD



      

    
        

                

  

  




  





  



    


    
  


  

    
            
Hmm... mivel a hozzászólásod négyötöde nem arról szólt, hogy megnézed a NetBeans-ben a sorok számát, két eset lehetséges:

1, Vagy nem te írtad azt a hozzászólást, ami a neved alatt megjelent.

2, Vagy szándékosan terelsz.

--

http://wiki.javaforum.hu/confluence-2.10/display/FREEBSD



      

    
        

                

  

  




  



    


    
  


  

    
            
vagy rohadtul utálom, amikor valaki konkrétumokra érvelés helyett annyit válaszol, hogy fröcsögés.

azzal vitatkozz, amit írtam, ne a személyemmel. én sem rólad meg a többiekről mondok véleményt, hanem az állításaitokról, esetleg egy tőletek nagyjából független dologról.



      

    
        

                

  

  




  




  



    


    
  


  

    
            

Én az elmúlt 6-8 évben Java-php-perl és pár egyéb scriptnyelv (például PL/SQL) fejlesztésével töltöttem. Mindegyiknek megvan a maga helye. Úgy érzem, hogy Java esetén nem sikerült a nyelvben és a technológiákban meglátni az OOP lényegét és működését, különben nem írnád azt, hogy a Java nem hatékony, és nehezen karbantartható, illetve magasak a fejlesztési költségei... pont ezekben van az előnye. Valami, valahol elveszett nálatok - például az, hogy kb. 5-10e LOC alatt nem kezdünk Java programnak... kivéve, ha van már egy saját FW, amelyre építeni lehet a modult. 5-10e LOC felett pedig nem állunk neki scriptnyelvet használva.





Na, sz'al ezt azert nem. Nem ertem meg az OOP lenyeget, ez egy picit talan eros.



Beszelgessunk arrol, hogy a java hogy alkalmatlan egyes OOP feladatok ellatasara esetleg? Alljunk at Eiffelre? Vagy beszelgessunk arrol, hogy vannak tisztan OOP nyelvek, vannak a C-kompatibilis nyelvek, meg van a java, akinel senki nem erti, mi a francert van kulon Integer es int tipus, de legalabb 10 evbe kerult az autoboxing?



Nem megyek bele elvi fejtegetesekbe, mert tul sok szakirodalmat hoznek (cimszavakban: Meyer, Dahl-Dijsktra-Hoare, Boochs), es meg valaki azt hinne, egyetemista vagyok, pedig csak nem vagyok kontar.



Nezd: a vegrehajtando feladatokrol modellek vannak. Ezek a modellek nyilvan megkozelitesfuggoek (hisz ez a modell definicioja). A java kialakitasakor pl. szukseges volt egy OS/CPU-emulalos megkozelites (pl. a Thread fogalom, VM fogalom), illetve az IO-nak szuletett egy meglehetosen bizarr, bar OOP elvekkel jol alatamaszthato reprezentacioja (InputStream, es leszarmazottjai).



Amit en vitatok, az az, hogy ezek a modellek hatekonyak, hogy ezek a megkozelitesek a mai tudasunk szerint, 14 evvel a Java 1.0 megjelenese utan megalljak a helyuket, hogy ezek jol reprezentaljak-e az ipari gyakorlatban elofordulo feladatok tobbseget, hogy ezek azt fejezik-e ki, amit a programozo irni szeretne, vagy pedig mindenkeppen szukseges.



Az en valaszom az, hogy nem: a java modelljei kezdetlegesek, nehol tulzott absztrakcio van bennuk, nyelvi keszlete pedig szegenyes. Minden egyes pillanatban, amikor getter-settert kell generalnom (egyaltalan, amikor a Generate reszre er a kurzorom), vagy amikor boilerplate-rol beszelunk, azt gondolom,  hogy a java, mint nyelv, es a java standard library megkozelitese, API-stilusa elavult.



Teny, az annotaciokkal, automatikus iteratorokkal, autoboxinggal sokat javult a helyzet, az 1.5-os a java legjobb release-e volt.



Azt is gondolom, a java ecosystem manapsag nem erv, latva a ruby, python, php, perl ecosystemek mereteit. Minden meg van irva mindenre, a valasztas szabad. Ugy gondolom, ezek megfelelo fizikai architekturaval jol skalazhato rendszerek alapjat kepezhetik.



Azt is gondolom, hogy ezek mind multiplatform megoldasok, mind nyilt, mind tobbfele valtozatban letezik (Jython, IronRuby, Quercus), igy nem latom ervnek azt, hogy a java multiplatform, hisz mind az.



Azt is gondolom, hogy szukseg eseten a mai elosztott rendszerek ismereteink konnyen adnak atjarhatosagot poliglot (tobbnyelvu) rendszerekben, tehat ha valami nincs implementalva az adott nyelven, ettol meg lehet jol hasznalhato, pl. egy egyseges SOAP, REST vagy Hessian (a sor hosszan folytathato) busszal, de meg sokezer, az adott helyzethez jobban passzolo megoldas letezik.



Ezek miatt nem latom azt a specialis teruletet, ahol a java alkalmas lenne: nyilvan visszaszorult a mobilpiacrol (pedig en szeretem a "csokitelefonokat", megse fejlesztenek rajuk sokan), visszaszorult a web frontendpiacrol (mikor lattal utoljara appletet...), a Java EE, olvasva itt tobb, altalam elismert javas hozzaszolasait, eredeti koncepciojaban szinten megbukott, azt meg talan sok-sok ev tapasztalattal kijelenthetem, hogy javaban webre fejleszteni ertelmetlen.



Nem celom senkit leflame-elni. En egy egyszeru programozo vagyok, aki szerint sem a generate, sem a ctrl-c, ctrl-v gombkombinacionak semmi keresnivaloja nincs a programozasban, aki mai napig a problemadomainbol szeret indulni, es meggyozodese, hogy ezek barmely turing-teljes nyelvre lekepezhetoek, akar OOP-elvek figyelembevetelevel is.



(Utobbira pelda a C -s WinAPI, vagy a korai C++ - C crosscompilerek.)



Vannak ennel csunyabb elkepzeleseim is (pl. hogy a publikus getter-setter privat valtozoval nem interfeszfuggetlenites, hanem egbekialto okorseg), de ezek tul konkretak talan ide.



Azt hiszem (nem gondolom, hiszem), hogy a legtobb mai java programozo az egyetemen ismerte meg ezt a nyelvet, ott kello melysegben elsajatitotta (mert jotanulo volt / elektronikabol megbukott esetleg, de az infos "szaktargyak" presztizsek voltak). Nem gondolom, hogy a java mint oktatonyelv feltetlenul idejetmult lenne, de osszefuggest veltem anno felfedezni a delphi-programozok tomegei es a kotelezo jellegu pascal oktatas kozott is.



A bajom ezzel a gondolatmenettel, hogy hibas: megakad egy adott absztrakcios szinten. Mindaz, amit a javarol tudunk, joreszt alkalmazhato C-ben is, sot, egy csomo mas nyelven. Megcsak az OOP feature-oknek sem kell meglenniuk.



Es itt ternek vissza az eredeti mondatodra,hogy nem ertem az OOP lenyeget. En azt gondolom, hogy pont, hogy jobban ertem, mint a java programozok egy jelentos resze, es emiatt merek kilepni a java keretei - mit keretei: korlatai! - kozul.



      

    
        

                

  

  



  



    


    
  


  

    
            
Hasonlót akartam írni azzal a kiegészítéssel, hogy ha pont ez a funkció kell 1 sorosan sokszor, akkor simán írsz rá egy függvényt és egyből megvan. Aztán még hibát is tudsz kezelni, bufferelni tudsz, cachelni tudsz, vagy amit akarsz.





  String content = UrlDownloadHelper.readFromUrl("http://java.sun.com");







Vagy ha a php-s echo-val hasonlítunk össze (körtét almával), akkor hasonlítsunk mondjuk a JSP-vel, ahol ugye van jsp:include page="relativeURL" vagy taglibből io:http url="http://www.yahoo.com"





De erre én azt mondom, hogy nyiss php-ban windows ablakot akárhány sorban :)



Láma kérdésem: hogyan tudtál kódot tabulátorokkal beilleszteni? nekem nem megy a "code" hintekkel sehogy sem.



      

    
        

                

  

  



  



    


    
  


  

    
            
Ez azért marhaság, mert KÖNYVTÁRAKAT minden nyelvben lehet írni. Megoldható, hogy egy sor legyen, és valahol máshol kódolod le a tényleges URL lekérést, hibakezeléssel, streamekkel, mindennel együtt. A scriptnyelvek... azok scriptnyelvek. Hosszabb távon egy komoly nyelvnél a döntő kérdés, mennyire lehet benne jó könyvtárakat építeni, semmi más. Mint ahogy NagyZ is írta, mindenre van megoldás már Java-ban (ezzel, meg úgy általában az érvelésével nem értek egyet, de itt nagyon igaza van), azért használnak egy X nyelvet, mert X-ben könnyű valamit megoldani. Vagy, mert beletoltak a nyelvbe minden bonyolult dolgot (ami barbár dolog lenne egy nem-scriptnyelvnél), vagy mert 10 éve használják és mindent megírtak már benne, legfeljebb burkolni kell néhány osztállyal, függvénnyel.



Tehát amit írsz az nem jelent nagyjából semmit.

----

Hülye pelikán



      

    
        

                

  

  



  



    


    

      

  


      
( dash
   | 2010. 01. 02., szo – 16:03 )

      
            
      

        
        
        
      

      
    

  


  

    
            
subscribe



---

Ami a windowsban szarrágás, az linuxban hegesztés.

Ha megszeretted a windowst, tanuld meg használni!

A linux igenis felhasználó-, és NEM idiótabarát.

A linuxot mi irányítjuk, a windows minket irányít.



      

    
        

                

  

  




  




  



    


    

      

  


      
( kisg
      v
   | 2010. 01. 03., v – 11:35 )

      
            
      

        
        
        
      

      
    

  


  

    
            
Sziasztok!



Mi fejlesztünk Javaban mobileszközöktől kezdve (J2ME, BlackBerry, Android) webes alkalmazásokig (Wicket, JPA, Jetty, Glassfish, GWT ... stb.)



Ugyanakkor fejlesztünk PHP-ban (Drupal, vTiger, Zend Framework, Doctrine ... stb.)



Sőt, van olyan projektünk, ahol C# és Python van két különböző platformon.



És végül itt van az IPhone Objective-C-vel.



Én, ha meg kell itélnem egy platform (nyelv + API-k + futtatókörnyezet) használhatóságát, akkor a következő szempontokat szoktam figyelembe venni:

1. Fejlesztőeszközök minősége

- Legyen rendes IDE hozzá (code completion, Debug támogatás)

- Legyen teszt keretrendszer hozzá (Unit teszt, funkcionális teszt)

- Legyenek nyelvi elemző eszközök (hibás minták kereséséhez, metrikák gyártásához, dokumentáláshoz...stb.)

- Legyen hozzá rendes build rendszer (igen, PHP-nál is van build, csak legfeljebb rövidebb / egyszerűbb mint más nyelveknél)

- Legyen hozzá rendes build szerver: Itt a Hudson szerencsére univerzálisan bevethető



A fent felsorolt platformok mindegyike megüti az elfogadható szintet, bár mindegyiknél vannak kényelmetlenségek.



2. Ecosystem

- Legyen megfelelően nagy felhasználói bázis

- Legyenek jó minőségű előregyártott komponensek

- Legyen hozzá megfelelő minőségű emberanyag a munkaerőpiacon



A felhasználói bázis és jó minőségű komponensek mindegyik platformhoz adottak. A munkaerőnél a PHP, Java és a C# előnye viszont látszik az ObjC-vel és a Pythonnal szemben. Viszont egy jó képességű szoftverfejlesztőnek 1-2 héten belül produktívvá kellene válnia bármilyen nyelven. Nem kell az adott platform szakértőjének lenni ahhoz, hogy képes legyen egy jól felépített és dokumentált projektbe bekapcsolódni.



Egy új projektnél a platform kiválasztását nálunk a következő befolyásolja:

- a rendszerrel szemben támasztott követelmények

- az ügyfél preferenciái

- a platformok lehetőségei

- a fejlesztőcsapat kompetenciái (ha van olyan platform, ahol már otthonosan mozognak, és ez nem ellentétes a követelményekkel, akkor érdemes azt választani)



Ami nem befolyásolja a választást:

- Hány sorban/hány perc alatt lehet X teljesen értelmetlen feladatot megoldani



Csak a fejlesztőkörnyezet normális összeállítása és dokumentálása 1-2 napot igénybe vehet egy nem triviális projektnél. Igen, PHP projektnél is. Nem beszélve bonyolultabb HA vagy load-balance teszt- és deployment környezetekről, amelyeknek az összerakása hetekig is eltarthat.



- Hány perc alatt lehet Hello World alkalmazásokat írni



A projekt méretétől, bonyolultságától függően napokba illetve hetekbe telhet, mire összeáll a rendszer architektúrája, milyen konvenciók szerint, milyen 3rd party komponensekre fog épülni (mindegyik platformnál van kismillió, ezeket össze kell hasonlítani, elemezni, vagy csak egyszerűen dokumentálni a döntést, meghatározni az adott komponens felhasználási szabályait...stb.)



Végül:

A fent felsorolt platformok mindegyikén fel tudok sorolni több olyan dolgot is, amik kényelmetlenséget, gondokat okoztak a múltban számunkra. De mindegyiknél fel tudok sorolni olyan dolgokat is, amik nagyon jól el vannak találva, és egy másik platformnál pedig hiányoznak. Ezért nekem mindegyik fenti platform tetszik (és még írhatnám hozzá a C és C++-t is), de különböző okok miatt.



Fontosnak tartom, hogy egy szoftverfejlesztő lehetőleg érzelmek nélkül tudjon viszonyulni a munkájának eszközeihez. Amatőr hozzáállásnak tartom azt, amikor érzelmi alapon döntenek egy adott platform mellett vagy ellen.



Üdv,

Gergely




      

    
        

                

  

  




  





  





  




  




  



    


    

      

  


      
( atomheart
      v
   | 2010. 01. 03., v – 13:38 )

      
            
      

        
        
        
      

      
    

  


  

    
            
Jo volt felhozni ezt a regi topicot, az emberek ujult erovel kapcsolodhatnak be a flame-elesbe... :^DD



----------------------

"ONE OF THESE DAYS I'M GOING TO CUT YOU INTO LITTLE PIECES!!!$E$%#$#%^*^"