Jag försöker vidga mina kunskapsvyer en aning. Jag tycker att .NET kan lösa de flesta problem på ett tillräckligt bra sätt. Sedan finns det säkerligen undantag men plattformen som sådan har bra stöd för lösning av kunders problem. Det som jag funderar över är om det finns något problem som Java löser betydligt bättre än .NET vilket i sin tur gör att man bör välja en Java-lösning. Kan någon komma på ett sådant problem?

Det första jag kom att tänka på är att du kan köra Java-applikationer på betydligt fler platformar än .NET.

/Johan

Skit i Java. Kolla på helt andra typer av språk istället; lisp, Haskell, F#, prolog, ml, erlang.

Hej
precis som de skrivit tidigare så är Java plattformsoberoende
Kanske inte till alla plattformar i hela världen men tillräckligt många.

Några saker till
Man kan bundla JRE med java och då få ett komplett paket som man sedan kan ladda ner från nätet eller använda java webstart för att köra direkt

Med javaFX (som inte är riktigt java men ändå java :-) ) så kan man lägga in applikationen i websidor men sedan dra ut dem till skrivbordet med dragendrop.

Personligen tyckte jag att javas FC har ett bättre upplägg än motsvarande i .net miljön, har du fattat hur JPanel funkar så fattar du rätt snabbt hur en JButton funkar osv..
Riktigt samma aha upplevelse får jag inte i .net. Där kan samma saker göras på flera olika sätt, ta SQL connection som exempel, fan vad man har svårt för i .net miljön att lösa problemet på ett likartat sätt.
I java FC finns det en röd tråd som kallas objektorienterad programmering och den finns säkert i .net miljön men är så mycket svårare att se.

Ett exepmel där jag ser Java användas varje dag är i konfigurering av utrustning så som routrar/switchar/servrar etc. Både Cisco/Fujitsu å andra leverantörer antar jag tänker som sådant att de gör en applikation, för att hantera deras utrustning, och genom att då göra det i Java så slipper man ha koll på om användaren använder Unix/Linux/Windows/Mac.

/Markus

> Personligen tyckte jag att javas FC har ett bättre upplägg än motsvarande i .net miljön, har du fattat hur JPanel funkar så fattar du rätt snabbt hur en JButton funkar osv..

Hm, här hänger jag inte riktigt med på vad du menar. Jag upplever inte .NETs kontroller som särskilt magiska av sig.

> Där kan samma saker göras på flera olika sätt, ta SQL connection som exempel, fan vad man har svårt för i .net miljön att lösa problemet på ett likartat sätt.

Här hänger jag inte heller riktigt med på vad du menar, det finns lite olika möjligheter att ansluta till en databas, generiska eller specialiserade, allt beroende på omständigheter och prestanda. Det är dock samma api och implementerar samma interface.

> I java FC finns det en röd tråd som kallas objektorienterad programmering och den finns säkert i .net miljön men är så mycket svårare att se.

Hela .NET bygger på OOP, så det man får anstränga sig för att missa det

Hej
Nu ville kanske inte den som skapade denna tråd att det skulle bli en debatt om det ena eller det andra språkets fördelar :-) vilket det som vanligt blir.

Men det jag försökte säga egentligen var att jag tycker att JFC är betydligt enklare uppbyggt.
Varje objekt ärver tydligt från någon annan ovanstående klass och man kan tydligt (tack vare dokumentationens upplägg) se hur allt hänger ihop ;-)
Min högst personilga åsikt att den bilden är svårare att se i .Net miljön.

"Hela .NET bygger på OOP, så det man får anstränga sig för att missa det"
Japp helt riktigt, men när man i bland skall skapa nya objekt av vissa typer så skapas de inte av sorten

MinKlass minKlass = new MinKlass();

Jag har stött på vid flera tillfällen att man i .Net miljö vill göra så här i stället

MinKlass minKlass = MinKlass.Create();

Men i bland så gör man på det första sättet, det skapar inte en homogen utvecklingsprincip.

Vi kan säkert fylla ett helt forum om varför osv. man gör si och så men det är en skillnad i hur man har tänkt i .net miljön gentemot java miljön. Och jag upplever det som att Javas röda tråd var enklare att lära sig än den i .net.


Så på frågan vad är det som gör Java bättre än .net
Jag vet faktist inte, det finns en massa nackdelar med Java, som jag inte ens skall försöka gå in på.
Men det java är bra på är att, om man vill göra en liten applikation mot en specifik lösning där man inte vet vad klienten kommer att köra för operativ annat än att det kan vara något annat än MS Windows
Tja då är Java ett startkt alternativ för det passar väldigt bra i en sådan miljö

