Fizetni kell - bekeményít Java SE ügyben az Oracle
2016-12-19T11:16:07+01:00
2017-01-14T21:24:20+01:00
2022-07-21T16:36:47+02:00
  • Na, mielőtt mindenki pánikolni kezdene. Nálunk is körbement a cégnél ez a cikk, úgyhogy utánaolvastam, mert mindenki csak odáig jutott, hogy Java és Licensz és Pénz, és jött a parázás.

    Ha te installer-rel rakod fel a java-t, ÉS használsz bizonyos komponenseket, akkor kell fizetni. Ezek mind olyan komponensek, amikre egy átlag alkalmazás esetén az égadta világos semmi szükség nincs, például adatgyűjtés a JVM-ben futó programokról, majd ennek az analizálása.

    Tehát nyugodtan lehet java-ban fejleszteni, jvm-et telepíteni, ebben alkalmazásokat futtatni, stb. Nem kell parázni.
    Mutasd a teljes hozzászólást!
  • (2) Ha ír egy cég egy alkalmazást GAE-re Javában, akkor kell az Oracle-nek külön liszencdíjat fizetnie a Java használatáért?

    Szerintem nem.

    A GAE-ben a Java a bérelt platform része, nem? Ha igen, akkor neked nem kell bármit fizetni utána az Oracle-nek, te a Google-nek fizetsz, azt amit az kér érte, és kész.

    Hogy megdrágulhat-e a GAE emiatt, arra szerintem csak a Google tud válaszolni. De ha OpenJDK-t használnak akkor szerintem nem sanszos.
    Mutasd a teljes hozzászólást!
  • Tudod egy (rossz nyelvek szerint) osszessegeben 100 millio dollaros projekt (aminek resze az android es sokan hasznaljak) eseteben ezt nem teheted meg. Ok kifiezetik amit szeretnenek es az ugy legyen ahogy szeretnek,nem pedig ugy,hogy ahogy a .Net es a Xamarin tudja...
    Mutasd a teljes hozzászólást!
  • Nem tudom, nálunk speciel még gépből is csak pár típust használ a megrendelő - azon egyszerű oknál fogva, hogy nem akarja fél Indiát felvenni alsó és közép szintű supportra. Általában véve próbálnak egységes megoldásokat alkalmazni cégen belül - egyszerűen túl nagyok ahhoz, hogy hagyják szétfolyni a dolgokat. Nincs háromféle vonalkód, nincs tetszőleges típusú eszköz.
    Mutasd a teljes hozzászólást!
  • Ezt simán meg lehetett volna oldani xamarinnal is.

    Lehet, hogy meg. Csak hozzank sem egyszerre erkezett az osszes igeny, hanem szep lassan jottek az ujak az uzlettol. Es tul kenyelmesek ahhoz, hogy a usernek valasztani kelljen akar egy gombbal, hogy milyen kodot is olvas be, pl. ezert fut sok minden parhuzamosan. Az meg megint uj igeny volt, hogy lassunak talaltak az ingyenesen elerheto megoldasokat QR/Aztec Code beolvasasra, ezert lett fizetos. Text kod olvasas szinten detto, azert van agyon optimalizalva OpenCV-vel es volt probalkozas C++-os megoldassal is. Es emellett fusson egy andorid 4-es 2 magos lassu keszuleken, de tamogassa a legujabb csucs keszuleket android 7-el. Szoval az ugyfel igenyek valtozhatnak, es ha mar indulasnal keretek koze vagy szoritva, akkor az sokkal nagyobb problema lesz, amikor az uj igenyeket nem tudod befogadni technologiai korlatok miatt.
    Mutasd a teljes hozzászólást!
  • Mondjuk nálunk nem xamarinban van megoldva egy mobil app, hanem windows store app van, sqlite adatbázissal (szintén offline működés, de mi implementáltuk a szinkronizációt, mert picit komplexebb a szerver oldal, nem elég egy sima replikáció), a vonalkód olvasó sima EAN128-at olvas.  Vagy 60 tábla, vagy 100 mega adat lenn a gépen. Ezt simán meg lehetett volna oldani xamarinnal is. Ezzel együtt kétszer sem mondom, hogy van olyan megoldás ahol a javás megközelítés olcsóbb / jobb.
    Mutasd a teljes hozzászólást!
  • Ez az elmelet, a gyakorlat meg megint mas... Lehet, hogy egy egyszeru alkalmazasnal nem jonnek elo a fo problemak, de nalunk nem ez a helyzet. Androidon kell futnia: QR/Aztec/Text Code (OpenCV) olvasonak parhuzamosan (aki felismeri az nyer), NFC olvaso, ill. lokalis DB ~3GB (az alkalmazasnak offline is mukodnie kell) es szinkronizal fel-le (Mobilink - ehhez szinten fizetos lib van hasznalatban ill. Ultalite DB-amihez szinten nincs semmi Xamarintol, ha jol latom google alapjan), A QR es Aztec lib fizetos, azaz irhatod a wrappereket hozza Xamarinban, mert nincs. A valaszido kritikus, ezert is hasznalunk fizetos megoldasokat, es az OpenCV-s Text Code olvaso is szenne van optimalizalva, hogy 1 sec-es valaszidot elerje. Szoval itt a Xamarin nem jatszik. Es nyilvan van sok komoly alkalmazas ahol szinten nem. Persze, egyszeru appnal elmegy.
    Mutasd a teljes hozzászólást!
  • A droidos API-t ugyanúgy meg tudom hívni belőle mint ha javában fejlesztenék. Ugyanarra a bytekódra fordít amire a java is a dex után. Akkor miért is ütköznék bármibe is ?
    Mutasd a teljes hozzászólást!
  • Azért a xamarin nem mai gyerek, és jó pár cég használja egészséggel

    Es? Ez meg a tenyen nem valtoztat,h elobb fogsz korlatokba utkoxni xamarinnal....
    Mutasd a teljes hozzászólást!
  • Engem az érdekelne (és elnézést ha hülyeséget kérdezek), hogy a felhős platform szolgáltatásokra (mint a Google App Engine stb.) van-e bármilyen hatással az Oracle-nek ez a lépése vagy nincs? Pl. megdrágulhat emiatt a GAE?

    (2) Ha ír egy cég egy alkalmazást GAE-re Javában, akkor kell az Oracle-nek külön liszencdíjat fizetnie a Java használatáért?
    Mutasd a teljes hozzászólást!
  • Ez ha stabilnak és megbízhatónak is bizonyul a .NET core

    Valamint felülről binárisan kompatibilisnek... merthogy a belinkelt .NET core-os oldalon a telepítések rögtön azzal kezdik: takarítsd le a .NET Core korábbi verzióit.
    Mutasd a teljes hozzászólást!
  • Befektetési banki és szigorúbban véve nagyteljesítményű, sebességkritikus backend rendszerek esetében, mint például a trading rendszerek, a Java konkurenciája nagyjából egyedül a C++. És egyre nagyobb teret hódít magának a Java az utóbbival szemben, köszönhetően a nem kevés nagyobb teljesítményt biztosító fejlesztésnek, amit beletett mind az Oracle, mind a community. Ez ha stabilnak és megbízhatónak is bizonyul a .NET core, akkor is nagyon sok év, mire meglesz a megfelelő tapasztalat és támogatottság. Ha egyáltalán a közösség le akar mozdulni egy jól működő és stabil platformról. Én erre nem látok racionális indokot. Az itt elhangzottak nem racionális indokok, hanem érzelmi indíttatású félreértelmezései egy direkt félreérthetően megírt cikknek.

    A fentiek nem a heavyweight application serverekre vonatkoznak, hanem szigorúan véve a core Java-ra.
    Mutasd a teljes hozzászólást!
  • az unofficial blackdown.org.

    Meg még az sem...
    Mutasd a teljes hozzászólást!
  • Nem a fizetés nem fizetést érzem itt problémának hanem az egész hozzáállást. Eddig miért nem kértek érte pénzt? Miért volt ez ilyen surranó pályán befutó tétel amikor már a fél világ ezt használja?

    De kértek. Attól, hogy nem mentek az ügyfelek nyakára a licenc audittal, hanem becsületkassza volt, az nem jelenti azt, hogy nem kértek érte pénzt.
    Mutasd a teljes hozzászólást!
  • Szerintem ami változott az utóbbi időben, hogy lett egy erős konkurenciája a Java-nak

    És itt mire gondolsz? Amíg a .NET nem fog rendesen Linuxon futni, addig nem látom, hogy leválthatná. Amíg a Python nem fog saját motoron rendes sebességgel futni, és nincs rendes interoperabilitása a Java-s eszközökkel, addig dettó.

    ha az Oracle elhanyagolja akkor bizony lassan halálra is ítéli az egészet.

    A Java SE réteget nem fogja elhanyagolni szerintem.

    A Java EE réteg az sanszos hogy az Oracle kivonul belőle vagy megpróbálja valahogy monetizálni. Ennek nem kimondottan örülök, minthogy annak sem, hogy az Oracle hanyagolja a middleware fejlesztést is a DB és a Cloud kedvéért.
    Mutasd a teljes hozzászólást!
  • Mutasd a teljes hozzászólást!
  • Azért a xamarin nem mai gyerek, és jó pár cég használja egészséggel - és használta akkor is, amikor még aranyért adták. A .NET core már újabb technológia, de azt sem a nulláról fejlesztették le a microsoftnál. A mono már lassan 10 éves, és elég komplex dolgok is épülnek rá, Pl. unity3d, monodevelop, xamarin.
    Mutasd a teljes hozzászólást!
  • A JavaFX egy UI toolkit, nem egy deployment model. Tehát inkább a Swing alternatívája, nem az "appletek alternatívája". 
    A JavaFX-szel is lehet applet/webstart appokat csinálni, mint a Swinggel. Az AWT/Swing-et alapból ablakos alkalmazásokra tervezték, de JavaFX-nél elég egy HelloWorldöt megnézni, már ott is lehet látni (pl. primaryStage), hogy azt appletekre találták ki.
    És amikor JavaFX 1.0-t bejelentették, a Sun is azt mondta, hogy Flash/Silverlight konkurense akar lenni.
    Mutasd a teljes hozzászólást!
  • Aha,persze. Xamarinhoz sok szerencset, ha mondjuk olyan komplex alkalmazas van,mint nalunk. A .Net Core fel eves, a monohoz is sok szerencset kivanok. Es hozza teszem,h ez egy futo fejlesztes, tehat a java evek ota tudta a kovetelmenyeket,mig az MS most vasarolta fel a Xamarint.  .Net Core igeretes,de meg projekt tapasztalatrol sem talaltam infot,ami bonyolultabb egy hello world. Persze,ettol felolem kezdhet vele barki uj projektet. Csak akkor a kockazatokat is vallalja.
    Mutasd a teljes hozzászólást!
  • A .NET-es kódodat ugyanúgy újrahasználhatod Androidon, IOS-en (xamarin), linuxon (mono, .NET core), windowson, felhőben (Azure, Amazon, Google). Vékony klienst ugyanúgy csinálhatsz vele (asp.net mvc, webforms) ahogy vastagot (wpf, winforms, vagy ha valamiért linuxosat és mac-eset is akarsz (enterprise esetén nemigen akarsz) akkor Pl. GTK#).

    A .NET sem most kezdődött multiplatformos lenni, ráadásul a javával ellentétben ezt fejlesztik is, így egy év eltelte a .NET esetén picit több változást hoz mint a javánál. Amúgy a java sem volt mindig annyira multiplatform, én emlékszem még olyan időkre, amikor nem volt hivatalos java jdk csak az unofficial blackdown.org.
    Mutasd a teljes hozzászólást!
  • Egy enterprise szoftvert főleg ha az banki nem 3 évre tervezel és itt jön be az, hogy ha valaki nagyvállalati környezetben ezt meglátja akkor bizony menekülni fog a Javatól. A Microsoft Winformsra meg tudta csinálni a High DPI-t rendesen? Pedig az is egy több mint 10 éves technológia.

    Enterprise szoftvert nem GUI-san szokás megcsinálni, minden téren jobb egy vékony klienses (böngészős) alkalmazás. Mi már közel 15 éve így fejlesztünk és sose volt gond a HDPI-vel Java alatt ;)
    Internetbanknál is sokkal jobb a böngészős megoldás, mint a vastag klienses. Nem is értem a CIB miért nem írta át még eddig, hiszen valóban egyre több böngésző tiltja (vagy csak nem engedi alapértelmezetten) az appleteket.
    Mutasd a teljes hozzászólást!
  • Nem a múltról beszélünk hanem a jövőről.

    Szinte mindegy, h miről beszélsz. A .Net most kezd platform független lenni (a mono volt, de sokkal korlátoltabb, mint a java), a java meg évekkel ezelőtt is az volt. Ez azért fontos, mert bizonyos kódok, interface-ek újrafelhasználhatóak Androidon, Weben, backend oldalon és vastag kliensen is. Ez pedig nagy előny a fejlesztésben is és a projekt büdzsében is. Nálunk pl. van back-end(micro servicekkel), java-se-kernel(windows-linux, hogy bárki ráhúzhasson saját vastag klienset), android-kernel(hogy külsős cégek bármilyen guit ráhúzhassanak androidon), android-app(kernellel együtt gui-val), és két web front-end. Itt meglehetősen sok kód közös, és nagy cégeknél ez nem szokatlan. Ilyen környezetben, .Net még mindig kockázatosabb, mint a java és nem tudok arra gondolni, hogy majd 5 év múlva jobb lesz. Vagy majd azt mondom, hogy pár év múlva kiforrja magát?

    ha 3-4 éve amikor egy aktuális nagy projektet elkezdtek lett volna open source .net c#-al és f#-al akkor bizony erősen elgondolkodtak volna rajta.

    Ja, hát gondolkozni lehet rajta, csak kérdés, hogy milyen kontextusban? A jelen témával összefüggésben? Sokan leírták, hogy mi történt, és nem is értem, h emberek miért vannak azon meglepődve, amikor az Ora. licenc díjat hajt be (ha használják azon funkciókat), ami után amúgy is kellett volna fizetni, de nem tették meg?
    Mutasd a teljes hozzászólást!
  • Az applet már több, mint 5 éve is elavult volt. Annak az alternetívája az ULC és a javaFX.
    Mutasd a teljes hozzászólást!
  • Ez az ami változni fog szerintem. Nem a múltról beszélünk hanem a jövőről. Én is befektetési banki területen mozgok és már olyat is hallottam, hogy ha 3-4 éve amikor egy aktuális nagy projektet elkezdtek lett volna open source .net c#-al és f#-al akkor bizony erősen elgondolkodtak volna rajta.
    Szerintem ami változott az utóbbi időben, hogy lett egy erős konkurenciája a Java-nak és ha az Oracle elhanyagolja akkor bizony lassan halálra is ítéli az egészet.
    Nem a fizetés nem fizetést érzem itt problémának hanem az egész hozzáállást. Eddig miért nem kértek érte pénzt? Miért volt ez ilyen surranó pályán befutó tétel amikor már a fél világ ezt használja?
    Mutasd a teljes hozzászólást!
  • Elég sok panaszuk van, mert az összes browser kitíltotta vagy megnehezítette az applet használatát vagy hogy hívják őket. Emiatt elég bonyolult módon kell elindítani. Tudják ők is csak egy új webbankot lefejleszteni nem két fillér.
    Mutasd a teljes hozzászólást!
  • Én új projektet tuti nem kezdenék Javaban és nem is javasolnám senkinek az biztos. Pont az ilyenek miatt.

    Ez a te bajod. Ahol normális pénzt szánnak a projekt költségeire, ott a pénzes Java licenc sem tétel (sőt valószínűleg úgyis benne van valami másban). Sőt, pénzügyi területen szerver oldalra a Windows legtöbbször fel se merül, kivéve ha valami legacy és/vagy pénzes c++ libraryt kell használni amit nem csináltak meg rendesen Linux .so-ban.
    Ebből kifolyólag a Java-nak igen kevés alternatívája van szerver oldalon pl pénzügyi területen, és a finnyásságodat leginkább csak megköszönnék és közölnék hogy holnap nem kell jönni dolgozni.
    Én legalábbis a világ legnagyobb befektetési bankjainál így láttam.

    A pénztelen projekteken meg úgyse fizetnek supportért, nem használják a pénzes feature-öket, és továbbra se kell fizetniük egy fillért sem.

    Az Oracle bejelentette, hogy szándékában áll behajtani a licencdíjat azon funkciók után, ami az elfogadott EULA alapján pénzbe kerül. Ha nem használod, ne installáld fel, és akkor nem fizetsz utána.
    Nem látom, emiatt miért kéne felháborodni.
    Mutasd a teljes hozzászólást!
  • Ja, hogy azt akarod mondani, hogy több mint 10 év nem volt elég, hogy fusson. Gyakorlatilag az MS meg ezt sz@rja le. Egy nagyvállalat meg lehető legkevesebb kóddal akarja a lehető legtöbb platformot támogatni. Valszeg ezért választotta anno a CIB a java-t. Valszeg még így is viszonlyag kevés panaszuk van HDPI-s ügyfelektől. Ellenben ha winformst választottak volna, akkor a felhasználók x%-a kiesik, és nem csak elégedetlen. Szerinted melyik a jobb?
    Mutasd a teljes hozzászólást!
  • Nem véletlen az sem, hogy a MySQL-t is ahogy az Oracle-höz került azonnal leforkolták és mára a főbb disztribuciók már MariaDB-vel jönnek ki (ez a mysql fork).

    Ez sem ilyen egyszerű. A MySQL-t az eredeti készítője forkolta miután eladta az Oracle-nek. Az eredeti fejlesztőgárda jelentős része nem is maradt az Oracle-nél.
    Mutasd a teljes hozzászólást!
  • Most trollkodsz, ugye? Nem arról beszélünk, hogy mi fut meg mi nem hanem arról, hogy ki mit sz@r épp le. Mellesleg izélheted ha fut rajta csak épp a gépek jópár %-án használhatatlan és teljesen mindegy milyen oprendszer alatt.
    Mutasd a teljes hozzászólást!
  • Microsoft Winformsra meg tudta csinálni a High DPI-t rendesen?

    Fut linuxon és Mac-en HDPI-vel? Nem ismerem, ezért kérdem.
    Mutasd a teljes hozzászólást!
abcd