Ismer valaki jól működő(!) java programot?

Flame

A cím magáért beszél. Közületek, akik üzemeltettek olyan appliance-okat, amihez java-s guit adnak, tud valaki olyant mondani, ami nem egy rakás sz@r? Most számoltam össze, hány ilyen gui-t használok nap mint nap, és mindnek NAGYON DURVA hibái vannak, ami mind arra vezethető vissza, hogy nem lettek rendesen megtervezve.

Mondjatok ellenpéldát (olyan java-s programot, ami komplex (nem hello world szintű), de ennek ellenére gyors, kényelmes, és minden funkciója jól működik).

Miért van az, hogy azt hiszik, ha valaki(k) nagyon magas nyelven progmoz(nak), akkor már nem is kell megtervezni azt a programot?!?

Szerk: napi üzemeltetés során mennyi python, perl vagy php hibaüzenettel találkoztok, és mennyi java-ssal?

Szerk2: mivel egyre több vérben forgó szemű Pistike irogat, ezért felhívnám a figyelmet arra, hogy a topik _APPLIANCE_-okról szól, ahol _NEM NYÚLHATSZ_ a jvm konfigokhoz.

  • 6343 megtekintés

( pgabor v | 2010. 06. 01., k – 16:27 )

"Miért van az, hogy azt hiszik, ha valaki(k) nagyon magas nyelven progmoz(nak), akkor már nem is kell megtervezni azt a programot?!?"

mert elolvasnak 3-4 howto-t a neten és már is programozóknak hiszik magukat. lehet működik valamennyire, de mindig is látszódni fog az alapok nem ismerete.

mert az igazán képzetlenek be sem kapcsolják ezekben a nyelvekben a warningokat.

perl-ben pl. alapból a nem létező változóra hivatkozás (elgépelted a változó nevét) nem jelez vissza, szimplán üres értéket fog használni a program. aztán csodálkozol, hogy miért csinál hülyeséget a programod... aki bekapcsolja a -w meg a use strict opciókat, az vagy kiba korrektül dolgozik, vagy állandóan fosni fogja a perl a warningokat...

php ugyanez pepitában: pl. a tömb nem létező elemére hivatkozás elég gyakori kezdő (és nem annyira kezdő) programozóktól, közben az apache logtól meg megtelik a diszk... a rendszergazda (mert ugye ő szembesül a trágyarakással) meg inkább átállítja a logolást, hogy minden menjen a php-ből a /dev/null-ba.

Elsősorban azért, mert az önképzett "programozók" között sokkal többen írnak Java-ban programot, mint Pythonban.
A Java helyett persze lehetett volna Delphi-t, Visual Basic-et is írni.

Elég ha szétnézel pár programozással foglalkozó fórumon és látszik, hogy senki sem programozni, hanem programozási nyelvet akar megtanulni. A többségnek lövése nincs még a folyamatábráról vagy az állapotgépről sem, nemhogy ennél komplexebb programtervezésről.

( kisfarkas | 2010. 06. 01., k – 16:30 )

Csak, hogy párat említsek: eclipse, squirrel, tomcat. Tény, hogy ezek egyike sem "olyan appliance-okat, amihez java-s guit adnak", de szerintem ellenpéldának tökéletesek.

Az eclipse-t és a tomcat-et inkább hagyjuk (se nem gyorsak, se nem kényelmesek, se nem jól funkcionálók. Gondolj bele, hányszor de hányszor találkozik az ember minden nap tomcat hibaüzenetekkel). A squirrel-t nem ismerem.

Itt most üzemeltői szemszögből szólt a kérdés, ezért az eclipse-t duplán is hanyagoljuk.

squirrel egy sql kliens.

"Gondolj bele, hányszor de hányszor találkozik az ember minden nap tomcat hibaüzenetekkel"

Amiket a tomcat generál (elég kevéssel), mert szar, vagy azok amiket a szarul megírt webalkalmazások okoznak? Van különbség.

Sebességről nem tudom nyilatkozni, de ezek mind a leggyorsabbak voltak, amikkel ebben a témában összefutottam. Funkciójukat ellátták, és kényelmesek szerintem.

PS: Java fejlesztő vagyok, és büszke ;) Zúdítsd rám a dühöd.

"Amiket a tomcat generál (elég kevéssel), mert szar, vagy azok amiket a szarul megírt webalkalmazások okoznak? Van különbség."

Ismétlem, üzmeltetői szemszögből. Nekem tök mindegy, melyik a gáz, azt tapasztalom, hogy rengeteg a hiba a java-s programokban, és ezt nem sikerült megcáfolnod. Az én szempontomból nincs különbség a tomcat és az alatta futó alkalmazások között, a végeredmény működésképtelen honlap, tomcat üzenettel.

Az egész enterprise fejlesztői szakma el van cseszve. Legtöbb multi alulképzett, programozónak hazudott emberekkel dolgoztat, vagy rosszabb esetben ezeknek outsourceolják a munkát. Költséghatékonyság.

Ha elcseszek egy php szkriptet, és elhal az oldal render, akkor az apache, vagy a php mod a hibás?

"Az egész enterprise fejlesztői szakma el van cseszve. Legtöbb multi alulképzett, programozónak hazudott emberekkel dolgoztat, vagy rosszabb esetben ezeknek outsourceolják a munkát. Költséghatékonyság."

ezen nincs mit csodálkozni. Elmész egy java programozói interjúra, és tesztírás címen lényegében a java könyvekben leírtakat kérik számon, és annak eredménye lesz az, ami alapján téged oda felvesznek. Desktop alkalmazások fejlesztésénél előfordulhat, hogy alap programozási ismeretek + a java nyelv magasszintű elméleti ismerete elegendő egy jól működő alkalmazás kifejlesztéséhez. Enterprise szintű fejlesztéshez ennél jóval több kell - és sajnos számtalan cégnél látom, hogy ez a tudás félig van csak meg (pont annyira, hogy ha szállítani kell, akkor azt némi jóindulattal elfogadják, persze megesik, hogy nem...)

Gyere el mar hozzank egyet interjura legyszi.

Javabol, mert PHP-bol kenytelen lennek osszeferhetetlensegre hivatkozni.

Nyelvi kerdeseink is vannak, de ezek is olyanok, hogy az eletbe nem talalod meg oket a google-lel ha nem tudod elore.

Mas problemak viszont total nyelvfuggetlenek, es valtozatos, hogy melyiket tesszuk fel, abban biztos lehetsz, ha felvettunk, tudsz valamit.

Mondjuk ennek ellenere se fogom szeretni a java-t, de en nem is azert vagyok ott, hogy azt szeressem, vannak erre tobbszazan.

Igen, mert üzemeltetői szemszögből mindegy, hogy a framwork api-ja a bugos, vagy a program, ami hívja az api-t. Ezt nem fogod megérteni, amíg csak programozó vagy, és nem üzemeltettél.

(Próbáld meg úgy megközelíteni a dolgot, hogy egy atombiztos framework alá nem lehet - legalábbis nagyon nehéz - "hibás/rosszul megtervezett" programokat írni úgy, hogy azok átmenjenek a teszteken, és csak éles üzemben jöjjenek elő a hibái).

Én már elég sokféle üzemeltetői csapatot láttam, de eddig csak a low-end indiai üzemeltetők kezelték úgy a helyzetet, hogy nem tudták megmondani, hogy mi az ami infrastruktúra és mi az ami alkalmazás-probléma. ("Doesn't work, please suggest"). No offense meant.

Ha pedig üzemeltetőként nem látsz bármikor legalább 10 okot arra, ami miatt egy "atombiztos", ezerszer letesztelt program ne romolhatna el élesben, akkor még nagyon kevés hibával találkoztál...