/Markus

> Nu ville kanske inte den som skapade denna tråd att det skulle bli en debatt om det ena eller det andra språkets fördelar :-) vilket det som vanligt blir.

Jag är inte intresserad av en debatt, jag tänker inte ta ställning för varken .NET eller java (de har olika fördelar, själv knackar jag iofs ingen java-kod, men..), däremot är jag intresserad av att korrekt fakta förs fram.

> Men det jag försökte säga egentligen var att jag tycker att JFC är betydligt enklare uppbyggt.
> Varje objekt ärver tydligt från någon annan ovanstående klass och man kan tydligt (tack vare dokumentationens upplägg) se hur allt hänger ihop ;-)

Det du beskriver skulle kunna vara .NET Framework.. Jag kan ju säga att min personliga åsikt är tvärtom, vet iofs inte om dokumentationen till Javas framework har utvecklats sen 2005, men då (när jag knackade java-kod) blev jag less på att jag inte lyckades hitta något vettigt i javas dokumentation.

> Min högst personilga åsikt att den bilden är svårare att se i .Net miljön.

Som sagt, vi har nog olika åsikter, troligtvis färgade av att vi är hemmablinda och vana att navigera i ett visst dokumentationssystem. Jag ögnade precis igenom java:s dokumentation, och jag kan inte påstå att jag ser någonting där som jag saknar i .NETs dokumentation, eller tvärtom.


> Japp helt riktigt, men när man i bland skall skapa nya objekt av vissa typer så skapas de inte av sorten
> MinKlass minKlass = new MinKlass();
>
> Jag har stött på vid flera tillfällen att man i .Net miljö vill göra så här i stället
> MinKlass minKlass = MinKlass.Create();
>
> Men i bland så gör man på det första sättet, det skapar inte en homogen utvecklingsprincip.

Det där har inget direkt att göra med .NET, snarare att man nog inte skapa kunna skapa de klasserna utan vidare. Nu vet jag inte exakt vad du syftar på, men t.ex. System.Net.WebRequest har ingen publik konstruktor utan där måste man anropa en statisk .Create(). Där finns det dock en anledning: klassen System.Net.WebRequest är en abstrakt klass, och beroende på typ av URI så kommer .Create() returnera objekt av olika subklasser, t.ex. kommer http:// resp. https:// returnera ett objekt av typen HttpWebRequest. Gissningsvis finns liknande konstruktioner i java där man inte har publika konstruktorer utan måste gå via någon metod någonstans.

(Personligen ser jag inget problem med att göra såhär, även om man bör tänka efter före)

För det första kanske man ska skilja på språk och framework? Vad gäller språket så har iaf inte jag upptäckt några större skillnader, båda är mycket kompetenta. Frameworken kan jag egentligen inte jämföra, då jag mest kodat java i embedded-miljö. Men jag får intrycket att Java ligger före på en hel del områden, flera av dom riktigt användabara frameworken i .net är ju Java-portningar (NHibernate mfl). Kan ingenting om J2EE, men det är väl ganska omfattande?

Att .NET Framework inte är helt konsekvent uppbyggt håller jag helt med om. Dels har man ändrat konventioner mellan versionerna, utan att uppdatera befintliga klasser, dels är en del klasser ganska tunna wrappers runt Windows-API'er...

> För det första kanske man ska skilja på språk och framework? Vad gäller språket så har iaf inte jag upptäckt några större skillnader, båda är mycket kompetenta. Frameworken kan jag egentligen inte jämföra, då jag mest kodat java i embedded-miljö. Men jag får intrycket att Java ligger före på en hel del områden, flera av dom riktigt användabara frameworken i .net är ju Java-portningar (NHibernate mfl). Kan ingenting om J2EE, men det är väl ganska omfattande?

Ska man bara titta på java som språk så saknar jag nog tre saker tror jag:
1) Delegater
2) Automatisk boxning av värdetyper (man måste själva sitta och wrappa värdetyper om de ska någonstans där bara referensetyper accepteras)
3) Det går inte att skicka byref

Alla de sakerna är lite partykilllers för mig.. :/

> Att .NET Framework inte är helt konsekvent uppbyggt håller jag helt med om. Dels har man ändrat konventioner mellan versionerna, utan att uppdatera befintliga klasser, dels är en del klasser ganska tunna wrappers runt Windows-API'er...

Det kan jag också hålla med om, men jag tror inte java är mycket bättre, så det är nog hugget som stucket