Er java et tregt språk?

[doloop]

Silverlight har også lite med java å gjøre, det er heller et forsøk på å angripe flash, samt kanskje gi en fremtidig plattform for mobilapplikasjoner.

 

Jeg ville heller si javaFX var et forsøk fra Sun sin side å angripe Microsoft og Adobe enn at silverlight var et angrep på Java.

 

 

.Net var uten tvil et angrep på java, silverlight var ikke det i hovedsak (selfølgelig, alle nye verktøy til en plattform gjør den mer attraktiv, men det var nok ikke tanken "NÅ SKAL VI TA SUN" som lå bak planleggingen av silverlight).

[Del]

Nei java er ikke database språket, ikke vet jeg hva dette har med diskusjonen å gjøre heller.

Bruksområder ble lagt som premiss for diskusjonen hvor både du og quantum kom med ganske kategoriske påstander etter det jeg kan huske.

Hvilken IBM server støtter ikke java? Java ligger som et lag oppå operativsystemet, du finner java støtte på alle store operativsystemer.

Den jeg nettopp ga deg lenke til Einstein. Dessverre er jeg så lei av å gjenta meg selv at jeg blir mindre høflig for hver post. Beklager det.

 

Les hva IBM selv skriver om dette:

TPF continues to service assembler find/file programs as not only will some existing code be with us ten years from now, but in many cases where path length is absolutely critical, there is nothing more efficient. TPF also supports C, C++ and will support Java and a high end model of their associated environments. Will a TPF Java program be as efficient as an assembler program or even C? Of course not, but consider that in many installations today, less than 20% of the software accounts for 80% or more of the execution path length. That leaves a lot of software that can be brought to market quickly without exposing the system to performance problems.

ref. http://www-01.ibm.com/software/htp/tpf/pages/Ztpfoverview.htm

 

Forøvrig er all annen diskusjon om treghet eller hva annet det skal være det reneste tullball når man tar utgangspunkt i premisser uten rot i virkeligheten.

 

Angående Silverlight, har du ennå ikke fått med deg at det nå er plattformen for applikajsonsutvikling på windows phone? Skal jeg gjenta dette og at Android bruker fortrinnsvis Java for deg igjen? Tror du fortsatt det bare handler om servere? Hvorfor tror du Unix er i ferd med å avgå med døden?

[doloop]

Databaser:

Jeg har siden første stund sagt at java ikke kjører på de store databasene i dag, jeg ga deg dog et par eksempler på databaser som kjører java for å vise at det er mulig.

 

Om IBM og java:

Hva var det med lagdelingen

 

Java

Os

Hardware

 

du ikke skjønte?

 

Silverlight

bla bla bla jeg har rett så det så

 

Android

Fakta:

• Android kjører ikke java runtime
  
• Android kjører ikke java byte code
  
• Android kan kodes med feks c/c++ via NDK
  
• Android er google
  

 

• Android gir deg en god del av java bibliotekene
  
• Android kan oversette Java kode til Dalvik kode og kjøre det(såfremt du ikke bruker biblioteker som ikke er tilgjengelig på android)
  
• De fleste koder i Java for så å oversette koden til Dalvik(gjøres gjerne automatisk av IDE)
  

 

J2mee

Du har forsåvidt rett i at det er et angrep på j2me, men dette er en plattform jeg ser på som omtrent død i dag, og ikke på grunn av silverlight. Det er sikkert fortsatt en del som utvikler mot nokia etc fortsatt, men silverlight er ikke et angrep på ikke smart phone segmentet.

 

Forøvrig er all annen diskusjon om treghet eller hva annet det skal være det reneste tullball når man tar utgangspunkt i premisser uten rot i virkeligheten.

 