szerk: amúgy van egy olyan érzésem, hogy érzed te ezt a különbséget, csak most durcásan csakazértis szidod a java-t, mert ha már egyszer megszivatott, vissza akarod adni a törlesztést...

A nyelvvel nincs semmi gond, egyszerűen szarok a szoftverek. Az, hogy sok memóriát eszik az alkalmazás, lassú, akármi, az a nem megfelelően megírt szoftver miatt van.

Mivel a mai világban minden nagy cég olcsósít, és a minőség másodlagos (igen, a több 10 millióba kerülő cuccoknál is!

A tervezésen is lehet spórolni (architekt minek), a fejlesztésen is lehet (indiai jómunkásember), meg a tesztelésen is. (majd a felhasználó rinyál, aztán javítjuk, ha úgy gondoljuk)

A Java nyelvet pont ezért szeretik használni, mert viszonylag jól tolerálja a fejlesztők hülyeségeit (dob exception-t, aztán jobb esetben megy tovább), míg egy lefordított program ilyenkor elhasal (core dump).

Azért gondolj bele, üzletileg mekkora ötlet kihagyni a tesztelési szakaszt. Ha van tesztelés, akkor

  1. fizetni kell tesztelőket;
  2. ha találnak hibát, ki kell javítani, ami szintén csak viszi a pénzt;
  3. a tesztelés időt vesz igénybe, így később lehet szállítani.

Ha viszont nincs tesztelés, akkor

  1. a tesztelők fizetnek neked (ők a felhasználók);
  2. ha találnak hibát, akkor külön fizetnek azért is hogy kijavítsd (vagy az egyes javításokért, vagy vesznek supportot);
  3. a szoftvert sokkal hamarabb ki lehet adni.

Persze mondhatnád, hogy akkor a felhasználók elpártolnak a programtól a konkurenciához, de ez gyakran kivitelezhetetlen, hiszen

  • nagyobb cégeknél a program használói nem azonosak a beszerzést végzőkkel, a beszerzők pedig azt nézik, hogy melyik termék olcsóbb, és melyik jön ki időre;
  • ha már a döntés megszületett és vettek iszonyatos összegekért license-eket meg supportot, és bevezették a programodat, akkor akármilyen fostalicska is legyen, nem lehet máról holnapra lecserélni, a mamut effektus viszi őket tovább;
  • ha váltani akarnak, kétfajta céget választhatnak: amelyik pont olyan, mint a tiéd, vagy amelyik lelkiismeretes munkát végez - csak éppen a QA pluszköltsége miatt kétszer annyiba kerül, és a határidőkkel is csúszik néha a javítások miatt.

Ha mégis elkezd hullani a barna eső, egyszerűen szélnek ereszted a céget, áttelepülsz India egy másik tartományába, alapítsz egy másik céget, és ennyi. Az európai / amerikai partnerek úgysem fognak utolérni Távol-Keleten, Délkelet-Ázsiában vagy hasonló kellemes éghajlatú vidékeken. Leírják a veszteséget, és megveszik a következő adag hulladékot - amit talán éppen te szállítasz majd.

(Én meg tanulom a formális helyesség-bizonyítást. Mekkora vicc.)

Szerk.: lemaradt egy pontosvessző.

én ebben nem találok ilyent. először *.java-ban kerestem 0xd-re, majd 0x0d-re, aztán már nem csak *.java-ban, nem sok eredménnyel. exit-re és code-ra rákeresve már több találat van, de ezeket most nem fogom átnyálazni. azt hittem van hozzá valami doksi, ami leírja, hogy melyik exit code mit jelent.

a felvetésem alapvetően beugratós volt...

azt ugye csak viccnek szántad, hogy a 13-as számot 0xd-ként keresed...?

mellesleg, jó volna kideríteni, hogy a szám, amit egyáltalán keresgélsz, alapvetően honnan jön. lehet pl. egy exit code, de lehet egy signal száma is, akkor ugye máshol keresgélünk...

Ami a tomcat-et illeti: amikor rá fejlesztettem programot (életemben az elsőt), a munkatársaim szóltak, hogy túl rondán beszélek és vegyek vissza.

Bevallom őszintén 10 éve vagyok programozó, de nem azzal kezdtem, hogy az 1000 oldal doksit elolvassam. Nincs idő tetvészkedni: megírod, ha pedig nem megy javítod.

A tomcat kellően bonyolult ahhoz, hogy tapasztalt informatikusok is elcsesszenek dolgokat, ha még járatlanok benne.

Egy hetem ment el a GWT Comet belövésével.

A comet kommunikáció a szervertől a kliens felé. Úgy működik, hogy másodpercenként elküld egy bájtot, hogy életben tartsa a TCP kapcsolatot, ha pedig üzenet jön, akkor azonnal átküldi.

A probléma ott jött be, hogy az Apache bufferinget használ és hiába küldözgeted te másodpercenként a bájtokat, az Apache megvárja míg a 32k összegyűlik, így cseszheted az egészet.

Szóval kezdő Tomcat fejlesztőként a se kép, se hang, hivatalosan mindennek működnie kellene, az interneten semmi róla, azért elég fájdalmas volt. Egy szimpla beállítással természetesen gyógyítani lehetett, de amíg megtaláltam 1 hét volt.

A tapasztalatom az, hogy a Tomcat fejlesztési idő elég jelentős része a konfigok buzerálásával megy el, így nem elég megbecsülnöd, hogy ennyi idő a programot megírása, hanem "tomcat suck"-ra is időszeletet kell fordítanod.

megírod, ha pedig nem megy javítod.

Szerintem itt lesz a gond. Nem tudsz eléggé programozni ahhoz (többek között, mert nem olvastad el az 1000 oldalas doksit, meg mert nem tartozol a zsenik közé), hogy fejből, tesztek nélkül jól írd meg elsőre. Ez még nem volna baj, ez sokaknak nem megy még akkor sem, ha elolvassák a doksit.

Viszont azt gondolod, hogy
- majd szól a compiler, ha valamit nagyon elcsesztél,
- majd elindítjuk, nézegetjük, és meglátod, ha nem megy.

Aztán hogy-hogy nem, nem látod meg. Mert nem tesztelsz elég jól. És azért van sok gyatra program, mert sokan nem tesztelnek elég jól (és nem is zsenik, hogy elsőre jól írjanak meg mindent).

1) nincs különösebb baj a Tomcat-el, lassúnak se mondható (persze ez viszonylagos)
2) a sok hibaüzenet nem jelenti azt feltétlenül, hogy szar a program, csak azt biztosan,
hogy nincsenek lekezelve rendesen a hibák
3) üzemeltetői szempontból sem lényegtelen mi dobja a hibát.. egy apache/tomcat kiszolgáló, vagy
az alatta futó program, úgy hogy ez a kiindulási alap rossz

( ratdragon | 2010. 06. 01., k – 16:49 )

Megmondom én, hogy mi a baj ezekkel a GUI-nak nevezett javas szottyadványokkal:
az, hogy _ROSSZAK_! :D

( verkri | 2010. 06. 02., sze – 21:11 )

Ne haragudj, de szerintem elég bugyuta kérdést tettél fel. Ilyen alapon bármelyik nyelven írt GUI-s programmal lehetne előhozakodni, mert mint tudjuk, hibátlan program nincs.

1, gyorsaság : relatív, ki mit tekint gyorsnak, milyen környezetben, stb. Nem hiszem, hogy csak a Java lassú, más példát is lehet bátran hozni, gondolkodni sem kell. Matlab is indulhatna gyorsabban, mondjuk 0.5 sec alatt, mert miért ne, de mégsem lehet mondani, hogy lassú.

