Mainsoft provozuje ASP.NET aplikace pod Javou

Mainsoft představil produkt, se kterým je možné používat aplikace ASP.NET na platformách, kde funguje Java EE (tedy i na Linuxu). Zdrojový kód Visual Basicu a C# je převáděn do bytecodu Javy. Výsledek je založen na spolupráci s projektem Mono. Více čtěte na LinuxWorld.

10.4.2008 16:57 | Luboš Doležel (Doli) | Zajímavý software

Komentáře

[Ilfirin]

Juch! Líbí se mi, že se .net portuje..

[freshmouse]

Zeptám se takhle: co z aplikací, které potřebují Mono, ty osobně používáš?

[Ilfirin]

Zatím žádné, ale v .netu vyvýjí kde kdo, včetně firmy, kde dělám. A možnost provozovat ony (firemní) aplikace pod Linuxem (a ne pod Vistama) se mi zamlouvá, nehledě na to, že je pak budem moc prodávat na newin strojích.

[freshmouse]

Windows používá kde kdo. Soubory *.wmv produkuje kde kdo. Atd.

Kdyby Mono mělo za následek to, že budou portovány "firemní" aplikace, tak prosím, nejsem proti. Bohužel jsou ale především "vyvýjeny" tzv. běžné aplikace, jako třeba prohlížeče obrázků nebo přehrávače muziky.

Mimochodem, má někdo přehled, kolik "firemních" aplikací je vyvíjeno pod .NET? (Můj tip je, že minimum.)

[Käyttäjä 11133]

A co ti na tom vadí? Že do mona investuje Novell? Nebo že tu technologii vytvořil Microsoft? Nebo co?

[freshmouse]

Než odpovím, zeptám se i tebe: jakou aplikaci potřebující Mono používáš ty?

[Käyttäjä 11133]

Žádnou. Ale stejně tak nepoužívám žádnou aplikaci, která by potřebovala Javu, Gnome,....

[freshmouse]

No, a jsme u toho. Já rád dám výkon procesoru nebo paměť na aplikace, které to využijí rozumně a hlavně s rozumným cílem.

Např. Tomboy přeskakuje mezi 3 a 15 MB. Šílenost.

Pokud bych byl firma, a nutně potřeboval něco, co potřebuje .NET, řeknu: dobrá, je to strategická aplikace, holt investujeme do HW. Ale čím je startegický Tomboy nebo F-Spot?

Sečteno, podtrženo: vynechám-li politické důvody, na Mono (příp. .NET) mi vadí výkon.

[Käyttäjä 11133]

No jasně a ze stejného důvodu ti rovnou může vadit všechno kromě ASM. Dobře, možná i nějaký FORTRAN, když se použije dobrý kompilátor.

[Ilfirin]

To je ale hodně špatný tip. Microsoft Visual Studio s .Net je čím dál více používané vývojové prostředí na Windows. Netroufám si říci, že je nejpoužívanější, ale jednou jistě bude.

Takže kolik? Všechny.

[freshmouse]

A podklady?

Určitě bude aplikací, co potřebují .NET, víc, pokud budeme .NET podporovat. Což ode mě nečekejte.

[Ilfirin]

Na vás to vůbec nezávisí. VS s .net umožňuje dělat multiplatformní (samozřejmě se bavíme o Windows ) aplikace. Umožňuje použít mnoho jazyků, od C# přes Javu až po Python. Má plno hotových věcí, jako je textový editor, export do OXML a další. Podklady.. rozhlížím se kolem sebe. Vývojová prostředí na Windows jsou Visual Studiem doslova válcovaná.

[Daniel Kvasnička ml.]

Mimochodem, má někdo přehled, kolik "firemních" aplikací je vyvíjeno pod .NET? (Můj tip je, že minimum.)

No konkretne ASP.NET se (bohuzel) tesi docela slusne popularite, tam uz se o minimu mluvit neda. Z exponovanejsich aplikaci me ted napada ale jen elektronicke bankovnictvi CSOB... ale bude toho mnohem vice.

[Karel]

To by ses pekne divil, kolik je toho v .NETu....

[Chocolate Bear]

Dotaz! Proč by převádět zdrojáky do bytecode Javy a nezkompilovat to mono c# kompilátorem a obejít se bez EE javy?

[Ilfirin]

Třeba proto, aby pak ona aplikace šla spustit všude? (všude, kde je java)

[Chocolate Bear]