Det er vel strengt tatt du som setter opp ytelsespørsmålet til å dreie seg 1 kb med kode for å flytte bytes fra a til b. Jeg diskuterer reell ytelse i et stort program, ikke kode som kan spesialsys i assembly etc. Det området som java faktisk lever i. Det er du ikke vi som prøver på dra diskusjonen over på områder som gjelder kanskje 1 promille av kode som er i et prosjekt. Om du skal skrive kode osm skal flytte bytes fra a til b og ingen ting annet, ja da er sikker assembly det smarte. Go for it.

[doloop]

Jeg vil legge til det er selvsagt flott at android støtter java så mye som den gjør =)

 

god natt

[Del]

Om IBM og java:

Hva var det med lagdelingen

 

Java

Os

Hardware

 

du ikke skjønte?

IBM sine stormaskiner kjører Power prosessor, en arkitektur som trenger eget rammeverk for å kunne kjøre Java. Transaksjonsystemene jeg lenket til kjører i tillegg et custom OS, hvilket også fordrer custom Java i dette tilfellet. Java blir kanskje støttet i en ikke datert fremtid, men kjører ikke på disse maskinene i dag overhodet skal vi tro IBM selv. Du spurte hvilken IBM server som ikke støttet Java, jeg svarte. Ble dette for vanskelig for deg?

Det er vel strengt tatt du som setter opp ytelsespørsmålet til å dreie seg 1 kb med kode for å flytte bytes fra a til b. Jeg diskuterer reell ytelse i et stort program, ikke kode som kan spesialsys i assembly etc. Det området som java faktisk lever i. Det er du ikke vi som prøver på dra diskusjonen over på områder som gjelder kanskje 1 promille av kode som er i et prosjekt. Om du skal skrive kode osm skal flytte bytes fra a til b og ingen ting annet, ja da er sikker assembly det smarte. Go for it.

Hva er det du babler om nå da. Hvilke ytelseskritiske bruksområder er det du tenker på. Er du i det hele tatt i stand til å klassifisere et applikasjonsområde? Endret 2. januar 2011 av Del

[quantum]

@Del - Milde jesus, det går framover, dog akk så langsomt. zSeries, som z/TPF kjører på (zTPF er ikke hardware), støtter f.eks. Websphere helt finfint, så du er fortsatt på bærtur med disse irrelevante hardware-tiradene dine. Det eneste som er mer uforklarlig enn den generele forvirringen din, er hvor i all verden du vil med disse argumentene. Java har større moment på server enn på klient, du kan ikke endre det faktumet ved å vise til ymse løsninger brukt til en spesiell type prosessering.

[quantum]

Nei java er ikke database språket, ikke vet jeg hva dette har med diskusjonen å gjøre heller.

Bruksområder ble lagt som premiss for diskusjonen hvor både du og quantum kom med ganske kategoriske påstander etter det jeg kan huske.

prøv å få med deg hva folk skriver så slipper du å fremstå som totalforvirra, hvilke «kategoriske påstander» har jeg fremsatt om javabaserte databaser?

[quantum]

 

IBM sine stormaskiner kjører Power prosessor, en arkitektur som trenger eget rammeverk for å kunne kjøre Java. Transaksjonsystemene jeg lenket til kjører i tillegg et custom OS, hvilket også fordrer custom Java i dette tilfellet. Java blir kanskje støttet i en ikke datert fremtid, men kjører ikke på disse maskinene i dag overhodet skal vi tro IBM selv. Du spurte hvilken IBM server som ikke støttet Java, jeg svarte. Ble dette for vanskelig for deg?

 

 

sånn generelt, noe av pointet med java er jo plattformuavhengigheten, men *alle* ulike arkitekturer som skal kjøre java krever «eget rammeverk». det er altså bytekoden som er plattformuavhengig, runtime'n må være «egen» for «alle» arkitekturer. men dette vet du vel, håper jeg?

 

når det gjelder IBMs z/Series så leverer jo IBM Websphere på disse. IBM er forøvrig godt representert i bank/finans med Websphere. i tillegg sier jo tpf-linken din at tpf støtter gnu toolchain, hvilket da blir nok et eksempel på at referansene dine konsekvent motsier de kategoriske påstandene dine, gnu toolchain inkluderer gcc som støtter java. (ikke dermed sagt at gnu java akkurat er i utstrakt bruk på tpf)