2, kényelmesség : kinek mi kényelmes ugye. Eclipse-ben még mindig nem jöttem rá, hogy ha meglévő build.xml-ből csinálok új projektet, akkor az most hol lesz, mit hova rak, a változtatások hol lesznek átvezetve. Gány. NEKEM ultramegakényelmetlenmegszokhatatlanszar.

3, minden funkciója JÓL működik : define JÓL. Thunderbird pár funkciója sem úgy működik, ahogy én szeretném, mégsem lehet mondani hogy rossz "szottyadvány". Vagy lehet. Kinek mi a jó, ugye.

Na szóval szerintem joggal került a Flame-be. :)

"Eclipse-ben még mindig nem jöttem rá, hogy ha meglévő build.xml-ből csinálok új projektet, akkor az most hol lesz, mit hova rak, a változtatások hol lesznek átvezetve. Gány. NEKEM ultramegakényelmetlenmegszokhatatlanszar."

Gondoltál már rá, hogy csak te nem értesz hozzá?

Igen, én nem értek hozzá, sosem állítottam az ellenkezőjét. Ámbár nem gondolom magam hülye embernek, és mivel más, hasonló kaliberű alkalmazásnál pofonegyszerű, egyértelmű, logikus ugyanez a funkció, bátorkodtam megjegyezni, hogy "NEKEM ultramegakényelmetlenmegszokhatatlanszar."

A workspace nem munkakonyvtar abban az ertelemben, hogy forraskodgyujtemeny, hanem projektek gyujtemenye, a projektek beallitasaival stb. Egy projekt pedig kezelheti a forrasfajlokat linkelt helyen levo mappakbol is (amikor importalsz peldaul mas projektet, akkor meg is kerdezi, hogy bemasolja-e a forrasfajlokat, vagy csak linkelje a workspacehez).

Lehet, hogy firefox is javában készült :)

Na jó, ne vicceljünk, a helyzet ennél tragikusabb.
A youtube+flash combo a jelenlegi formában egy szar. Nem ehet(ne) meg 10-15 tab 300-400MB-ot, főleg úgy, hogy (mivel nem vagy pók) csak egyet nézel, a többi max. kúszik lefelé.

Az meg egy hibás felfogás, hogy a RAM az van, mint a tenger.
Igen, általában nem szokott ebbe beleütközni a tisztelt felhasználó ill. olcsóbb sokszor RAM irányba bővíteni, mint reszelni a kódon vagy neadjisten átírni más nyelvre (amitől még gyorsabb sem lesz feltétlenül).

A végtelen hardver illuzióját első körben az energia árának emelkedése kezdte/kezdi szétverni. Már nem is olyan végtelen az a memória, ha össze kell költöztetni 2-3 vagy még több algépet egy fizikai vasra. Akárkivel beszélek szerverhosting fronton, mindenki a "kihoztam az 53 PC-met, bevittem helyette 3 izmosat" történetekről számolt be.

Ha az energia ára tovább emelkedik, akkor minden drágulni fog: az alkatrész és a hosting is. Közben fejlődik a technológia persze, meg a szoftverek is többet esznek, ez kb. kiüti egymást. Én nem látom azt a hatalmas felhasználói élmény változást, amit mondjuk a iDX2-66 + 8MB RAM óta elszenvedtünk. A RAM az ezerszerese, a CPU is kb. 100x, aztán elmegy compizre meg 5 youtube tabra az egész plusz.

talalkoztam nem egy olyan kis- es kozepvallalkozassal, ahol a legnagyobb teljesitmenyu szamitogep 512MB DDR1 rammal rendelkezik. Elhsiheted, hogy nem az en gepemnek a sok. (Bar en is 1,5GB rammal vagyok el mar miota)
-----------
Happy, satisfied and completely up-to-date Archlinux user since 2009 september (KDE)
"Which version do you use?" "The latest stable" (a random archlinux user)

Egyszer kicsit belenéztem, hogy hogyan működik:

Az ABEV egy általános nyomtatványkitöltő (szeretne lenni). Ezzel nincs is semmi baj, tök jó lenne, ha minden nyomtatványt amivel kommunikálsz az állammal / önkormányzattal 1 db eszközzel lehetne kezelni.

A gondok a következők:
1. Rossz a modell absztrakciós szintje. Olyan dolgok vannak benne, hogy:
- írj ide ki (456,123-as pixelre) egy keretet
- írj ide ki (456,123-as pixelre) egy labelt, ami azt mondja "Ni"
- írj ide ki (456,123-as pixelre) egy beviteli mezőt, aminek a neve "abcd1234" és a "blabla123"-as szabályok vonatkoznak rá
Emiatt gyakorlatilag az űrlapok csak ezzel a programmal dolgozhatók fel. Alternatív kitöltőprogramok készítésénél az összes űrlapot újra le kell gyártanod kézzel, mert nem tudsz labelt társítani a mezőkhöz.

2. A felület tervezésénél a legfontosabb követelmény volt, hogy _pontosan_ úgy jelenjen meg az űrlap, mint nyomtatásban.
Gondolom van kiváló drag & drop-os eszközük is, amivel a "nyomtatványkészítő" munkakörben dolgozók gyártják az ABEV-es és a nyomtatandó űrlapokat egyszerre.
Ennek az az eredménye, hogy a monitorokon nehezebben áttekinthető az űrlap.

A megoldás egy olyan adatformátum kidolgozása lett volna, ami az egyes mezők jelentését írja le, hogy bárki készíthessen kitöltő alkalmazást. Ennek a formátumnak lehetnek "stylesheet-jei" amik meghatározzák, hogy pl. ABEV-ban hogy kell kinéznie egy űrlapnak.

Ez a tervezési hiba egyrészt vendor lock-int eredményez, másrészt akadályozza az egységes kitöltő formátum terjedését is.

Mindennek köze nincs ahhoz, hogy hány MB RAM-ot eszik vagy milyen nyelven írják.

Üdv,
Gergely

Nyílt szabványokról hallottál már? Nem, nem kell felsorolnod az összes szabványt, amit minden gyártó másképpen implementált. Olyan szabványról beszélek, amihez van tesztkészlet, ami alapján ellenőrizhető a helyes működés.

Egyébként most is van interfész, amivel 3rd party alkalmazás tud beküldeni adóbevallást, de csak az "abcd123" jellegű id-k vannak meg hozzá. Tehát a formot megjeleníteni már csak akkor tudod, ha valaki kézzel végignyálazza a formot, és legyártja hozzá a felületet -> nyilván sok a hibalehetőség.

Ezzel az a probléma, hogyha valaki az ő könyvelőszoftverébe akar ilyen interfészt, akkor folyamatosan figyelnie kell, hogy módosították-e ezeket az id-ket a legújabb formverzióban. Ami ugye fejlesztői erőforrást vesz igénybe, ami miatt drágább a szoftver + teljesen értelmetlen problémát old meg, ami egy tervezési hiba eredménye.

Üdv,
Gergely

UI: A Nyílt Szabvány Szövetség tevékenysége nyomán egyébként ma már törvény írja elő Magyarországon a nyílt szabványok alkalmazását...

( psc | 2010. 06. 03., cs – 00:03 )

Én sem láttam.
Titkon azon reménykedek, hogy egyszer valaki a java -t is úgy kinyírja, mint steve jobs próbálja a flash-t...
Natív programokat mindenhová!

A java program pont olyan, mint aki írta.
Azt azért tegyük hozzá, hogy nagyon súlyos tákolmány nem tud születni, mert ahhoz bonyorult a nyelv egy kezdő Pistikének (elnézést az Istvánoktól, nem személyeskedés). Ők elvannak PHP-vel, ami kellően könnyű ahhoz, hogy 3 perc után már megjelenjen nekik valami értékelhető.