Tak tady jde o servery a webové aplikace, ne? BTW já neříkám, že to není užitečné, ale ptám se na to, na co se ptám Teda když má někdo platformu podporovanou mono c# kompilátorem, jestli je nějaká výhoda, když to přesto bude mít v Javě.

[bubak]

Rychlost. Bytecode bezi v JRE temer stejne rychle jako C/C++ kod.

[Jary]

To je možné? Co je to to "téměř"? Jak je to možné?

[bubak]

10 let optimalizaci

[KS]

Tak ten bytecode se neinterpretuje, ale kompiluje pro procesor. A kdyz se zkompiluje dobre, tak proc by to nemohlo bezet rychle.

[aubi]

Tohle mě děsně baví -- to je totiž sen všech Gentooistů: mít soft kompilovaný přesně na hardware. Java jde ještě dál -- kompilace na hardware, ktery je k dispozici aktuálně a kompilace podle aktuálního způsobu využívání aplikace (dík rekompilaci).

Zdůrazňování, že se bytecode neinterpretuje, mi začíná připadat opravdu nudné. Naposledy se interpretoval v Javě 1.2, v 1.3 už byl hotspot (zapnutelnej)...

[Luboš Doležel (Doli)]

A co ten čas CPU strávený JIT kompilací?

[zoul]

To malé zpoždění při startu programu se většinou vrátí, jinak by ta technologie byla značně legrační :) Dokonce si člověk může vybrat, jestli se má JIT snažit hodně (java --server), nebo jestli to nemá cenu a ušetříme si čas (java --client).

[cronin]

A co ten čas CPU strávený JIT kompilací?

Ak aplikacia obsahuje kod, ktory sa opakovane vykonava viackrat a tento kod ma bezat dlhsie ako 30 sekund procesoroveho casu, tak sa cas straveny HotSpotom na optimalizaciu vrati (su to radovo sekundy, nie viac). Server-Side aplikacie zvycajne obsahuju kod, ktory sa opakovane vykonava, a tento casto spotrebovava nie sekundy, ale hodiny procesoroveho casu. Takze ak pouzijete -server -Xbatch pre takuto aplikaciu, bude jej start o 2-10 sekund pomalsi, ale vysledna vykonnost bude 10-40% lepsia. Ak inkriminovany program do tejto skupiny nespada, jedna sa o kratko beziaci jednoucelovy tool, stale mozete pouzit -client; jeho start je v sucasnych verziach JDK uz velmi rychly. Osobne pouzivam Javu aj na vedecke vypocty. Overhead HotSpot kompilacie/optimalizacie je cca 3-4 sekundy, uspora casu je radovo v hodinach.

Prednostou HotSpot optimalizacie je prave to, ze je dynamicka. Ano, nieco to stoji, ale tento overhead je zanedbatelny. Java dokaze optimalizaovat aj dynamicky viazane volania metod (t.j. v kode je interface/nadtrieda a pocas kompilacie nie je mozne vyhodnotit, ktora konkretna implementacia sa pouzije), a to dokonca aj v pripade, ze sa konkretna implementacia za behu programu meni. HotSpot dokaze za behu robit tzv. analyzu utekov (escape analysis) a ak je mozne urcit, ze synchronizovany blok sa nemoze dostat mimo scope daneho vlakna, odstrani synchronizacny overhead; to je tiez nieco, co staticky kompilator jednoducho nema sancu urobit.

Takze ano, Java a dynamicky interpretovane jazyky maju overhead voci staticky kompilovanym jazykom, ale tento overhead poskytuje prinosy, ktore ho daleho prevazia. IMHO je "pomalost javy" v sucasnej dobe uz len mytus, dany 1) rannymi verziami javy, ktore boli skutocne pomale, 2) pomalsim GUI, ktore je trochu pomalsie (ak je pomale vyrazne, je to pravdepodobne preto, ze je zle nakodovane, nie preto, ze "java je pomala"). V server-side aplikaciach, davkovom spracovani udajov, vedeckych vypoctoch a pod. je v sucasnosti Java velmi dobra volba.

[Luboš Doležel (Doli)]

Obavam se, ze je toho pomaleho vic nez jen GUI. Ale kdykoliv jsem popsal silenou pomalost Javy, tak mi nekdo rekl, ze uvadim spatne programy, ze tomu nerozumim, ze jsem zklamal (sic!) atd. Jenze ja ten rozdil mezi nativnim a javovym programem poznam pocitem i z grafu zateze CPU. GUI je line i se SWT, kde by to snad tolik hrozit nemelo.