[doloop]

Du er kanskje ikke klar over at IBM er en av de største om ikke den største java støttespilleren utenfor Oracle?

 

 

Og jo java støttes i zOS

 

http://www-03.ibm.com/systems/z/os/zos/tools/java/index.html

Endret 2. januar 2011 av doloop

[Del]

prøv å få med deg hva folk skriver så slipper du å fremstå som totalforvirra, hvilke «kategoriske påstander» har jeg fremsatt om javabaserte databaser?

At hovedmarkedet til Java er forretningskritiske transaksjonssystemer? En påstand du ikke har vært istand til å innrømme var feil ennå.

sånn generelt, noe av pointet med java er jo plattformuavhengigheten, men *alle* ulike arkitekturer som skal kjøre java krever «eget rammeverk». det er altså bytekoden som er plattformuavhengig, runtime'n må være «egen» for «alle» arkitekturer. men dette vet du vel, håper jeg?

Dermed er Java omtrent like plattformuavhengig som et hvilket som helst annet språk med forskjellen at du ikke trenger å rekompilere når du flytter den over til en annen arkitektur. Google er som kjent saksøkt for sin Dalvik på ARM baserte enheter, som er akkurat et slikt tilpasset rammeverk. Denne plattformuavhengigheten din er oppskrytt, og det har jeg demonstrert ganske ettertrykkelig for deg nå. Det er et buzzword med lite reell substans, enten det gjelder serverside eller klient side.

når det gjelder IBMs z/Series så leverer jo IBM Websphere på disse.

Korrekt. Lenken hos IBM var utdatert, Java-støtten kom på plass i løpet av et par år.

i tillegg sier jo tpf-linken din at tpf støtter gnu toolchain, hvilket da blir nok et eksempel på at referansene dine konsekvent motsier de kategoriske påstandene dine, gnu toolchain inkluderer gcc som støtter java. (ikke dermed sagt at gnu java akkurat er i utstrakt bruk på tpf)

Dette er et interessant punkt, og sier en god del om hvor viktig det var å få åpnet Java. For Red Hat sin JBoss satsing var dette fundamentalt, så for Java er det ingen tvil om at dette var veldig viktig. Men dette kunne jo Sun gjort lenge før Silverlight kom på banen, i tide for lanseringen av z/TPF som da kom på markedet helt uten Java-støtte. Dette er noe du bør gruble lenge på, men du er kanskje for ung til å ha fulgt med årene før.

Du er kanskje ikke klar over at IBM er en av de største om ikke den største java støttespilleren utenfor Oracle?

Pest og Kolera, alternativet var .Net. You do the math.

Og jo java støttes i zOS

z/TPF kjører ikke zOS.

[quantum]

@Del: lurer fortsatt på hvilke bastante påstander jeg har kommet med om javabaserte databaser, men det er vel så enkelt som at du har blanda korta litt i kampens hete.

 

når det gjelder transaksjoner har du avgrenset din definisjon til å være noe helt annet enn det jeg snakker om, så den diskusjonen er rett og slett over. faktum er at serverside-markedet for java er stort, større enn klientmarkedet etter mine landemerker, og man finner at java er svært utbredt til forretningskritisk eksekvering (for ikke å komme på kollisjonskurs med transene dine) hele veien ned til, men ikke inklusive, databasenivå. jeg synes det er svært forunderlig at det må knyttes realtime-krav til transaksjoner for at de skal betegnes som kritiske, men det er nå engang ditt valg og det skal du gjerne få ha i fred for min del.

 