Ami elő szökött fordulni: indokolatlanul is ilyen-olyan keretrendszert használnak a kedves fejlesztők, ezért rettenetesen vastag a kód. Egy szirszar alkalmazáshoz, ami 20 sor lenne perlben, írnak egy java programot, ami bezabál egy rakás memóriát, mivel ugye nem erre van méretezve. Ez nyilván nem a nyelv hibája, hanem az emberé, aki ennyire értett hozzá és minden defaulton ketyeg és be van emelve az összes modul, ami csak a fejlesztő birtokába került.

A másik, hogy üzleti logikában átgondolatlan folyamatok ugyanolyan szar kódot adnak javaban is. Lustaság, kevés idő, hiányos információ és máris kész a tákolmány - akármilyen nyelven.

Tipikus, hogy sokan a hibakezelést nulla szinten implementálják, ilyenkor vannak a 78 oldalas verem-dumpokkal megspékelt kedves default java hibaüzenetek.
Ez megint nem nyelvfüggő, hanem általános hiba.

"Azt azért tegyük hozzá, hogy nagyon súlyos tákolmány nem tud születni, mert ahhoz bonyorult a nyelv egy kezdő Pistikének (elnézést az Istvánoktól, nem személyeskedés). Ők elvannak PHP-vel, ami kellően könnyű ahhoz, hogy 3 perc után már megjelenjen nekik valami értékelhető."

Szerintem a Java egy fokkal sem nehezebb, mint a PHP. Aki abszolút nem ért hozzá az úgyis csak copypaste-lni fog össze-vissza.

de a php egy apt-get install-al fennvan, szt mehet a scriptelés, míg a java-t már konfigolni kéne, nem olyan, mint az apache httpd.conf-ja, így szar. Utánaolvas, nemmegy, uristenmiazhogy reverseproxy apacheban, ezsemegy, fosaegész, és már ott is járunk, hogy proghun megy a fikálkodás, hogyezmekkoraszar, bezzegaziis. Akinek meg véletlenül sikerül, az meg kijelenti, hogy ő az első programozó az országban, a többi meg hozsannázik.

Osztan ha meghalljak a tisztelt script-kiddie urak, hogy szakmai interjun kerdes egy cegnel, hogy osztaly emittalasa binarisan, classloaderrel betoltetni majd azt hasznalni, akkor eros kussolas vagy visitas, hogy ezmiafasznak, debuzisag, meg optimalizalni is nekem kell?

Na, ilyen vilagban elunk.

PHP-ben baszkuralod a file-t s azonnal van eredmenye, javaban meg forditasz, deployolsz, molyolsz.
Melyik a konnyebb? Na, nyilvan ahhoz ertenek.

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

(off)

"Akinek meg véletlenül sikerül, az meg kijelenti, hogy ő az első programozó az országban, a többi meg hozsannázik."

Nem ismerem KisJ -t személyesen, de azt tudni kell, hogy ő tényleg egy igazi programozó, és tud is az ember.
Persze vannak rajta kívül még sokan, de azért az erős, hogy neki véletlenül sikerül konfigolni. :)

A Java-hoz letöltesz egy IDE-t, az rakja fel maga előtt a JDK-t, maga után meg a szervereket, hozzáigazítva az IDE-hez. Egyszer írtam így egy-két servletet NetBeans-szel, nagyon egyszerű volt. Sokkal könnyebb, mint felrakni egy LAMP-ot, aztán meg kitalálni, hogy hova kell másolgatni a kódot, hogy fusson.

Ha nem szerver, akkor jobb IDE-khez van felülettervező is, ahol csak rádobálja az ember a formra a vezérlőket meg ír egy kis kódot, és készen is van.

Maga a nyelv tenyleg nem nehezebb. De a Java API-kat jol hasznalni, ismerni es alkalmazni a hatterben meglevo megfelelo tervezesi mintakat igenis gondolkodast igenyel. De ez meg megintcsak nyelvfuggetlen dolog. Egyszeruen: imperativ nyelveken mindegyiken ugyanugy kell programozni, legfeljebb mas logikaja van az API-nak, amit hasznalni kell. Nem a programozasi nyelvek a nehezek/konnyuek (nagy vonalakban ugyanaz mindegyik igazabol), hanem a paltformok megismerese meg egyes esetben konnyebben, masik esetben meg nehezebben.

Én teljesen megértelek.
És a többiek véleményével ellentétben szerintem nem igaz az, hogy csak a szarul megírt javás progrmaok szarok.
Ami java programot használtam eddig, és nem hányt mindenféle hibákat, az is lassú, bloatware, nehézkes, memóriazabáló monstrum volt.
Ha fut eg yilyen programod órákon át, akkor képes anynira belassulni, hogy egy kattintást 2 sec után érzékel, meg hasonló kényelmetlenségek.
Szerintem a java keretrendszerek, meg a jvm-ek úgy szarok, ahogy vannak.
(Figyelem! szubjektív vélemény!)

Szóba került a Delphi meg hasonlók. Arra emlészem,h ogy ha akár pistike összekattintgatott egy delphi programot, akkor az nem lett nehézkes, lassú, memóriazabáló, hanem működött.

Érdemes pl. egy netbeanst (javás) elindítani kicsit, és dolgozni benne, lassú, bloatware, nehézkes, ha egy nagyobb projektet betöltesz, akkor a projektablakban ha kattintasz egy fileon, hogy nissa meg, sok esetben másodpercekre megfagy az egész, stb.stb.

Én jól használható, gyors, kényelmes java programmal még nem találkoztam.

Nem szeretem a java-t, de el kell ismerni, hogy számos igencsak erős lába van ennek a nyelvnek.
- gcj, ami generál akár natív kódot is, a legtöbb népszerű nyelvben ez korlátozott, nem múködik vagy soha nem is volt meg
- rettenetesen nagy a közösségi támogatása, szinten mindenhez van készen megoldás
- a fejlesztő cégek egy nagy része beállt a java-jómunkásemberekkel való munkavégzésre. Tehát mint a kis csavarok, felveszik az embereket, ha valaki nem válik be, kirúgják és jön helyette a következő, aki folytatja ugyanonnan a munkát. Nincs betanítás, nincs egyénieskedés, lefektetett elvek mentén megy a fejlesztés
- a keretrendszerek széles választéka áll rendelkezésre, amiben "félig kész" is van a munka, csak össze kell rakni a darabokat

GCJ: Szerinted a HotSport JIT fordito nem csinal nativ kodot? Igaz, a kulonbseg annyi, hogy az egyik futasidoben tudja az alkalmazas futasa, mukodese alapjan optimalizalni on-the-fly a kritikus reszeket, mig a masik egyszeri statikus kodoptimalizalast csinal, attol fuggetlenul, hogy hol van a bottleneck a kodban. Dontsd el, melyik jobb.

Amugy igen, a kozosseg, a Java ecosystem hatalmas erv. A legtobb open source kod Java, ez hatalmas elony. Nezzuk meg pl., hogy az Apache Software Foundation projektjeinek hany%-a nem Java kod...talan van 5 projekt, ami nem Java, a tobbi mind az.
Mondjuk a tiobe.com indexe alapjan hossz-hosszu ido utan atvette a C a vezetest a Javatol, ebben az egy honapban, 2004 ota folyamatosan elso volt, az az egy masodik hely 2004-ben is csak erosen atmeneti volt. http://www.tiobe.com/index.php/paperinfo/tpci/Java.html

( NagyZ v | 2010. 06. 03., cs – 00:17 )

a legujabb sajat fejlesztesu java programjaim megfelelnek ennek, de ez hosszu ut volt :)

