.NET, mint Java SE alternatíva
2016-12-21T09:01:24+01:00
2016-12-24T13:58:19+01:00
2022-07-21T17:06:56+02:00
  • Amúgy szerintem eléggé rétegigényeket feszegettek.

    Szerintem nem.

    Azt feszegetjük, hogy mikor lesz a .NET Core integrálható meglévő Linux + Java alapú környezetbe, Java alapú termékekkel teljes interoperábilitást nyújtva.

    Feltéve ha lesz még java 10. Ami szerintem azért lesz 10-es, mert legkorábban 10 év múlva hozza ki az Oracle. És persze ez a feature is épp kimarad majd...

    Attól nem tartok hogy Java 10 ne lenne. Az Oracle szinte teljes alkalmazás stackje a Java-ra épül.

    Ami ezt a feature-t illeti, szerintem bele fog kerülni, mivel pont azokon a területeken erősíthet vele a Java ahol a .NET és C++ erősebb volt:
    - memória kezelésből adódó teljesítmény optimalizációk
    - struct-ok stacken keresztüli átadása
    - több mint egy return-by-value érték visszaadása memória allokáció nélkül
    - processzek közti memória területeken keresztüli (shared memory) kommunikáció egyszerűsítése
    Mutasd a teljes hozzászólást!
  • .NET alatt viszont van managed C++, ahol compiler direktívával tudod megmondani akár egy osztályon belül is, hogy mi legyen managed és mi nem. Na, ez viszont tudtommal még tényleg nincs a Core-ban.

    Amúgy szerintem eléggé rétegigényeket feszegettek.

    Erre majd talán a Java 10-re várt új megoldások (ObjectLayout/StructArray) adhatnak majd megoldást.

    Feltéve ha lesz még java 10. Ami szerintem azért lesz 10-es, mert legkorábban 10 év múlva hozza ki az Oracle. És persze ez a feature is épp kimarad majd... 
    Mutasd a teljes hozzászólást!
  • Lehet kicsit kényelmetlenül néz ki JNI esetén a határon lévő C/C++ kód, viszont így létrejön egy réteg a két világ között, és abban van az ocsmányság, nem a magasabb szintű kódban, ahol gyakorlatilag egy native modifierrel el van intézve a dolog.

    Sőt, a sun.misc.Unsafe használatát a JIT compiler megfelelő 1-1 natív instrukcióval helyettesíti metódushívás helyett tehát még JNI nélkül is lehet relatíve egyszerű gépi kóddal ekvivalens dolgot írni... feltéve ha a kód relatíve egyszerű. Sajna a vektorizációs utasítások viszont így nem érhetőek el, mivel nincs is velük ekvivalens Java típus. Erre majd talán a Java 10-re várt új megoldások (ObjectLayout/StructArray) adhatnak majd megoldást.
    Mutasd a teljes hozzászólást!
  • tanultak a Java-ból, nem csak ennél a problémánál

    Baj lett volna, ha nem így lett volna egy jóval később tervezett nyelvnél. Bár ez egy kicsit talán fölényeskedő megjegyzés egy olyan platform esetében, ami kézzel-lábbal a Java sikerét próbálja meglovagolni és tizenéve szeretne neki konkurenciát állítani :) Tehát a sikeréből és előnyeiből legalább annyit próbálnának tanulni...

    Tudsz egyébként példát mutatni, hogy pontosan mire gondolsz? Javaból is lehet többféleképpen natívat hívni. Én amennyire tudom C# forrásban megjelennek natív implementációt érintő dolgok (marshaling stb). Lehet kicsit kényelmetlenül néz ki JNI esetén a határon lévő C/C++ kód, viszont így létrejön egy réteg a két világ között, és abban van az ocsmányság, nem a magasabb szintű kódban, ahol gyakorlatilag egy native modifierrel el van intézve a dolog.
    Mutasd a teljes hozzászólást!
  • Csak feltételezhetően nem ugyanaz a teljes implementáció Java-ban mint .NET-ben ezért az erre épülő kód (pl. a memóriakezelés) különböző lesz, és a réteghatár alatt feltehetően különböző még .NET/Win és .NET-Linux között is az oprendszer különbözősége miatt, ezért ezt meg kell írni és-vagy újratesztelni, nem lehet egy kész kódbázist úgy ahogy van rögtön használni.
    Mutasd a teljes hozzászólást!
  • Felteszem .NET-hez is van/lesz megoldás native kód hívására, ahogy Javaban is van.

    Ezt tipikusan nyelvi szinten beépítették, nem hozzátapasztottak utólag valamit (tanultak a Java-ból, nem csak ennél a problémánál).
    Mutasd a teljes hozzászólást!
  • A kontextus nem ez volt. Az egész big data, banki informatika, machine learning témákban utcahosszal le van maradva a MS. Ez nem fog anélkül megváltozni, hogy a MS rengeteg erőforrást tolna bele. Ha egyáltalán sikerül neki, lásd pl az említett mobil piacot, ahol csak szenvednek. Az alkalmazásokat ugyanis a közösség fejleszti, nem a MS. Nekik pedig komoly motiváció kell az amúgy működő és stabil platformokról átváltáshoz. Hogy tiszta legyen: ez messze nem a technológiáról szól.
    Mutasd a teljes hozzászólást!
  • A MS-nek nem kell mást tennie, mint átemelni a létező implemetációkat. Ahogy tette is - lásd asp.net MVC, entity framework, stb.

    Itt nem a MS saját termékeiről és nem az open source cuccokról beszéltünk, hanem az egyéb üzleti termékekről amelyek készítőinek időt kell tölteniük a saját termékeik .NET + linuxra portolásával, amire vagy van üzleti indoklásuk vagy sem.

    Lehet azzal jönni hogy van .NET saját, de ha az nem illeszkedik a meglévő céges infrastruktúrába akkor teljesen lényegtelen, az azt jelenti hogy nincs az adott már megvásárolt és használt infrastruktúra termékre .NET támogatás. Ezt a vendor tudja implementálni, de hogy neki ez majd mikor éri meg, az kérdéses. Erre mondtam, hogy ez még szerintem évek kérdése. Erre a Microsoft tudna még esetleg hatni, ha megfizeti a kérdéses integráció lefejlesztését és/vagy certifikálását.
    Mutasd a teljes hozzászólást!
  • Úgyhogy jó eséllyel a Microsoftnak kell ebbe további igen komoly erőforrásokat tegyen, ha akar valamit

    A MS-nek nem kell mást tennie, mint átemelni a létező implemetációkat. Ahogy tette is - lásd asp.net MVC, entity framework, stb. Itt Pl. nem kell a communitynek hibernate-et fejleszteni (bár van nhibernate is), mert van EF.
    Mutasd a teljes hozzászólást!
  • A natív alatt itt .NET bájtkódot vagy C/C++/assembly kódot értel? Gondolom C/C++/assembly-t.

    Na ezek szerintem (.NET kódból gépi kód hívása) pont hogy VM implementáció függő dolgok, pláne ha esetleg a kernelre is rá kell hívni. Ha erőforrást kell kezelni, az megint kernelfüggő is lehet.
    Épp ezért nem feltétlenül nyilvánvaló hogy biztos megy.

    Természetesen C/C++/Assemblyt értettem natív alatt. Felteszem .NET-hez is van/lesz megoldás native kód hívására, ahogy Javaban is van. Ha megoldották, hogy fusson a VM linuxon, akkor az implementáció függő kernel hívásokon már túl vannak. De nem akarom ezt tovább ragozni, akinek szüksége van erre .NET-ben, majd utánamegy. 

    Ahogy már írtam korábban, abban egyetértünk, hogy a jelenleg Java platformra már eléggé ráépült közösség számára erősen kérdéses a motiváció, hogy felépítsék mégegyszer ugyanazt egy még csak most formálódó .NET alapra. Úgyhogy jó eséllyel a Microsoftnak kell ebbe további igen komoly erőforrásokat tegyen, ha akar valamit. Mire a .NET core beérik, addigra még komolyabb előnye lesz a Javanak ezen a területen is. Szerintem belátható időn belül max annyira fog tudni a .NET labdába rúgni ezeken a piacokon, mint a mobil eszközök piacán. Eléggé piackövető cég lettek a korábban piacot meghatározó cégből.
    Mutasd a teljes hozzászólást!
  • Mivel natív hívásokkal működik mind az UMS, mind a 2 említett TIBCO cucc, felteszem, hogy megy linuxon is. De nem próbáltam.

    A natív alatt itt .NET bájtkódot vagy C/C++/assembly kódot értel? Gondolom C/C++/assembly-t.

    Na ezek szerintem (.NET kódból gépi kód hívása) pont hogy VM implementáció függő dolgok, pláne ha esetleg a kernelre is rá kell hívni. Ha erőforrást kell kezelni, az megint kernelfüggő is lehet.
    Épp ezért nem feltétlenül nyilvánvaló hogy biztos megy.

    Gondolom amúgy pont a big data és machine learning témákból nem szeretne kimaradni a MS, mint ahogy megtette azt szinte minden mással az elmúlt tizenévben.

    Ez valószínű, de ettől még nem valószínű, hogy le fogja helyettűk más fejleszteni a megfelelő kódot .NET-re, aminek hatására nem csak Java alapú kód lehet majd egy Hadoop clusterben hanem .NET alapú is, többek között azért, mert ezt a különbséget meg is kellene tudni jeleníteni a cluster manager számára, hogy tudja, hogy Java kódot ne küldjön .NET cluster memberre és viszont.
    Mutasd a teljes hozzászólást!
  • Mivel natív hívásokkal működik mind az UMS, mind a 2 említett TIBCO cucc, felteszem, hogy megy linuxon is. De nem próbáltam.

    Biztos van valami megoldás Hadoophoz és hasonlókhoz is. Nem tudom, nem dolgozok .NET-tel egyáltalán. Gondolom amúgy pont a big data és machine learning témákból nem szeretne kimaradni a MS, mint ahogy megtette azt szinte minden mással az elmúlt tizenévben.
    Mutasd a teljes hozzászólást!
  • Az mondjuk pont van .NET-hez: UMS, TIBCO FTL, RV gyárilag rendelkezik .NET API-val, Aeron clientet is portolták már .NET-re, igaz ez 3rd party.

    És mindegyik megy Linuxon is .NET alatt? Az azért már nem ugyanaz mint .NET Windowson.

    És egyéb termékek clustering protokollokkal? Hadoop (nem kliens hanem a YARN cluster tagok pl.)?
    Mutasd a teljes hozzászólást!
  • Az mondjuk pont van .NET-hez: UMS, TIBCO FTL, RV gyárilag rendelkezik .NET API-val, Aeron clientet is portolták már .NET-re, igaz ez 3rd party.
    Mutasd a teljes hozzászólást!
  • Pontosan milyen technológiára gondolsz ?

    Pl. low-latency messaging termékekre... vagy bármire aminek saját kommunikációs protokollja van
    Mutasd a teljes hozzászólást!
  • Na akkor még 3-5 év, míg eljutnak arra a szintre, hogy interoperabilisek lesznek a meglévő enterprise technológiákkal Linuxon.

    Pontosan milyen technológiára gondolsz ?

    Igen, feltéve ha nem lesz deprecated és eltávolított a korábbi verziók egyetlen rész technológiája sem. Ehhez túlságosan is kéne bízni a Microsoftban hogy nem csinál olyat amit már többször megtett

    Azért a deprecated technológiák amik a .NET-ben vannak, a mai napig is támogatottak, csak ma már van jobb. A jó öreg windows.forms még a mai napig ott van a .NET-ben. Ahogy a jó öreg AWT is deprecated lett a javában, de elég jó úton halad a swing is.
    Mutasd a teljes hozzászólást!
  • Van support a támogatott verziókon, amelyek egyre bővülnek.

    Egyébként évtizedes múltú kódbázisról beszélünk, tehát nem arról van szó, hogy 0-ról írtak egy multiplatform .NET-et. Jelenleg azon dolgoznak, hogy nagyobb kompatibilitást nyújtson meglévő, kiforrott libekkel.

    Na akkor még 3-5 év, míg eljutnak arra a szintre, hogy interoperabilisek lesznek a meglévő enterprise technológiákkal Linuxon.

    Másik topicban ORM-ről volt diskurzus: EF Core készen kínál olyan feature-öket, amelyeket Java alapúakból hiányoltál. Bár ez 0-ról lett újraírva, hogy kiküszöböljön az eredeti EF felépítéséből adódó hiányosságokat (pl. NoSQL támogatás), így itt valóban szükséges némi előélet, hogy bizalmat kapjon.

    Igen, ez hasznos lenne, és valószínűleg fog adni egy lökést ahhoz, hogy el is terjedjen a .NET Linuxon. De önmagában emiatt még nem fognak váltani.

    Ez csak a runtime, a ráépülő programok elvileg binárisan kompatibilisek.

    Igen, feltéve ha nem lesz deprecated és eltávolított a korábbi verziók egyetlen rész technológiája sem. Ehhez túlságosan is kéne bízni a Microsoftban hogy nem csinál olyat amit már többször megtett.

    Valamint a kedvenc főnököm egyik mondása után szabadon: az eltérés az elvileg és a gyakorlatilag között kisebb elvileg mint gyakorlatilag.
    Mutasd a teljes hozzászólást!
  • Van support a támogatott verziókon, amelyek egyre bővülnek.

    Egyébként évtizedes múltú kódbázisról beszélünk, tehát nem arról van szó, hogy 0-ról írtak egy multiplatform .NET-et. Jelenleg azon dolgoznak, hogy nagyobb kompatibilitást nyújtson meglévő, kiforrott libekkel.

    Másik topicban ORM-ről volt diskurzus: EF Core készen kínál olyan feature-öket, amelyeket Java alapúakból hiányoltál. Bár ez 0-ról lett újraírva, hogy kiküszöböljön az eredeti EF felépítéséből adódó hiányosságokat (pl. NoSQL támogatás), így itt valóban szükséges némi előélet, hogy bizalmat kapjon.

    Persze, majd az idő eldönti.

    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.

    Ez csak a runtime, a ráépülő programok elvileg binárisan kompatibilisek. De úgy lett tervezve, hogy egy gépen egyszerre futhassanak különböző verziók, minden függőségükkel együtt terjesztve, pont, hogy ne okozzon gondot egy esetleges breaking change a framework-ben (ezt mondjuk nem teszteltem, de ez tervezési szempont volt, hogy elkerüljék a teljes .NET Framework-ön tapasztalt ilyen irányú problémákat, ahol csak egyféle verzió futhat pl. 4-esből). Emellett a runtime-hoz külön van LTS és gyors frissítésű ág.

    Bocsánat, nem offolni szerettem volna, csak elég gyakran olvasok pontatlan információkat erről itt is, és ha ráérek, próbálok a tényekre rávilágítani.
    Mutasd a teljes hozzászólást!
  • FYI: a .NET Core független a Windows-tól, pl. Linux/MySql-lel is futtathatod. Ingyenes, nyílt forrás, MIT license.

    Aha. Mióta is? Szerinted mennyire robusztus, mennyi tapasztalata van a világnak vele Linuxon? Ad rá valaki supportot Linuxon?
    Mutasd a teljes hozzászólást!
  • De ha egy Windows Server + .NET VM-el veted össze a Linux server + Java VM-et akkor mindjárt más a leányzó fekvése.

    Én nem mondtam, hogy ne szerződj supportra, csak azt, hogy árvizsgálat céljából a .NET VM-et külön vizsgálni a Windows-tól és azt összehasonlítani a Java VM-el nem egészen fair.

    FYI: a .NET Core független a Windows-tól, pl. Linux/MySql-lel is futtathatod. Ingyenes, nyílt forrás, MIT license.

    Ez a hozzászólás és a rá adott válaszok a moderátor által lett átmozgatva a(z) "Fizetni kell - bekeményít Java SE ügyben az Oracle" témából.
    Mutasd a teljes hozzászólást!
abcd