Java versus .NET

az sym za .NET

Znachi kato biahme detza na po 5-6 godini taka se draznehme. Ediniat kazva "da", drugiat "ne" i na koito pryv mu pisne...
Tazi vyzrast odavna ia nadrastnah, ta ne moga da se vkliucha...

Ами кво да ти кажа... Ако искаш да кажеш, че Жава ще умре, грешиш. Още по-малко пък това ще стане с НЕТ. Както си съжителстваха досега МС с Жава технологиите, че и опенсорсове като ПХП и Перл за веб специално, така и ще си остане най-вероятно. Аз НЕТ-а не съм го цъкал още, затова не мога да кажа кое е по-добро. Ама принципно тоя спор е безсмислен. Тука сме клуб за Жава, така че се предполага, че можем да пишем на Жава. Е, аз доста плюя понякога по езика и реализацията, но що се отнася до веб, жава и свързаните с него технологии засега са ми по-удобни. Тва е.

There`s a killer on the road...

pi6a i na 2-te


J2EE ima predimstva
.NET Susto

Az predpo4itam J2EE

C++ - waste of time for web development

Predlagam da napravim njakakvo sravnenie na dvete tehnologii. Da se abstrahirame ot nesta kato : "Java e velika, M$ da go .....". Mislja, che e vyzmojno da stane dosta dobra obektiva diskusija ( moje bi ).

E da, taka po-stava. Ama kato ti vidiah pyrvia posting tochno mi zaprilicha na pokana za bezmisleno nadvikvane :)))
Rabotata mi krai .NET e predimno na C# ta nego gore-dolu moga da go sravnia v java-ta (koiato mi e slabost ).
Ama kak da ne se iadosa chovek? Kato otvorish C# Inside na MS Press i oshte na pyrvite niakolko stranici pochvat da ti govoriat kakvi genialni novovyvedenia sa napravili. Naprimer - avtomatichno upravlenie na pammeta! Ami tova "novovyvedenie" vsichki znaem ot koga e v Java-ta, nali (viziram Garbage collector-a)?
Plus tova, kazvaha i neshto ot sorta, che povecheto ezici, koito niamat vgradena poddryjka mejdu ezika i framework-a bili nepriatni za rabota, zashtoto ako iskash da inc-nesh edna stoinost na obekt triabva da pishesh neshto ot roda na: object.setValue(object.getValue() + 1)
Dokato vij, tuka pri tiah se pravelo samo object.Value++
E, bravo! Super! Vyrhyt napravo! Ostana niakoi da im izchete i edin kratyk kurs po OOP i moje i da napraviat neshto sviastno.
Abe vyobshte, cialoto C# si e jiva krajba 1 kym na 1 na Java-ta. To oshte kato im vidish prikazkite za MSIL i ti stava iasno.
E, ne che si niama i predimstva - niama da si krivia dushata. Primerno dosta vreme spestiava boxing/unboxing konzepciata. Drug vapros e, dali tova e pravilno ot gledna tochka na semantikata na OOP. No shtom vodi do po-efektivna rabota, predpolagam ne e losho.
Moje bi sym malko pristrasten spriamo Java, no tia si mi e liubimka. Ama v kraina smetka, kakvo znachenie ima koe e po-dobroto? Za kakvoto ni plashtat, na tova shte pishem

Haide sys zdrave!

Hi,
Na men slabost mi e C++. No da vidim osnovnoto razlichie mejdu .NET i Java :
.NET - mnogo ezici, edna platforma.
Java - edin ezik, mnogo platformi.
Kato se ima predvid predishnija "opit" za komponentnost i ezikova nezavisimost, taka narechenija COM, to .NET e dosta goljamo razvitie. Kolkoto do platformenata nezavisimost na .NET, na men mi zvuchi kato kijorfishek. MS njamat izgoda ot mejduplatformennosta na .NET, vse pak te pecheljat ot Windows .
I az bjah chel v edna kniga, che C# prevyzhozda Java zastoto ima boxing\unboxing, koeto e smeshno. Prosto knigite na MS Press sa edna ideja propagandni, no ima i mnogo cenni nesta ot avtori kato Jeffry Richter.
Che C# dosta si prilicha s Java ( ima daje i J# ) sym syglasen, no kazi kakvo trjabvashe da napravjat za da ne si prilichat? Da ostavjat destruktorite, koito se smjatat za ostarjalo nesto? Ili da izmisljat nesto radikalno novo za da ne gi obvinjat, che kradat. Ima i drugo vse pak v C# ima malko poveche nesta ostanali ot C++ otkolkoto Java, koeto pravi C# malko po-udoben ot sintaktichna gledna tochka. A ako tova pravi koda mi po-chetim mnogo dobre.
Rezultata e, che po-dobro njama. Imat razlichija i priliki, vseki ima predpochitanija. Na men mi e lybopitno zasto?

Zdravei,
Na ritorichnia ti vapros kakvo bi triabvalo da napraviat MS moiat otgovor e : Da si biaha spazili sporazumenieto sys Sun, vmesto da se sydiat
Sega - seriozno.
Niamam nishto protiv .NET kato ideia. Eto naprimer predi 6-7 meseca triabvashe da napisha export kym MS Word ot edno Java prilojenie. Az se opitah da obiasnia na proektantite da postypiat s tazi ideia kakto s Diavolskata kreditna karta ot "Donesete mi glavata na princa" (ako ne si go chel - tia triabvashe da byde zavriana na tymno, vlajno i mrysno miato, che da raboti ), ama nali klienta si e klient... E, ne che ne go napisahme, ama prez cialoto vreme si mechtaeh za VBA, kydeto shteshe da stane s 5 reda.
Eto ti obache i edin kontraprimer. Skoro se zaformi s kolegite edin spor za byrzoto sravniavane na obekti v Java (detailite ne sa vajni). V kraina smetka se zabihme v source-ovete na JDK-to i vidiahme kak go praviat samite razrabotchici na Javata. E, ne e chudno, che obojavam open source konzepziata, nali?
Vtoroto, koeto iskam da kaja e che gore-dolu i J2EE i .NET pokrivat shirok perimetyr ot zadachi za reshavane, obache kakvo mi triabva za da pisha na Java? Edin Linux, koito moga da si svalia free ot net-a, NetBeans ili neshto drugo podobno za sreda (koeto syshto e free), JDK + pylni dokumentazii (pak free) i gotovo!
A ako resha da razrabotvam pod .NET samo razhodite za edin legalen Windows prevyzhojdat mnogokratno tova, koeto mi e nujno za da razrabotvam na Java.
Za support - da ne govorim! Nikoga, ama nikoga ne e imalo neshto, koeto da ne moga da vidia v API-ta, tutorial-i ili forumi na java.sun.com. Predpolagam znaesh kakyv e syotvetnia support na MS, nali? Edinstvenia po-gnusen ot nego, koito sym vijdal beshe na IBM za SanFrancisco, ama i to ne ocelia dostatychno dylgo (zashto li?)
A za knigite ot MS Press - no comment. No to ne sa vinovni avtorite (v goliama chast ot sluchaite). Imam poznati po izdatelstvata i znam kakvi hora gi prevejdat na BG - prosto otvrat! Razni nevzrachni filolojki, koito ako neshto ne razbirat rejat celia absatz. Edinstvenata kniga ot MS Press, koiato beshe prevedena s konsultant e Building and administering... (seshtash se t MCSE track-a).
Drugiat moment e, che kato cheta kniga na MS sled 100-200 stranici pochvam da zashtitavam MS tehnologiite i mi triabvat posle 2-3 dni da mi mine
. Shte kaje chovek, che osven pisateli i shtatni psiholozi pomagat! Ama naistina byka ot hvalbi i izhvyrlianizi. E, ne vsichki est. - na Kruglinski za MFC-to beshe mnogo iaka.
Ia da spiram da pisha, che mai mnogo se otplesnah


S nai-dobri pojelania,
Dao Shou

Нека да разгледаме нещата различно. Защото някой хора бъркат технология с език за програмиране и обратно.

Значи Java vs. C#
Нито Sun, нито MS откриват топлата вода. Garbage collectora го има доста отдавна и не е нова идея. Да вземем VB или Делфи или Perl. Там кой освобождава паметта. Не съм забелявал програмистите да го правят. Така, че там си има gc. И това не е нова идея. :-)

Идеята за Виртуална Машина. Да кажем, че в сегашния си вариант е на Sun. Но да кажем езика Perl е интерпретатор и той работи на много платформи. Значи има пак нещо, което осъществява анализ на кода и друго дето е системно зависимо и осъществява интерпретацията. Само, че нещата са омесени в едно. Понеже Perl е продукт с отворен код, там няма проблеми да се разпространява кода. Идеята за Виртуална Машина съществува също във VB (Visual Basic). Някой дето се е занимавал с него знае, че там може да се компилира до P код. И после това exe за да се изпълни трябва един "vb.dll". Sun отиват един ход напред дори пред VB на MS и правят виртуалната машина да работи на различни платформи.

Както виждате до тука нищо ново, никой не е измислип.

Как работи една ВМ (Виртуална Машина). В общия случай ВМ на Java мина през всички етапи. В първата си версия си беше чист интерпретатор. Интерпретираше байт кода (на .class файла). После дойде JIT (Just In Time) компилатор. Т.е. байт кода се компилира до машинно зависим код и после се изпълнява. В този случай се достига бързина на изпълнение почти като на native приложенията. Само, дето има един проблем. Доста време се губи докато се компилира байт кода до машинен код. И пак става бавно. Дори по-бързо става ако кода се интерпретира а не да се компилира и после да се изпълнява. След това от Sun измислиха HotSpot ВМ. Това вече може да се смята за тяхно нововъведение. Значи идеята на HotSpot е да се локализират местата, които се изпълняват най-често и на тези места да се прилага JIT а на местата, където се изпълняват най-малко да се прилага интерпретиране. Т.е. HotSpot е смесица между JIT и интерпретатор и се пуска едно като се прави опит да се предвиди, кое ще е по-бързо. Сега java-та има опция -server която пуска ВМ като JIT и се препоръчва за сървъри. Иначе по подразбиране си тръгва като HotSpot ВМ.

Май MS я докараха до JIT само, тях ги домърза да правят HotSpot. :-)

Друга разлика между ВМ, тази по скоро е на ниво компилатор.
MS вкарват още един слой в компилатора и това е анализатор на езика. Т.е. можеш да не ползваш С# а примерно синтаксис на Basic, Perl, Pascal и разни други такива. Също не е нова идея. MS го имат това във IE-то където можеш да пишеш скриптове на VB или JavaScript. Ама не можаха да наложат VB-то и всички ползват JavaScript. :-))

Друга разлика на ниво ВМ е сигурността. В Java има един файл където описваш правата на ВМ. Това го няма в С#. Сега пък MS и security. Аз май много искам. :-) Това до сега не съм видял някой да го ползва под Win, но под Unix (Linux) има смисъл.

Като API-та Java-та е доста напред. Тепърва C# има да догонва.



Сега да видим и технологиите .NET или J2EE.

Идеята е да се направи Distributet Computing. Тази идея е толкова стара и през толкова реализации мина, че не знам дали ще мога да ги изброя. :-)

Първо беше RPC (Remote Procedure Call) да викаш една процедура от друг компютър. Да и пращаш данните и тя да ти връща отговора. Това вървеше разбира се на *nix платформи. :-)

После големите играчи направиха CORBA, MS бяха в групата разработваща CORBA ама се отцепиха и направиха COM, DCOM и COM+. Идеята е да имаш обек и да му викаш методите от друг компютър. CORBA е независима от ОС-а и езика. Има някъв протокол, който върви по TCP и така. Не знам по какви проблеми но не се наложи. Тъкмо в това време Java-та набираше скорост и Sun изкараха RMI (Remote Method Invocation). Същата идея, само дето е фиксирано до един език. Пак след това Sun изкараха EJB същата идея в общия случай. Само дето вкарваше малко стандартни и лесни методи за писане на обекта на сървъра и клиента на другия компютър. Отново същата идея но фискирана пак само до Java.

MS някъде преди това са измислили SOAP (Simple Object Access Protocol) но го заразвят. IBM го доразвива и сега този протокол е фрее. И цялата .NET технология се крепи на SOAP.

Основните разлики са следните:
1. Работи по HTTP(S) протокола. Т.е. минава през всички proxy-та и така нататък. Аз в момента съм зад едно яко proxy и само HTTP връзки мога да правя. EJB-то минава по TCP.
2. Използва XML за описание на структурата си. EJB-то е в двоичен формат.
3. EJB то може да поддържа сесия. Т.е. имаш един обект инциализираш го и си му викаш методи и той си пази сесията. Докато SOAP няма сесия. Той е като RPC. Засилваш данните, сървъра ги обработва и после ти връща резултат, и край връзката се разпада.
4. EJB-то е работи само с Java. SOAP-а не зависи от езика. Сървъра може да бъде на един език. Клиента на друг. Те изпозлват XML over HTTP. Естествено никой не пише или не парсва XML на ръка. Има си разни инструменти и библиотеки дето вършат това за програмиста, както при EJB-тата.

Те това е за Distributet Computing




После има така наречените WWW технологии.

ASP vs JSP, Servleti
ASP + COM vs JSP + Java Beans.

За тях ме мързи да пиша. :-)



В общия случай и двете технологии са доста близки. Има основни разлики в EJB-то и SOAP-а.

Пък, който иска да ползва Java + SOAP да си дръпне има един фрее модул от Apache и е готов. Освен това на IBM WebSpehere Development Studio ги има и повечето технологии на куп EJB, SOAP, JSP, Servleti, CORBA ... и много други. Само дето не можеш да ползваш С#. :-)

Аз мисля да оставам на Java и ако трябва да ползвам SOAP със Java да ползвам нещо фрее. Както правя до сега за JSP и Servlet-и. Щото както някой каза трябва да дадеш майка си и баща си за да купиш софтуер за MS платформа пък и MS IIS като сървър постоянно спада. Според последното прочуване на неткрафт за сървърите MS IIS са на 25% от машините. На по-предното прочуване са били 32%. Добър спад от 7%, който е зает от Апаче-то. :-) Ако така продължават с тези тъпи лицензионни политики никой няма да купува MS бозите след някоя и друга година. Някой компании взеха вече да заместват даже и десктопите си с Линукс.


Ако някой пише, да ползва кирилица, иначе изобщо не чета. Боли ме главата като трябва да прочета нещо дълго на латиница.

Мммм. Много яка лекцийка дръпна. С удоволствие я изчетох.
Иначе си прав, че GC-то е стара идея. Специално в Perl мисля че беше комбинация от refernce count и GC, но може и насилствено да си освобождаваш променливите... Както и да е, това не е важно. Значи по начало, ако не ме лъже паммета GC-то е идея на МакКарти и му е хрумнала някъде към 1958-59-а година, като е измислял LISP-a (то там май за първи път е и въведена тази система).
И едно уточнение само. EJB-то не работи само с Java. Може да си го ползваш и през Delphi (AppServer etc.) чрез Simple IDL... Абе мързи ме да пиша повече и от теб, само това исках да кажа

Поздрави,
Dao Shou

не че искам да се заяждам ама доста грешни неща си написал.

Определено не разбираш какво е RMI и EJB (hint и двете са различни технологии, ползват се за различни неща и нито едното от тях не зависи от другото). Това е все едно да сравняваш FTP с Oracle DB.

> EJB-то е в двоичен формат.

е сигурно JavaBeans е било текстов формат ама са решили да го оптимизират за Enterprise-a

"EJB was originally designed around remote invocation using the Java Remote Method Invocation (RMI) mechanism, and later extended to support to standard CORBA transport for these calls using RMI/IIOP. "

EJB 2.0 Specification

Мда... Какво ли им е общото?

Hint: И аз не се заяждам. Само искам въпросът да е изяснен.

ок, като ще изясняваме въпроса, обясни какво е "същата идея в общия случай." :)

> Тъкмо в това време Java-та набираше скорост и Sun изкараха RMI (Remote
> Method Invocation). Същата идея, само дето е фиксирано до един език.
> Пак след това Sun изкараха EJB същата идея в общия случай.

Ми той човека си го е написал много ясно, ама ти май се заяждаш от чисто спортна злоба.

RMI и EJB като основна идея изобщо не са "различни технологии" и поне в 80% от случаите се използват за едно и също.

Приликата между JavaBeans i EJB е единствено в думата "Beans" (btw, и от Sun така казват, ама ме мързи сега да ти търся цитата)

Към "NeverMind":
Браво! Наистина беше удоволствие да чета постинга. Това е едно от най-добрите сравнения м/у Java и .NET

---
In God we Trust (all others must submit a X.509 certificate)

Ами като видях репликата, че двете технологии не зависят една от друга нямаше как да не реагирам
Сега като преглеждам пак написаното от NeverMind обърнах внимание на нещо друго. Например, че EJB-то "минава по TCP", а SOAP-а по HTTP. Технически погледнато, HTTP-то е над TCP и практически и то минава по TCP (гледайки на по-ниско ниво). Но това вече са дреболии.
Важното е, че EJB-то без проблеми работи по HTTP, че и по други авторски протоколи (например T3 на WebLogic-a).
Въобще, работата е доста наплетена. Аз даже писах едно време цяло описание на EJB технологията за вътрешнофирмено ползване и въпреки че обяснявах на 2 на 3, пак стана към 40 страници
Но струва ми се, че с всички тези коментари изместихме темата. Нали уж беше за J2EE и .Net? А пак изпаднахме в терминологични дрязги

Въпреки, че ползваме EJB дори и в този проект, в който съм сега си нямах и понятие, че EJB-то може да минава по HTTP, че може да се свързваш към EJB от Delphi и други такива неща. Явно се ползват много малко и стандартната конфигурация е да се връзваш с JSP към EJB и да е най-много на съседния компютър в интранет-а на фирмата.

А за протоколите исках да кажа, че SOAP-а върви навсякъде. След като много фирмени мрежи имат солидни firewall-и и proxy-та да направиш връка навънка е възможно само по HTTP(S). Аз в момента също съм зад много рестриктивно прокси. Само HTTP(S) и FTP download (без upload). И в този смисъл исках да кажа, че SOAP-а ще върви нявсякъде съобразявайки се с вече изградената структура и рестриктивни правила за достъп до интернет.

съвсем накратко (неформално).

RMI е протокол (за извикване на методи на отдалечен обект).

EJB е стандарт за persistent обекти (да кажем че освен това осигурява и транзакционно поведение).

RMI се е ползвало и ще се ползва без EJB. EJB-та също можеш да викаш по Corba ако искаш (въпреки че RMI определено е най-добрия избор за Java-to Java системи).

Просто искам да покажа че в оригиналната статия "куцат" някои неща.


> Това е едно от най-добрите сравнения м/у Java и .NET

Java е език за програмиране. .NET е "платформа". за какво сравнение изобщмо може да става дума ? (може би искате да сравнявате J2EE i .NET ?)

> А за протоколите исках да кажа, че SOAP-а върви навсякъде.

RMI поддържа HTTP tunneling от самото начало. Не виждам какво повече може да се иска :) (правенето на callback ще е еднакво трудно и в двата варианта)


Лично аз имам нещо друго против това да прекарваш всичко през HTTP.

Познайте за какво се използват firewall-s ? За да може да се регулира достъпа до различни услуги (тоест до една машина да позволиш само web access i SSH access само от няколко фиксирани IP-ta). И работата на системните администратори е да регулират достъпа на различни хора до различни услуги.

И какво точно прави SOAP в тоя случай ? Една ГОЛЯМА ДУПКА в цялата вече изградена и регулирана структура. Мечтата на всеки системен администратор.

Да пращаш XML върху HTTP не е нищо повече от това да пращаш XML върху HTTP. Не е панацея. Не е ясно какъв точно "проблем' решава. И ако не си наясно какво и защо правиш, може да ти донесе повече неприятности от колкот ползи.

divan (devil's advocate :)

:-))
tova e edna druga tema. otkakto se poiavi praktikata da se zabraniavat vsichki protokoli osven HTTP, neshtata se "izmestiha" s edno nivo "nagore" :-)
edin vid sega vsichki protokoli se kateriat v/u HTTP, dokato predi go praveha v/u TCP. dosta bezsmisleno spored men, osobeno sled HTTP 1.1 (makar che povecheto firewalls ne go poddyrzhat napylno imenno zaradi tova predpolagam). sega firewall-ite triabva da slediat i content-a... abe goliama divotia stana s tova security.
v krajna smetka ako imash covek otvytre (kakto se hack-va v 99% ot sluchaite) nishto ne mozhe da te spasi

Fear is the path to the dark side...

are begai togava v .NET foruma ili si nameri zanimanie

karam zaika zashtoto moga!