a viccet felreteve, tul sok a programozo a piacon. a felet mar az egyetem elso eveben el kene bocsatani, hogy menj kapalni fiam/lanyom, ez nem neked valo. manapsag sajnos mindenki azt hiszi, hogy o "megtanulhat" programozni. ez egy bizonyos szinten igaz is, viszont ez a kozepszer legalja, szerintem.
en sem tudok rajzolni, elhiszem, hogy bizonyos szintig meg lehetne tanitani nekem, de sosem leszek picasso. (mielott valaki belekotne, tudom, hogy o nem rajzolt, hanem festett.)

a napi uzemeles soran egyebkent en baromi keves javas hibauzenettel talalkozom. talan ehez is erteni kene?

(nezzuk csak, hasznalok cassandrat, glassfisht, kulon jerseyt, grizzlyt, amire a sajat alkalmazasaimat epitem; hasznalok openmqt, tomcatet. van netbeansem, eclipsem, jdeveloperem (na, az tenyleg egy rakat kaki, az asztali gepemen is lassu:())..

+1, a java jo nyelv lenne, csak a tobbi nyelvvel szemben a legnagyobb hatranya, hogy 120-as IQ alatt is lehet benne programot irni (es az olyan is lesz). Aki C++-ul megtanul, annak pl csak akkor lesz "ertelmes" porgramja, ha mar ert is hozza, de ettol a C++, mint nyelv nem lesz jobb, hogy a C++-ban kevesebb a selejt program.
-----------
Happy, satisfied and completely up-to-date Archlinux user since 2009 september (KDE)
"Which version do you use?" "The latest stable" (a random archlinux user)

nem nyelvfuggo, de intelligenciafuggo, es a javahoz ebbol kevesebb kell. Persze vannak jo java-fejlesztok 140-es IQval is, de aranylag javara ilyenbol kevesebb jut
-----------
Happy, satisfied and completely up-to-date Archlinux user since 2009 september (KDE)
"Which version do you use?" "The latest stable" (a random archlinux user)

"Persze vannak jo java-fejlesztok 140-es IQval is, de aranylag javara ilyenbol kevesebb jut"

1. Szerintem ilyenbol (jo Java fejleszto 140-es IQ-val) a Javara jut a legtobb (100%).
2. Amit mondani akartal, miszerint java-ra aranylag kevesebb 140+ IQ-ju fejleszto jut: MIVAN????!!! SZERINTED MIBEN DOLGOZUNK??? PHP-ban???!!!

"Imadom" amikor a sok mihaszna pancser akik nem kepesek olyan helyre bejutni ahol tenyleg jo minosegu Java programokat irnak, itt (vagy barhol) veri a nyalat hogy nincsenek jo minosegu Java programo(zo)k. Egyszeruen csak annyira mas a szint hogy odaig el se lat az egyszeri Pistike.

Ebredjetek mar fel, szalljatok magatokba (es rugjatok fenekbe magatokat egyuttal), es probaljatok egy kicsit ertelmesen gondolkodni (tudom, nehez...).

Apache Software Foundation (projektjeik 90+ %-a Java)? Google (lasd Goole Collections, Gjuice, Google App Engine). Facebook (hasznal Javat).
Eclipse Equinox, RCP?
Attol, hogy ezek esetleg nem end-user szoftverek, attol meg lehetnek nagyon jo minoseguek, csak te nem talalkozol vele se a szabadidodben, se maskor. Mig esetleg egy szoftverfejleszto egy jol megirt komponenst tud dicserni, mert dolgoznia kell vele, API szinten.

Én nem a nyelvre fogtam a 2hibát" (az még tetszik is), hanem a Java -ra, az egészre, beleértve a framworkoket, futtatókörnyezeteket, stb.

"Csak hát sokan nem látnak túl az orruknál és hajlamosak a nyelvre fogni minden hibát, véletlenül se az emberekre..."
Bocs, de én úgy vagyok vele, hgoy olyan programot használok, amire szükségem van. Ilyenek közül, ami javás, csak hígfossal találkoztam.

Lássuk csak, én használok és üzemeltetek: Cisco ANM, Cisco Security Manager, Cisco ISC,Cisco Works, Juniper Network Security Manager, HP Openview Operations, HP NNM, HP Service Desk
stb

Ezen szoftverek mindegyike Java a szerver és a kliens oldalon is nagyrészt.
És egy darab sz*r mind. Okádják a hibaüzeneteket, rejtélyes hibák tömkelegét produkálják az erőforrásokat felzabálják (nem nem 250MB-t, hanem pl a Juniper NSM 1 óra futás után 2GB-4GB-t képes megenni a kliensen ami engedtessék meg nekem egy röhej, a szerver oldalról ne is beszéljünk)
Support válasza legtöbbször ezekre: nagyobb vas több memória az nem érdekli őket, hogy a specifikációnak megfelelő vasra telepített (legtöbbször általuk) sz*ruk nem működik.

Gondolom ezeket a szoftvereket is hátulgombolós idióták írták, mint minden java-ban írt szoftvert ami nem működik.

Na és akkor itt elértünk a topikindító második bekezdéséhez. A nyelv hibája, hogy ennyi rossz program születik, mert megpróbálja kiny@lni a t. programozó seggét ahelyett, hogy precíz kódolásra szoktatná. És ez igen, a nyelv hibája.

Magamról tudom, hogyha írok egy programot C-ben, meg ugyanazt java-ban (tehát azonos kvalitású, azonos programozói tudással rendelkező egyén ír mindkettőben), akkor az előbbi fordításnál reklamál inkább, vagy valgrind tesztelésnél, míg az utóbbi átmegy mindenféle teszten, aztán élesüzemben dobálja az egzotikusabbnál egzotikusabb exceptionjeit.

A nyelv hibaja vagy a platform hibaja? El kene mar kuloniteni a Java Platform kulonfele API-jait es magat a nyelvet. A Java Platform okos hasznalatahoz esz kell. A Java nyelv alapveto ismeretehez sok esz nem kell, elegge konnyen olvashato es irhato nyelv, persze, altalaban a gondolkodast igenylo nyelvi konstrukciok, mint strictfp hasznalata, synchronized hasznalata es egyebek mar az atlag programozo kepessegein tulmutat. Java nyelven kodolni nem nehez. Igazi jo Java programot irni nehez, ahhoz biza gondolkodni kell, ismerni valamelyes a memoriamodellt stb. Hogy azert a nyelv legyen a felelos, mert tudni kell hasznalni? Hat ez rohejes hozzaallas. Minden programozasi nyelven lehet szar kodot irni.

Az, hogy strukturalt a kod vagy nem, erosen LOL dolog, az automatikus kodformazok koraban. En pl. szepen beallitottam magamnak az Eclipse-ben a java kodformazot, minden menteskor formazza is a forraskodot, szepen, ahogy kell. A forraskod kinezete es a szoftver mukodesenek josaga (megfelel-e az elvarasoknak) teljesen kulonbozo dolog.

Valami konkrét példát is kaphatnánk, mert ez így nagyon bullshit gyanús, már ne haragudj.

Java-ban pont hogy nem lehet össze vissza gányolni (lásd fentebb említett php hibák tömkelege), mert a fordító szépen az arcodba tolja a gondokat.

Exception-nal önmagában meg nincs gond, azzal van gond, ha valaki nem kezeli le. Lásd még

try{}catch (Exception e){e.printStackTrace();}

Te meg a stack trace-t látod a logban.

Ellenben mondjuk egy null pointer exception jellegű dolog C-ben szép nagy halálként jelenik meg a futó alkalmazásban, aztán lehet túrni.

"Exception-nal önmagában meg nincs gond, azzal van gond, ha valaki nem kezeli le"
Hogy kezelhetnél le egy exceptiont, amiről nem is tudod, hogy valami nagyon extrém esetben előbújhat valamelyik API belső bugyraiból?

Konkrét példa: HP proliant iLo, 10 indításból egyszer csak outofmemory exception-t dob a java, mikor mind a 10 indításnál ua. memória van a gépben...

"Lásd még
try{}catch (Exception e){e.printStackTrace();}
Te meg a stack trace-t látod a logban."
Na ez az, amitől agybajt kap minden üzemeltető. A legtöbb stacktrace teljesen HASZNÁLHATATLAN, merthogy a nyakatekert API hívások listáját látod benne (trace ca. 90%-a), és nem a konkrét hibát, ellenben híznak tőle a logok mint a k*rvaélet. Mint üzemeltető, ezt a fajta programozási hozzáállást rühellem a legjobban a java-s programokban. Pláne, ha még tovább is dobja az exceptiont fölfelé, ahol megint megkapod ua. a trace-t mégegyszer, mert hátha elsőre nem olvastad végig...

Ja, bocsánat, hogy a java alkalmazásokat is meg kellene tanulni üzemeltetni...

Out of memory exception-t akkor dob, amikor nincs elég heap memória a java VM-nek!!! Tessék elolvasni a dokumentációt (ha a php konfig doksit, az apache konfig doksit el lehet, akkor a java doksit is el lehetne). Hint: -Xmx paraméter környékén tessék nézelődni.

"mikor mind a 10 indításnál ua. memória van a gépben..."

Akkor valami cucc lefut néha, ami megzabálja a heap-et. Ez nem a java hibája, ezt megtenné c++-ban is, ennek a teszteletlen, szarul összegányolt igénytelen bantu négerekkel fejlesztett szemét szoftver az oka.

"A legtöbb stacktrace teljesen HASZNÁLHATATLAN, merthogy a nyakatekert API hívások listáját látod benne (trace ca. 90%-a),"

Ha stacktrace-t látsz, küldd tovább a fejlesztőnek, a stack trace nekik segít. De ez a fejlesztők hülyesége (végig nem gondolt loggolás) Nálunk lehet állítani a log level-t, és default-ban csak a felhasználóra tartozó üzeneteket írja ki, nem pedig a fejlesztő szintű cuccokat. Ha sok a log, akkor ezt állítsd át, és megszűnik minden gondod.

Azonban, ha van hiba, akkor nem biztos, hogy könnyű lesz reprodukálni a hibát, ebben az esetben egy részletes log nagyon hasznos tud lenni.

"Out of memory exception-t akkor dob, amikor nincs elég heap memória a java VM-nek!!!"
Igen, na ne mondd... és akkor mit csináljak? Hogy adjak neki, amikor ez egy appliance, amihez NEM nyúlhatok? Jött, ahogy a gyártó beállította, oszt csókolom. Ha bármit belebarmolsz, ugrik a garancia.

"Ha stacktrace-t látsz, küldd tovább a fejlesztőnek, a stack trace nekik segít."
Nem segít. Össze se tudom számolni, az elmúlt évben hány ilyent küldtem és hány ticketet nyitottam gyártóknál. Az esetek kb 1%-ban lett kézzelfogható eredmény (patch vagy ilyesmi) belőle.

"Nálunk lehet állítani a log level-t, és default-ban csak a felhasználóra tartozó üzeneteket írja ki, nem pedig a fejlesztő szintű cuccokat. Ha sok a log, akkor ezt állítsd át, és megszűnik minden gondod."
Kivéve, mikor hiába állítod a loglevelt, mert le se sz*rja. Konkrétan JasperServer quartz, hiába raktam debug levelre, egy bittel nem adott több infót. Másik ellenpélda meg a JBoss, ami akkor is stacktrace-eket hány, mikor ki van kapcsolva. Erről ennyit.

Végül pedig:
"szarul összegányolt igénytelen bantu négerekkel fejlesztett szemét szoftver az oka."
Ezt kérdezem én is, miért van ennyire sok ilyen java-s szotty? Miért nincs ennyi más programnyelven írt szotty, mikor azokat is ugyanilyen igénytelen bantu négerek írják?

Ha te olyan gyártótól veszel terméket, amelyik nem ad normális supportot, akkor el kell gondolkozni a gyártó lecserélésén.

Ez nem a java hibája, hanem a szarul megírt, jóárasítottan eladott, userekkel nem foglalkozó gyártó.

"Miért nincs ennyi más programnyelven írt szotty, mikor azokat is ugyanilyen igénytelen bantu négerek írják?"

Talán azért, mert az indiai jómunkások olcsóért dolgoznak (ennek megfelelő minőségben). Régen meg kellett fizetni a a közép európai/nyugat európai mérnököket, akik rendes munkát végeztek. Most van helyettük indiai/kínai olcsó jómunkásember, aki pedig a fent említett minőségben fog neked sw-t előállítani. Képzeld el, ha ez c++-ban lenne, akkor milyen lenne ...

Továbbra sem értem. Keress helyettesítő terméket. Ha nincs, vagy nem lehet, akkor tessék venni premium support-ot. Ha ezek után is egy fostalicska a termék (megnyugtatlak, python-ban is ugyanilyen sz@r lenne) akkor nagyjából IJ, és elfogadjuk, hogy az élet nem mindig egyszerű, és kompromisszumokat kell hozni.

BTW Huawei úgy tudom elég ügyesen cimkéz :D

Mondd meg pl az OTP-nek, hogy hiába dobtak ki x száz milliót Hitachira, szar, keressenek helyettesítő terméket. Ugye ezt Te sem gondolod komolyan.

Mellesleg ne mondd, hogy "tessék venni premium supportot", mert van (gondolom az OTP-nek is van, hogy a példánál maradjunk). A sima support és a premium között annyi a különbség, hogy utóbbi drágább :-) És, ha elég kitartó vagy, akkor talán kapcsolnak nem indiait is.