akkurat som jeg ikke har uttrykt noe bastant om javabaserte databaser har jeg heller ikke uttrykt noe spesielt bastant om java's plattformuavhengighet, men like it or not så er det en sentral egenskap ved de fleste implementasjonene. pointet var å understreke at java må regnes som støttet på en plattform selv om det er med en «egen» implementasjon, enten det er gnu java, sun java, oracles java eller ibms egen java. at du ikke er imponert over plattformuavhengigheten intersserer meg midt bak.

 

at det skulle bety noe spesielt at suns åpning av java sammenfaller med lanseringen av silverlight blir ren spekulasjon. det kan godt hende silverlight har spilt en rolle i avgjørelsen til sun, men jeg tror ikke den var stor. avgjørelsen om å lansere javafx har sikkert vært sterkere påvirket av silverlight.

 

at det alt i alt var viktig å få åpna java er det ingen som stiller spørsmålstegn ved. det faktum at det ble gjort er vel bevis nok i seg selv?

 

når det gjelder z/TPF så er det for det første ikke en hardwareplattform men et softwaremiljø for eksekvering av transaksjoner. jeg har bare funnet dokumentert at gnu toolchain, som jeg da antar inkluderer gnu java, er tilgjengelig. om den brukes på det os'et i noen særlig grad aner jeg ikke. det som derimot er faktum er at zSeries stormaskiner, som *er* en hardwareplattform, har god støtte for java, og din påstand var at det ikke var tilfellet. så noe særlig grubling basert på dine inkorrekte påstander og motstridende referanser har jeg ingen planer om å begi meg inn på.

Endret 2. januar 2011 av quantum

[Del]

@Del: lurer fortsatt på hvilke bastante påstander jeg har kommet med om javabaserte databaser

Når sa jeg påstandene var om databaser? Kan godt hende du slang med leppa der også, men det begynner å bli rimelig uinteressant nå.

når det gjelder transaksjoner har du avgrenset din definisjon til å være noe helt annet enn det jeg snakker om,

Det er en sak, men å klassifisere transaksjoner som hovedmarkedet er uansett definisjon fjernt. Det hørtes sikkert kult ut, men det er villedende, og siden har du ikke vært i stand til å komme deg ut av det sporet.

når det gjelder z/TPF så er det for det første ikke en hardwareplattform men et softwaremiljø for eksekvering av transaksjoner.

Tilsvarende kan du naturligvis argumentere at HPs non-stop bare er Integrity hardware, så det er også en software plattform. I praksis brukes naturligvis samme komponenter, men høyere RAS krav betyr typisk tandem oppsett med fail-over, og dette betyr fort et annet hardware oppsett som kompliserer software biten betydelig. De færreste vil være enige med deg i at dette kun er et software miljø.

[quantum]

Dette er et interessant punkt, og sier en god del om hvor viktig det var å få åpnet Java. For Red Hat sin JBoss satsing var dette fundamentalt, så for Java er det ingen tvil om at dette var veldig viktig. Men dette kunne jo Sun gjort lenge før Silverlight kom på banen, i tide for lanseringen av z/TPF som da kom på markedet helt uten Java-støtte. Dette er noe du bør gruble lenge på, men du er kanskje for ung til å ha fulgt med årene før.

websphere 3.0 ble støttet på OS/390, på java 1.2, som altså var i markedet i 1999. z/TPF kom i 2005, og jeg tipper den ikke støtter annet enn gnu java den dag i dag, og dermed ikke websphere. det betyr dog ikke at z/OS er den marginale plattformen på zSeries.

[doloop]

Jeg skjønner virkelig ikke hvordan zTPF betyr at java ikke brukes i forretnings-kritiske transaksjoner, men du kan kanskje forklare dette bedre.

 

 

 

z/TPF er noe jeg skal innrømme jeg ikke har mye peiling på, men har nå undersøkt en del de siste 2 timene ihvertfall, i tilegg til å lese litt har jeg snakket med et par som jobber med disse tingene(dog ingen av mine "bekjente" har jobbet mot z/TPF). Jeg har lært følgende (om du har ekspertise på dette område må du gjerne rette meg):

 