[mj41]

No ja do toho nevidim, ale kdysi jsem narazil na clanek Fast interpretation. Podle mne na tom neco bude .

[zoul]

Knihovny?

[meap]

Dobré to může být například v případě, že firma má svou JEE aplikaci na nějakém aplikačním serveru a chce k ní přihodit další psanou např. v .NET. Výhod je hned několik. Shodná administrace na úrovni aplikačního serveru, výhody poskutující aplikační server, jeden stroj, jeden os apod. Aplikační server např. řeší spojení do db, takže pokud to mají až na této úrovni, příjde mi to jako docela dobré řešení.

[Peter Fodrek]

Je to barlicka oko obsmeknut EC nariadenie o zakaze MS v EU, ak prejde zakaz MS produktov v statenej sprave EU, na ktory dnes vyzvala nemecka poslankyna Europralamnetu za "zelenych" http://www.theinquirer.net/gb/inquirer/news/2008/04/10/member-eu-parliament-asks

MS sice nebude moct ist do tendrova ale bude mopct robit subdodavky rieseni

[Rezza]

Doprkynka jake zase zakazy MS! To nechapu ty komisare a europoslance...

[Luboš Doležel (Doli)]

Do USA jde hodně peněz, tak tomu chtějí bránit.

[Rezza]

Ale to je jen chyba Evropskych firem a hlavne socanske EU, ktera ty firmy proste skrti...

[Luboš Doležel (Doli)]

Ale to je jen chyba Evropskych firem

Takový dojem opravdu nemám. Stejně tak nemám dojem, že pády evropských firem spolu s nárůstem importu z Číny, jsou chybou evropských firem.

[Rezza]

Cinu neberu, to se neda srovnavat. Beru hitech firmy... Ale je pravda, ze vic nez ty zkostnatele firmy za to muze vic zkostnatela byrokracie...

[xm]

Je to jednoduché, dle zákonů/nařízení EU je to jeden z možných "trestů" pro firmy usvědčené z monopolistických praktik (a Microsoft usvědčený je, potvrdil to soud). Viz:

... candidates or tenderers shall be excluded from participation in procurement procedures if: (b) they have been convicted of an offence concerning their professional conduct by a judgment which has the force of res judicata; (c) they have been guilty of grave professional misconduct proven by any means which the contracting authority can justify;"

Takže by to bylo IMHO zcela legální a správné

[Peter Fodrek]

70% OSS vyvojarov je z EU tu

To je dovod, konania EC

navyse aj gro uzivatelov istych typov OSS je v EU tu

EU leje peniaze do OSS dlhodobejsie tu

a dokonca EU ma svoju licenciu typu OSS, pod ktorou sa musia licencovat vsteky SW v\yvynute s penazi EU. tu

[xm]

Což je všechno dle mého názoru jednoznačně dobře

[boris]

Tak toto podporujem, lebo ako sa ukazalo tak volny trh nic nevyriesil, ale prave posral ked vytvoril de facto monopol microsoftu v OS a Office a teraz je takmer nemozne sa vyhnut pouzivanie MS produktov. Keby vsetky tie EUR-a za licencie (ktore putuju do USA) dali europskym programatorom na vyvoj Linuxu a OpenOffice tak je to pre ekonomiku EU urcite lepsie ako len nakupit XXXX-licencii a poslat EUR-a zaocean. A ty co budu mat reci o tom ze EU nema co davat dotacie sukromnym firmam tak nech si skusia zistit ako to funguje v USA, kde su firmy tiez pekne dotovane cez rozne vojenske projekty atd. A urcite ste zaregistrovali co sa v USA strhlo ked armada ohlasila ze nakupi tankovacie lietadla od Airbusu a nie od Boeingu, tam to uz idu vysetrovat lebo nakup airbusov vytvori udajne od niekolko 10-tisic menej pracovnych miest.

[miso]

Z rovnakeho dovodu preco ine jazyky (napr. Python v projekte jython) kompiluju do java bytecode. Proste moznost pouzit dany jazyk na pridanie funkcionality k nejakej hotovej java aplikacii, pripadne pouzit v danom jazyku java kniznice

[Daniel Kvasnička ml.]

Protoze EE java je kralem ve F/OSS svete velkych server side aplikaci a protoze pro Javu jsou knihovny snad na vsechno. Open source serverove technologie zalozene na C# pouziva snad jen par nadsencu... (zatim).