Egyébként ha csak egy-két termék lenne IJ, akkor nem is nyitottam volna topikot, az b@szta fel az agyam, hogy MIND AZ. Szóval ez a helyettesítő termék dumád fail.

Itt a piaci szegmens, lehet betörni. A viccet félretéve, nézd, baromira megértem, hogy téged zavar az olcsó jómunkások által összegányolt igénytelen webes rendszer, de ennek az égadta semmi köze nincs a programozási nyelvhez, sokkal inkább ahhoz, hogy a piacon ezeket a rossz minőségű termékeket is el lehet adni, és van, aki megveszi.

Ugyanilyen rossz minőségű (vagy soha el nem készülő) szoftverekkel találkoztunk már assembly, cobol, pascal, c, c++, c#, és java nyelven is. De ez sosem (általában nem) a nyelv hibája (van persze, amikor belefutnak a korlátaiba) hanem a képzetlen "programozók", és az idióta főnökség kombinációja. Bocsi,
ezen sajnos nem tudunk segíteni.

Nincs neki. A legtöbb appliance-t ma már java-s guival szállítják, aztán jónapot. És ha van is, sokszor annyira bonyolult konfigokat kell kezelnem, aminek az áttekintése gui nélkül lehetetlen. (Nem is a guival van bajom (bár jobban szeretem a parancssort), hanem a kivitelezéssel, mint már említettem volt).

Igen, én is pont az S7000-et akartam felhozni, hogy azon (legalább) a felületet meg tudták csinálni hellyel-közzel korrektre. Igaz, jelenlegi formájában nem helyettesítő terméke a HDS-nek, viszont amit tud, az azért már majdnem jól megy... ;-)

De ha Larry komolyan gondolja, amiket összehadovált, akkor ez a termék hangsúlyt és fejlesztőket kap, és akkor bizony minden lehetősége meglesz, hogy megszorongassa a HDS-t meg az EMC-t.