Enhver hardware som kjører z/TPF kan også kjøre z/OS dermed støtter alle IBM server java. Det også vanlig å kjøre z/OS sammen med z/TPF, i en konfigurasjon som lar z/TPF kalle opp z/OS applikasjoner.

 

Videre forstår jeg zTPF er i prinsippet et minimalt operativsystem for ruting av meldinger til applikasjoner eller for å gå direkte på databasen via småprogrammer (typisk under 4kb i assembly, men større C programmer støttes også nå). Typisk bruk vil være å laste opp en liten blokk assembly kode som skal prosessere en bestemt meldingstype, prosesseringen kan være alt fra å skrive den til permanent lagring, eller å prosessere den for så å sende ut nye meldinger selv. For eksempel meldinger som skal sendes til en java applikasjon. Java applikasjonen kan enten kjøre på samme hardware eller eksternt.

 

 

Plattform uavhengihet

 

Dette var da voldsomt, at java gir deg et lag over os for kall betyr da absolutt at den er mer plattform uavhengig enn for eksempel c++. Ja du kan compile samme kildekode mot forskjellige operativsystemer, gitt at du ikke bruker noen os kall eller biblioteker som bruker os kall. Java har gitt deg et lag som gjør at du aldri trenger å gjøre os kall. Write once run anywhere argumentet er jo absolutt er godt argument. Oracle står for testing av at oppførselen til ditt program vil være lik uansett plattform.

Endret 2. januar 2011 av doloop

[quantum]

@Del, pointet er at både zSeries og HP Nonstop støtter Java, påstanden din var det motsatte.

 

at ikke du er villig til å kalle noe en transaksjon før det kjører på en plattform uten javastøtte er helt greit for meg, men konsekvensen av det er at f.eks. flyselskaper og ymse andre virksomheter jeg har nevnt for deg etter ditt syn rett og slett ikke har transaksjoner. det har jeg ingen problemer med å leve med heller.

[Del]

Godt å se at dere begge har begynt å sjekke litt facts før dere poster.

websphere 3.0 ble støttet på OS/390, på java 1.2, som altså var i markedet i 1999. z/TPF kom i 2005, og jeg tipper den ikke støtter annet enn gnu java den dag i dag, og dermed ikke websphere. det betyr dog ikke at z/OS er den marginale plattformen på zSeries.

Gidder ikke finne tilbake, men jeg så et par kilder som tydet på at Java nå er på plass også for z/TPF. GNU sin Java som du sikter til er en relativt kompleks software stack. At deler av GCC er tilgjengelig betyr ikke nødvendigvis at du kan sette Java i produksjon. Her har du åpenbart en del å lære om porting av programvare. Du skjønner, kildekode er ikke helt plattformuavhengig det heller når alt kommer til alt.

Jeg skjønner virkelig ikke hvordan zTPF betyr at java ikke brukes i forretnings-kritiske transaksjoner, men du kan kanskje forklare dette bedre.

Se å dra hodet ditt ut av binær modus. Det er veldig lite i verden som er svart hvitt. Jeg har aldri sagt at det ikke brukes, jeg har bare foret dere en rekke teskjeer slik at dere ser at det er en svært dårlig klassifisering av hovedmarkedet til Java. Jeg har også gjort dere oppmerksomme på at klientsiden er viktig selv om Java applets mislykkes mot hovedsaklig Adobe.

z/TPF er noe jeg skal innrømme jeg ikke har mye peiling på, men har nå undersøkt en del de siste 2 timene ihvertfall, i tilegg til å lese litt har jeg snakket med et par som jobber med disse tingene(dog ingen av mine "bekjente" har jobbet mot z/TPF).

Så flott. Det morsomste med slike tråder er at man gjerne kommer ut av dem med litt ny kunnskap.

Jeg har lært følgende (om du har ekspertise på dette område må du gjerne rette meg):

 