Cisco ANM, Cisco Security Manager, Cisco ISC,Cisco Works, Juniper Network Security Manager, HP Openview Operations, HP NNM, HP Service Desk

Gondolom ezeket a szoftvereket is hátulgombolós idióták írták, mint minden java-ban írt szoftvert ami nem működik.

Nos, igen: azok írták. Idióták. Régen, amikor még natívan fordított C/C++ kódokat írtak ugyanezen gyártók ugyanezen (vagy más) idiótái, akkor is pont ugyanilyen szarok voltak ugyanezen szoftvereik: HP OV NNM 5.0, CiscoWorks 4.0, Cisco WAN Manager, Newbridge/Alcatel 56020 - ezeket gyakorlatban tapasztaltam - egyik nagyobb fostalicska, mint a másik.

( Yorirou | 2010. 06. 03., cs – 01:55 )

Én egy Java alkalmazást használok napi szinten, az a NetBeans. Semmi gondom vele. Néha igaz egy kicsit leakad, de nem vészes. Sokakkal ellentétben én nem Java-ra használom, hanem PHP/HTML/JS/CSS/Python kódot írok vele.

Viszont láttam már enterspájz Java alkalmazásokat...

Volt egy olyan szerver, amit működésre kellett bírnom. Oldalra felmegy, csomag letölt, kicsomagol, telepít. Könyvtárba belép, start-server.sh (vagy valami ilyesmi). Bash syntax error. Generált egy halom shell szkriptet, csak a placeholdereket elfelejtette kicserélni bennük :) Megint start-server.sh, nem indul. Valami nagyon lehetetlen exception-t dobott (na a logjait megtalálni sem 2 perc volt). Google után rájöttem, hogy a kedves fejlesztők néha elfelejtenek jar-okat bepakolni a csomagba. Ezeket csomagból fel, symlink, és már működött is :)
Telepítéskor még befigyelt, hogy van egy opcionális modul (default-ban off, de én bekapcsoltam), amitől a szerver azt csinálja, hogy request-enként indít 2 szálat, ami darálja a CPU-t és a RAM-ot is szépen eszi... 20 perc után lelőttem, gondoltam hátha csak valamit generál.

Localhoston ment a cucc, gondoltam telepítem szerverre is. Felmásolni nem akartam a cuccot (az irodában elég gagyi inviteles net van), letöltöttem oda is, majd telepítettem. Ami érdekes, hogy ebben a tarballban már benne voltak a jar-ok (a mérete is nagyobb volt), viszont a release nem változott (ez marhára enterspájz :) ). Kezdeti buktatókat ismertem, felrakom, a szöveges telepítő szépen fel is rakja. Jön az első request, elkezdi enni a CPU-t... ami a grafikus telepítőben default off, az a szövegesben automatikusan települ kérdés nélkül. Nincs semmi dokumentált command line kapcsoló, amivel ki lehetne kapcsolni. Biztos config fájlok szerkesztgetésével szépen ki lehetett volna kapcsolni. Ha kitöröltem, akkor a szerver nem indult. Végül "chmod 000"-val meg kellett bizonyos fájlokat kezelni, és így ment a dolog.

Ami miatt szerintem tapasztalod ezeket a dolgokat az az, hogy a Java programozók és főnökeik nagy része igénytelen az ilyen dolgokra (ez sajnos igaz PHP-ra is meg egy halom másik nyelvre/technológiára). Ráadásul akikkel eddig találkoztam, azok közül sokan elitisták, úgy vannak vele, hogy a programjuk már csak azért is sokkal jobb (gyorsabb, jobban skálázódik, szebb a kódja, kényelmesebb stb), mert Java nyelven van írva. Pl egy helyi Java-s konferencián hallottam az egyik előadót fintorogni a JavaScript-re, mivel szerinte az "nem igazi programozás". Ugyanott mások mondták, hogy a cégük keres JavaScript programozókat, mert a Java kódereik nem hajlandóak JS-hez nyúlni.

Ugyanott mások mondták, hogy a cégük keres JavaScript programozókat, mert a Java kódereik nem hajlandóak JS-hez nyúlni.
Azért azt is látni kell, hogy sokan berakják az egyenlőségjelet a kettő közé, hogy Java = Javascript, mert ugye mindkettő tartalmazza azt a szót, hogy Java. És mivel nekünk van egy csomó Java-s programozónk, ezért elvárt, hogy mind profi Javascript-es is legyen.

A "nem hajlandóak JS-hez nyúlni"-nak meg egy olyan értelmezése is van számomra, hogy a Java programozóik nem értenek magas szinten a JS-hez, persze tutorialok, meg manualok, meg net túrás után képesek bizonyos dolgokat elvégezni, de ésszerűbb lenne inkább megfizetni egy profi JS-es embert (akár projekt jellegű időszakos munkára is), akinek kimondottan ez a szakterülete és nincs szüksége tutorialra.

( uid_228 | 2010. 06. 03., cs – 08:51 )

Azureus, JDownloader. :)

--
Wir sind erfaßt, sind infiziert,
Jedes Gespräch wird kontrolliert.

( syntern | 2010. 06. 03., cs – 09:15 )

... alacsony a kerítés, az biztos :)

( Csigaa | 2010. 06. 03., cs – 10:07 )

Nem láttam durvább hibákat mint bármi másban.
Valójában a felhasználói programok nagy része, függetlenül hogy miben írták, bugos tervezetlen szar. Ennek az oka pedig hogy mindent azonnal gyorsan kiadnikiadnikiadni, mert akkor több lesz a fizető felhasználó [meg a nem fizető is, "ezért pénzt kiadni???"] vagy többen látják a kódot [meg azt is hogy a kód mekkora szar].

Valaki meg is fogalmazta, "Release early, release often". Őszinte gratulácói neki.

Valaki meg is fogalmazta, "Release early, release often". Őszinte gratulácói neki.
Pláne gratuláció, mert ha jól emlékszem eredetileg ez a mondás úgy szólt, hogy "test early, test often" csak valaki kicsit összekeverte a dolgokat és azóta ebben a torzult formában fertőzi az ipart. :)
---
Internet Memetikai Tanszék

( talisker | 2010. 06. 03., cs – 10:06 )

Mivel az Eclipse-t mag a NetBeans-t már mondták, ezért csak:

jEdit, meg természetesen a Jalbum (http://www.jalbum.net).
Ez utóbbi igen ütős szerintem.

Mindemellett nálunk van egy-két rendszer, ami 7-800db modulból áll, kb olyan 3000db körüli GUI-s képernyőt jelent.
Ráadásul ez még kövületes Oracle Forms/Reports-ban fejlesztődik, aztán meg cross-compilációval születik belőlük egy tonna .jar.

Az alkalmazással JAVA tekintetben semmi probléma nincsen, GUI-k meg egyebek teljesen normálisan, megbízhatóan mennek.
Próbáltuk a rendszert már portolni natív JAVA-ra, de sajnos közelébe sem értünk annak a teljesítménynek, amit az Oracle IAS Fors/Reports "plugin"-ja ad.

Bizonyára mi voltunk nem profik, de egyelőre ez van. :( :)

Szal osztom, hogy nem a JAVA miatt szar egy program, hanem a balf@sz tervezetlen kúl kódhányás miatt.
És persze ez ugyanúgy igaz bármilyen nyelvben írt dologra.
---------------------------------------------------
Talisker Single Malt Scotch Whisky aged 10 years :)

( Csigaa | 2010. 06. 03., cs – 10:11 )

NetBeans, Mercury Messenger, Azureus így első körben. Sokat nem használok.

( ang | 2010. 06. 03., cs – 10:29 )

javaval keszul az android gui-ja is, a froyo 2.2 eleg gyorsnak tunik... az ottani szinte osszes app valami javaszerusegben irodik, ahogy ertelmezten az android sdk-t