Enhver hardware som kjører z/TPF kan også kjøre z/OS dermed støtter alle IBM server java. Det også vanlig å kjøre z/OS sammen med z/TPF, i en konfigurasjon som lar z/TPF kalle opp z/OS applikasjoner.

At du kan installere zOS på en zTPF maskin er kun av akademisk interesse, det vil ikke skje i virkeligheten. Da hadde kunden heller kjørt zOS fra dag en. En stormaskin fra IBM kan partisjoneres, og det er nok en vanlig løsning for kunder som kjører TPF. Dvs. du kan kjøpe en stormaskin fra IBM og så partisjonere den i en TPF del og en zOS del.

Videre forstår jeg zTPF er i prinsippet et minimalt operativsystem for ruting av meldinger til applikasjoner eller for å gå direkte på databasen via småprogrammer (typisk under 4kb i assembly, men større C programmer støttes også nå). Typisk bruk vil være å laste opp en liten blokk assembly kode som skal prosessere en bestemt meldingstype, prosesseringen kan være alt fra å skrive den til permanent lagring, eller å prosessere den for så å sende ut nye meldinger selv. For eksempel meldinger som skal sendes til en java applikasjon. Java applikasjonen kan enten kjøre på samme hardware eller eksternt.

Korrekt. Sjekker du wikipedia siden:

http://en.wikipedia.org/wiki/Transaction_Processing_Facility

så ser du at assembly er noe man ønsker å fase ut til fordel for C av helt naturlige grunner (assembly er krevende å kode og et mareritt å vedlikeholde):

However, more recent versions of TPF encourage the use of C.

Plattform uavhengihet

 

Dette var da voldsomt, at java gir deg et lag over os for kall betyr da absolutt at den er mer plattform uavhengig enn for eksempel c++. Ja du kan compile samme kildekode mot forskjellige operativsystemer, gitt at du ikke bruker noen os kall eller biblioteker som bruker os kall. Java har gitt deg et lag som gjør at du aldri trenger å gjøre os kall. Write once run anywhere argumentet er jo absolutt er godt argument. Oracle står for testing av at oppførselen til ditt program vil være lik uansett plattform.

Du bør sjekke opp bedre. Byggmiljø som qmake gjør krysskompilering til en lek. Eksempelvis Qt-applikasjoner kjører på tvers med svært lite problemer. På den andre siden er det nå lekende lett å virtualisere hele operativsystem, så i den forstand er nå alt plattformuavhengig. Dessverre funker ikke Write once run anywhere så godt i praksis, selv om ideen er god. Til det er det flere grunner, og vi har vel vært innom de fleste allerede.

@Del, pointet er at både zSeries og HP Nonstop støtter Java, påstanden din var det motsatte.

Nå må du skjerpe deg. Jeg har aldri påstått at Non-stop ikke støttet Java, tvert imot har jeg vært klar over det lenge. Har du nå sjekket hvor lang tid det tok å få det på plass? En liten digresjon: Hvor godt tror du løsningen er optimalisert for å kjøre på Itanium? Har du i det hele tatt kjennskap til utfordringer knyttet til optimalisering mot CPU-arkitektur? Når det gjelder IBM var det TPF løsningen jeg siktet til, og jeg ga lenke hvor jeg gjorde det krystallklart manglende støtte var sakset derfra. Jeg er drittlei av nivået du legger deg på, skjerp deg! Hvis du ikke er i stand til å lese hva folk skriver bør du vurdere å ikke svare.

[quantum]

@Del når det gjelder gnu java har jeg allerede sagt at den ikke akkurat er noe naturlig valg å gå i produksjon med, nettopp for at du ikke skulle henge deg opp i det. jeg nevnte gnu java for å illustrere at så godt som alle påstandene du fremsetter om java er feil, også den om at java ikke er tilgjengelig under z/TFP. nå har du jo sjøl også gravd opp enda mer info som viser at det ikke stemte helt, og det er jo bra.

 

likekvel, det var ingen andre enn deg som skrev at «Java blir kanskje støttet i en ikke datert fremtid, men kjører ikke på disse maskinene i dag overhodet skal vi tro IBM selv.» disse maskinene har hatt javastøtte ihvertfall tilbake til java 1.2, altså lenge før z/TFP eksisterte. men på den annen side, z'en er jo bare «new wrapping», denne teknologien har sånn sett eksistert lenge før java var påtenkt. men verden går framover vettø, gjelder å henge med i utviklinga, gammel'n!

[Del]

«Java blir kanskje støttet i en ikke datert fremtid, men kjører ikke på disse maskinene i dag overhodet skal vi tro IBM selv.»

og i tillegg en lenke hvor IBM selv forteller at de har støtte for C og C++, og at Java er planlagt men ikke tilgjengelig på TPF systemer. At støtten nå muligens er på plass og at lenken er utdatert kan naturligvis være tilfellet, nettopp derfor føyde jeg til skal vi tro IBM, slik at det ble krystallklart at informasjonen var fra lenken.

 

Ble det klart for deg nå? Hvis ikke er jeg redd det er vanskelig for meg å formidle noe som helst til deg. Du har allerede klart å dille i flere poster dette innbilte poenget ditt.

[doloop]

Du har sagt følgende (du har sikkert sagt mye mer men dette er hva jeg husker)

 

 

1) Java brukes ikke i forretningskritiske transaskjoner

 

Som en som lager ERP system i akkurat java kan jeg fortelle at alle forretningkritiske transaksjoner til de 1000+ selskapene i Norge som kjører vårt system går igjennom vårt Java lag. Det er selvsagt løsninger fra BBS og andre store selskaper involvert også, men alle transaksjoner går igjennom vårt Java lag, og om java laget vårt feiler går de nok ganske raskt konkurs, eventuelt får besøk av staten. Dette inkluderer for eksempel nettbutikker(b2b), vanlig butikker(den største her hadde ommsettning på 200+ millioner i 2009, dette er absolutt et godt antall transer =)), og mindre selskaper.

 

Dette betyr jo selvsagt ikke at bruken er utstrakt blant andre selskaper, men med tanke på artikkelen om java på Wikipedia høres det ut som bevisbyrden ligger på deg.

 

http://en.wikipedia.org/wiki/Java_(software_platform)#Web_server_and_enterprise_use

 

 

2) Java støttes ikke en i rekke servere (hp, ibm)

 

Her har du motbevist deg selv

 

 

3) Klientsiden er viktig nok for Java til at når en ny konkurrent dukker opp endres hele Java sitt forretningsgrunnlag.

 

Dette må du faktisk dokumentere, selvfølgelig java vil ha klientsiden, men å hevde at Silverlight kan ha en stor påvirkning på Java sin hele forretningsplan(open source java) er veldig drøyt. Her gjenstår det for deg å komme med dokumentasjon.

Endret 2. januar 2011 av doloop

[Del]

Vennligst ingen stråmenn. Kom frem med lenke til post hvor du mener jeg har påstått dette.

 

Når det gjelder den første sa jeg at jeg ikke kjente til bruk, og utfordret dere til å komme med eksempler. Ingen eksempler har jeg sett så langt. Jeg sier fortsatt ikke at de ikke eksisterer, bare at jeg ikke kjenner noen. Gettit? I det lyset er det ganske utrolig hvilken frihet du tar deg til å vri på ting.

 

Når det gjelder manglende Java støtte har vi allerede på det rene at både HP og IBM's løsning for forretningskritiske transaksjonssystemer ikke støttet Java inntil svært nylig. Hvordan Java støtten egentlig er på disse systemene i dag er det vel ingen av oss som kan si sikkert. Dette er altså akkurat de samme systemene som skulle være hovedområdet for Java. Gettit?

 

Til det siste. MS ny konkurrent? Hvilken planet datt du ned fra?