spec. szemely szerint desktopon ruhellem a java-t, mert mire betolt valamit egy evszazad (gyors vinyoval is), de pl. openoffice-t meg nem csereltem le abiwordre, vagy koffice-ra

szerencsemre uzemeltetni nem kellett eddig prod java alkalmazast, de nem kivannam olyan nagyon a nyakamba ha nem muss sein

Pontosítanék, még a nyelv sem ugyanaz, mert csak egy subsetje. Sok mindent nem lehet használni, ami egyébként bevett java-s dolog, plusz az, hogy külön java-s fileba kell összegyűjteni az összes erőforrást konkrét memóriacímekkel, különösen nyakonvágja a magasszintű filozófiát (oké, hogy a t. Pistike ebből semmit nem lát, mert megcsinálja neki az eklipsz plugin, de attól még így van). Szóval nemcsak a futtatókörnyezet más, a nyelv is csak "javaszerű".

a kerdesfelvetes a jolmukodo java programrol szolt, nem volt megadva milyen java subset nyelvezetben, meg futtatasi kornyezet meg semmi ilyenesmas

reszemrol futtattam mar rubyonrails-t native ruby-s meg jruby-n keresztul java-s kornyezetben is,icetea,blackdown,sun-jre meg mas vm-ekben is probalgatva. egesz mas nyelven irodott a kod, mint amilyen kornyezetben vegul futott... nem mondom sima ruby-s mongrel-el egyszerubb az elet, mert nincs meg a jvm-es overhead se, a jrubv-ruby kompatibilitasi kerdesek se, de vannak (ceges) kornyezetek, ahol preferealjak a java-s kornyezetben valo futtatast... sysadmin (es akar alkalmazasfejlesztes+debugging) szempontbol ebben a kontextusban a java/jruby (itt is) tobbletfeladatot jelent sztem. de megvallom vannak elonyei amiert erdemes lehet a javas megoldast alkalmazni.

visszaterve az elobbiekhez, sztem az androidon futo app-ok lehetnek majd pelda jol mukodo java programokra, ha ez igy belefer a topicinditasba.

elsosorban abbol indulok ki, hogy itt van egy elore megadott, vegiggondolt programozasi kornyezet, kulso tenyezok amikre oda kell figyelni, es bizonyos tekintetben "szukosseg", ami jo programok irasara kenyszeriti a kodereket.

alapjaratban szerintem azert cikik a java-s programok, mert pont az iszonyatosan sok rendelkezesre allo memoria/proci kontextusaban irodnak... mint sok jatek is manapsag... s ahol nincs bekorlatozva az eroforras, akkor pazarlo kodok keszulnek. de legalabb kapunk erte gyors procikat, meg 2-3 evente upgradelehetosegeket...

nezzuk meg a "demo" scene-ben mik szulet(t)/(n)ek 64k meretben... ott optimalizalva van kod meg minden. de nemis java...

( agolon | 2010. 06. 03., cs – 11:09 )

Szerintem a szar program, mint olyan, független az adott nyelvtől.
--
2e845cb4c3a5b5bd6508455b1739a8a2

( Charybdis | 2010. 06. 03., cs – 11:56 )

Freemind (mint jól működő javas program)?

( sunmao v | 2010. 06. 03., cs – 12:04 )

Nem akarok még több flame-t generálni és én nem is vagyok java ellenes, se java fan. Csak találtam egy groteszk cikket, aki gondolja elolvashatja én jókat derültem rajta...

http://lohere.net/ikm/index.php/JAVA

( kispista | 2010. 06. 03., cs – 13:05 )

Ha édesanyám ezt most látná nem nevezett volna el Istvánnak :D

btw. ennek a topicnak mi értelme volt? :)
de hogy legyen benne valami értelmes dolog is:
- Tegnap beállított hozzám egy Tyrannosaurus Rex és Hamlet. Volt nagy dínóm, dánom!
c'mon guys, give me your plus one's! :D

( dejo v | 2010. 06. 03., cs – 14:41 )

Nekem gyerekkoromban volt egy jó Java(-s) játékom: Java építő. Volt belőle kisebb és nagyobb készlet. Nekem a szüleim vettek vagy 3-4 fajtát. (Lehet többet is, pontosan nem emlékszem eltelt azóta vagy 45 év.) Sajnos bő 10 éve amikor az én gyermekeim ebben a korban voltak nem lehetett kapni, de most már ismét lehet, igaz arany árban.
Ez nem fagyott, és azt csinálta amit elvártam tőle. Igaz a piros átvezető elemek kissé ridegek voltak és ha nem figyelt az ember gyermeke és erőszakosabban nyomta meg bepattintáskor, akkor néha letört a pereme. De hamar rájöttem, hogy a kék kereteket a sárga csatlakoztatóknál kicsit meg kell lazítani és úgy bepattintani a piros átvezető négyzetet, majd a kék keretet össze kell nyomni.
Szóval már akkor az a játék is megkövetelte a user-tól a helyes használatot, ami részben íroásba volt foglalva részben a tapasztalatból kellet megtanulni.
:-{)E
--
Tertilla; Tisztelem a botladozó embert és nem rokonszenvezem a tökéletessel! Hagyd már abba és kész!

( gUHU | 2010. 06. 03., cs – 15:00 )

Te is a nyelvet hibáztatod azért, mert a programozó béna. Szerintem gondold át ismételten a problémát.

-- "Bízzál Istenben és tartsd szárazon a puskaport!" - Cromwell --
-- Sayusi Ando - http://sayusi.hu --

( kmARC v | 2010. 06. 03., cs – 15:48 )

Huh, hát jó sok a hozzászólás, nem is olvasom végig,hátha már leírták.

Nem a nyelvvel van a baj. A gond az, hogy túl jó, és tul sok előre megírt cucc van már hozzá, amit a jobb IDE-kben pikkpakk összekattintgatsz, pár nap alatt írsz egy sok fícsört tartalmazo appot, és ez indirekt módon bizonyítja, hogy mekkora jó programozó vagy, ezért aztán írsz még egy csomó ilyent.

A pár nap alatt összegányolt szarod hibáktól hemzseg, nincs megtervezve, nem lesz bővíthető, és így tovább. A nyelvhez sem értesz, később elakadsz, és így tovább.

Emiatt arányában sok szar javas program van, tényleg. De emiatt nem a nyelv a hibás, hanem a rossz programozók.

( kisg v | 2010. 06. 03., cs – 17:48 )

Egy szó: Hudson
Simán nyeri a legkönnyebben telepíthető CI szerver kategóriát (meg kb. az összes többi kategóriát is :) ).

A posztoló frusztrációját egyébként meg tudom érteni, Sun X2100M2 szerver menedzsment Java kliens kódját kénytelen voltam megnézni, mert nem akarta mountolni az ISO image-emet. Szomorú látvány volt. Sajnos a menedzsment felületeket minden projektnél a "B" vagy "C" csapat írja, tehát jó messzire ki van outsourcolva, és az olcsóbb programozók dolgoznak rajta. Ez semmit nem mond el a Java nyelvről, vagy a különböző Java platformokról (EE, SE, ME, Dalvik ... stb.).

Üdv,
Gergely

( KGer | 2010. 06. 04., p – 13:22 )

A Java az egyetlen igaz uralkodo nyelv.

( Charybdis | 2012. 01. 05., cs – 13:30 )

Ubuntun én még nem találkoztam jól működő Java applettet vagy Java desktop alkalmazással. nem értem, miért erőltetik desktopon a javát. Ami nem megy, azt nem kell erőltetni. Lassú és fagy, én ennyit látok felhasználóként a javából. A böngészőt rendszeresen lefagyasztja egy-egy java applet.