Er java et tregt språk?

[Del]

jeg har nevnt mange eksempler du ikke har fått med deg,

Er det for mye å be om en liste. VPS var det eneste jeg så, og jeg er fortsatt tvilende på om det er et eksempel på forretningskritisk transaksjonsystem som kjører java. Oslo børs derimot bruker ikke java for sitt transaksjonsystem utfra det jeg vet.

tcp-c er en ytelsestest, som ikke reflekterer hvordan man bygger systemer som håndterer viktige transaksjoner.

Helt korrekt, det er det mest representative vi har på benchmarkfronten for slike systemer. Det største problemet med TPC-C er ikke manglende Java eller SQL, det er derimot de urealistiske disksystemene som brukes. Hvis du har noe å fare med her så foreslår jeg at du prøver litt hardere.

tcp-c involverer det absolutte minimum man trenger for å gjennomføre transaksjoner på et teknisk nivå. vi kan kanskje være enige om at f.eks. db2 og oracle db er to ganske mye benyttede komponenter i en systemstack for prosessering av forretningskritiske transaksjoner. trod du disse benyttes utelukkende via lavnivå c-api'er (slik som referansen din dokumenterer at tcp-c benchmark'ene blir implementert), eller tror du man tillater seg bruk av f.eks. SQL?

Hvis jeg svarer, vil du tro meg, eller vil du bable videre?

tror du oracle kjøpte sun for å knuse flash og silverlight?

Nei. Jeg tror Silverlight var en viktig faktor for Sun sin endelige åpning av Java. Men dette har jeg vel vært rimelig tydelig på hele veien.

du har skrevet at du ikke har sett java brukt i systemer som håndterer kritiske forretningstransaksjoner og derfor betviler at disse eksisterer. dette mener du altså ikke? kan du i såfall prøve å forklare *hva* du mener?

Jeg mener vel at forretningskritiske transaksjonssystemer er en rimelig fjern klassifisering av Javas viktigste marked. Hvis du hadde sagt middleware, hvor blant annet slike systemer kan være en back-end, så hadde du dekket en viktig del av markedet. Å dra det derfra til å si at Sun ikke brydde seg om klientsiden, og at Silverlight derfor ikke var en faktor under åpningen av Java, mener jeg vitner om svært mangelfull kunnskap.

[quantum]

Er det for mye å be om en liste. VPS var det eneste jeg så, og jeg er fortsatt tvilende på om det er et eksempel på forretningskritisk transaksjonsystem som kjører java. Oslo børs derimot bruker ikke java for sitt transaksjonsystem utfra det jeg vet.

 

du er velkommen til å lese tidligere innlegg for flere eksempler, og forøvrig også til å tvile så mye du vil.

 

tcp-c er en ytelsestest, som ikke reflekterer hvordan man bygger systemer som håndterer viktige transaksjoner.

Helt korrekt, det er det mest representative vi har på benchmarkfronten for slike systemer. Det største problemet med TPC-C er ikke manglende Java eller SQL, det er derimot de urealistiske disksystemene som brukes. Hvis du har noe å fare med her så foreslår jeg at du prøver litt hardere.

 

på hva da? tcp-c må gjerne være den mest representative ytelsestesten for min del, den er likevel ikke representativ for hvordan man bygger systemer som håndterer viktige transaksjoner, et utsagn du betegner som helt korrekt.

 

tcp-c involverer det absolutte minimum man trenger for å gjennomføre transaksjoner på et teknisk nivå. vi kan kanskje være enige om at f.eks. db2 og oracle db er to ganske mye benyttede komponenter i en systemstack for prosessering av forretningskritiske transaksjoner. trod du disse benyttes utelukkende via lavnivå c-api'er (slik som referansen din dokumenterer at tcp-c benchmark'ene blir implementert), eller tror du man tillater seg bruk av f.eks. SQL?

Hvis jeg svarer, vil du tro meg, eller vil du bable videre?

 

det er veldig avhengig av hva du svarer.

 

tror du oracle kjøpte sun for å knuse flash og silverlight?

Nei. Jeg tror Silverlight var en viktig faktor for Sun sin endelige åpning av Java. Men dette har jeg vel vært rimelig tydelig på hele veien.

 

du tror det ene og jeg tror det andre. det kan jeg fint leve med.

 

du har skrevet at du ikke har sett java brukt i systemer som håndterer kritiske forretningstransaksjoner og derfor betviler at disse eksisterer. dette mener du altså ikke? kan du i såfall prøve å forklare *hva* du mener?

Jeg mener vel at forretningskritiske transaksjonssystemer er en rimelig fjern klassifisering av Javas viktigste marked. Hvis du hadde sagt middleware, hvor blant annet slike systemer kan være en back-end, så hadde du dekket en viktig del av markedet. Å dra det derfra til å si at Sun ikke brydde seg om klientsiden, og at Silverlight derfor ikke var en faktor under åpningen av Java, mener jeg vitner om svært mangelfull kunnskap.

 

sun brydde seg om klientsiden, f.eks. nok til å komme opp med javafx, men ikke nok til å komme i mål. jeg sier (for å repetere meg selv) bare at browserplugins ikke er det tykkeste beinet java står på. silverlight kan ha spilt en rolle i suns beslutning om åpning, såvel som i beslutningen om å avslutte javafx. men beslutningen om åpning omfatter et mye bredere funksjonsområde enn det silverlight representerer, og jeg velger dermed å tro at silverlight ikke har vært en hovedpådriver bak denne beslutningen. hvis du velger å tro det motsatte er det helt uproblematisk.

 

på klientsiden er web/html minst like viktig som plugins og tykk-klienter som swing, for javaplattformen sin del leveres teknologien her stort sett av 3.part, som enten har åpne eller lukkede løsninger.

 

alt i alt har java *også* mellomvare som et viktig bein å stå på, som du skriver. ennå et eksempel på at plugins ikke er så sentralt. jeg tror det generelle momentet i opensource-baserte plattformer, både generelt og i java-markedet, har veid en god del tyngre enn plugin-teknologien silverlight som pådriver for suns beslurning om å åpne java.

 

forretningskritiske transakssjonssystemer implementeres i java. også. overhodet ikke alt. selvfølgelig. mye prosesseres blant annet ved hjelp av teknologi fra tidsepoken før java var påtenkt. jeg har aldri påstått noe annet. du har selv observert .net, og det har jeg overhodet ikke betvilt. selvfølgelig ikke. det er en mye enklere beslutning å innføre mellomvareløsninger som supplement i transaksjonsmiljøer, enn det er å erstatte eksisterende løsninger med ny teknologi. så java mellomvare sklir lettere inn. like fullt brukes java også til både implementasjon av nye systemer for prosessering av kritiske transaksjoner, og til å erstatte gamle.

 

om du fortsatt betviler dette er det helt og holdent din sak. jeg er ikke misjonær. men tenk over følgende: når du ser hvor lenge de systemene vi snakker om lever, og teknologien de bygger på, med dem, er det ikke da temmelig opplagt at det er et svært viktig marked for sun/oracle å være i med java? det samme gjelder andre 3.parts leverandører som f.eks. ibm, etterhvert som pl/1 fases ut - fort går det jo ikke, men det skjer faktisk - blir det desto viktigere å være på plass med ny teknologi som sikrer inntekter i årtier framover. ibm har et ganske kraftig salgsapparat som har pusha websphere i mange år allerede. neppe uten en visst gjennomslag i markedet. så ganger du det opp med bea(rip), oracle, sun(rip) og flere. vei så dette opp mot verdien av browserplugin-markedet, og du får sånn omtrentlig ut årsaken til at jeg ikke tror silverlight spiller så veldig tung rolle.

 

relevansen av hp's hardware og tcp-c oppi dette blir litt lav, sånn jeg ser det. hp's blade-servere kjører på lik linje med andre blade-servere og andre typer servere, selvfølgelig java-applikasjoner, som du spurte om. hvor i all verden ville du med det argumentet?

 

du spør stadig etter eksempler.

 

et skandinavisk mobilselskap kjører mange av sine viktige transaksjoner på oracle-database og lagrede prosedyrer. de bruker et 3-parts billingsystem og provisjoneringssytem som ikke er basert på java. de er i ferd med å implementere billing på java og generelt innføre javabasert mellomvareplattform. de har allerede en egenutviklet javabasert integrasjonsplattform. mellomvareplattformen er proprietær og billingsystemet basert på opensource plattform. billingtransaksjoner blir derfor implementert i java, og endelig eksekvert i databasen.

 

et markedsledende flyselskap i utlandet kjører java fra topp til tå, i tospann med et gammelt, utdatert reservasjons og bookingsystem som ikke kan håndtere kravene moderne flyprodukter stiller. dobbel transaksjonsflyt mao, med de forretningskritiske elementene på java (f.eks. billingen). også her med en markedsledende database inne i bildet selvfølgelig.

 

i tillegg flere eksempler (noen alt nevnt uten at du har fått det med deg) hvor java spiller en rolle, enten enda mer sentralt, eller mer perifert, ettersom hvor mye gammel teknologi det er i bagasjen og hvor raskt de klarer å tilpasse seg, herunder flere store norske banker og finansinstitusjoner, store annonse- og katalogselskaper og telecomselskaper.

Endret 4. desember 2010 av quantum

[GeirGrusom]

Hvem som bruker java er i og for seg uviktig.

[William_S]

Fælt så mye til krangling da. Hvorfor så mange bruker Java kan ha noe med at Java er enklere å forholde seg til. Jeg er på ingen måte en fullbefaren programmerer (2 året på dataingeniør), men Java er greit å forholde seg til. Java sier i fra ganske nøyaktig hva som er feil, i C så får man bare en stygg melding om segfault og må lete etter feilen. Det er kanskje det som gjør javaspråket tregere, men samtidig også enklere å forholde seg til.

Just my two cents.

[doloop]

Morroklump. Det var du som fremhevet forretningskritiske transaksjonsystemer som (det eneste?) markedet Java befant seg i. At java brukes som web-grensesnitt til diverse formål er en ganske annen sak.

 

 

Jeg ga faktisk opp å diskutere med deg på grunn av slike holdninger. Du har ingen anelse om hvor java er plassert i markedet, og referer til stadighet til nettbanken din sin innlogging. Dette blir for dumt og useriøst. Du referer også il stråmenn nå ser jeg, men du er jo mesteren av stråmenn; web broser plugin til java funker ikke hos meg, eller java appleten til BBS er dårlig.

[Del]

Dette begynner å bli fryktelig slitsomt. Hvis du kjeder deg i jula, og bare vil ha noen å snakke med, så finnes det mer konstruktive metoder. Jeg ble bare dritlei påståelighet på tema som du og enkelte andre åpenbart visste mindre om enn dere liker å gi inntrykk av. Når det gjelder disse markedene, så har jeg allerede dokumentert i tråden at klientsiden var viktig for Sun, og at de tjente store penger på den. Til og med Oracle anser klientsiden viktig nok til å saksøke Google, som med sin Dalvik har gitt en synkende/døende Java nytt liv.

 

Applet'en som alle i Norge bruker har aldri funket knirkefritt på tvers av plattformer, det er et godt eksempel på at denne plattformuavhengigheten er oppskrytt. Jeg kunne godt kommet med flere eksempler på dette også, Android spill som funker på en telefon men ikke en annen, Itanium som måtte vente en god stund på fungerende Java, Sparc som mottok særbehandling. Jeg nevnte appleẗ́en flere ganger fordi enkelte så ut til å være så tjukke i hodet at de ikke forstod hva det betød.

 

Forretningskritiske transaksjonsystemer kjører derimot typisk ikke Java. Dette gjelder så vidt jeg vet alle verdens børser, og alle verdens banker. På en web-server derimot kjører gjerne Java. Som mellomvare for å få diverse bankesystemer til å funke sammen er nok også Java populært. Java er typisk ikke foretrukket på ytelseskritiske system, enten det dreier seg om latency-kritisk, real-time eller HPC. Personlig tror jeg ikke språket er egnet til formålene heller, men det er en annen sak (og har utrolig nok ikke blitt diskutert). I utgangspunktet kan man argumentere for at Java kan brukes til HPC, men latency-kritisk og real-time er jeg noe tvilende til, og det utelukker blant annet de omtalte transaksjonsystemene.

[quantum]

blabla

du gir deg ikke ser jeg. det sier seg jo selv at du ikke har oversikt over hva som foregår i alle verdens børser og banker.

 

enda mer latterlig er påstanden din om at javas manglende rt-egenskaper forhindrer at det brukes i forretningskritiske transaksjoner. det må jo være nytt for deg at mange kritiske forretningstransaksjoner i banker, flyselskaper, børser, telecomselskaper osv. osv. kjøres i batch? kan du kanskje forklare oss hvorfor du mener den type transaksjonsprosessering krever rt-responstid?

[Del]

Virker som om vi har litt forskjellig definisjon av forretningskritisk transaksjonssytem. En web-interface for å legge inn bestilling er ikke hva jeg tenker på. Systemet som utfører selve transaksjonen, altså flytter pengene, er det jeg legger i ordet. Hvis du sikter til at nettsidene for bestilling hos en tilbyder gjerne drives med Java har jeg ingen problemer med det. Der betyr responstid typisk lite. Dernest foreslår jeg at dere begge skjerper språkbruken noen hakk, og heller forsøker å fylle postene med informasjonsverdi. Vi har vel allerede etablert ganske ettertrykkelig at dette ensartede markedet til Java bare var tull, markedet er atskillig mer sammensatt. Enhver diskusjon blir håpløs når man slenger ut slikt tullball som om det er et selvsagt premiss. Det blir litt mor lille er en sten utav det.

[Patton]

Forretningskritiske transaksjonsystemer kjører derimot typisk ikke Java. Dette gjelder så vidt jeg vet alle verdens børser, og alle verdens banker. På en web-server derimot kjører gjerne Java. Som mellomvare for å få diverse bankesystemer til å funke sammen er nok også Java populært. Java er typisk ikke foretrukket på ytelseskritiske system, enten det dreier seg om latency-kritisk, real-time eller HPC. Personlig tror jeg ikke språket er egnet til formålene heller, men det er en annen sak (og har utrolig nok ikke blitt diskutert). I utgangspunktet kan man argumentere for at Java kan brukes til HPC, men latency-kritisk og real-time er jeg noe tvilende til, og det utelukker blant annet de omtalte transaksjonsystemene.

Jeg ble litt nysgjerrig på den uthevede delen (språket). I tillegg til JVM fra sun finnes det kommersielle real-time VM laget av andre firmaer, så real-time og latency problemer tilknyttet garbage collection (som er kjerneproblemet med out-of-the-box JVM) kan elimineres. Hvorfor er akkurat språket dårligst egnet til formålene nevnt over?

[quantum]

Virker som om vi har litt forskjellig definisjon av forretningskritisk transaksjonssytem. En web-interface for å legge inn bestilling er ikke hva jeg tenker på. Systemet som utfører selve transaksjonen, altså flytter pengene, er det jeg legger i ordet. Hvis du sikter til at nettsidene for bestilling hos en tilbyder gjerne drives med Java har jeg ingen problemer med det. Der betyr responstid typisk lite. Dernest foreslår jeg at dere begge skjerper språkbruken noen hakk, og heller forsøker å fylle postene med informasjonsverdi. Vi har vel allerede etablert ganske ettertrykkelig at dette ensartede markedet til Java bare var tull, markedet er atskillig mer sammensatt. Enhver diskusjon blir håpløs når man slenger ut slikt tullball som om det er et selvsagt premiss. Det blir litt mor lille er en sten utav det.

 

du har ikke etablert noen verdens ting, annet enn at du er mistroisk og baserer deg på forestillinger tatt ut av lufta (som om du skulle ha oversikt over transaksjonsprosessering i allverdens børser og banker, det faller jo helt på sin egen urimelighet). du ser også ut til å velge å tro at alle eksemplene jeg har gitt deg er oppspinn? og i tillegg skal «språkbruken skjerpes»? makan ...

 

det du kanskje har rett i er at vi legger ulike ting i forretningskritiske transaksjoner. jeg vet fortsatt ikke hva du legger i det. jeg vil derfor igjen bare gjenta spørsmålet fra forrige post; hvorfor i all verden krever forretningskritiske transaksjoner rt-egenskaper? kanskje det klarer opp litt om du utdyper dette.

 

utfra det du skriver over om nettsider og flytting av penger får jeg inntrykk av at du har et litt pussig syn på enkelte ting;

 

for det første mener jeg at i et system hvor input - f.eks. i form av bestilling som du nevner - foretas i et webinterface, så er denne delen av systemet like "forretningskritisk" som resten (men jeg tror likevel vi er enige i at de transaksjonene vi snakker om ikke kjører i en webcontainer). men; kommer ikke bestillingene inn stopper pengestrømmen opp. til forskjell fra f.eks. faktureringstransaksjoner, eller transaksjoner mot kortselskaper, vil en mistet bestilling som følge av feil ofte ikke kunne "gjenvinnes", fordi kunden har gått til en annen leverandør. andre typer transaksjoner lengre ned i verdikjeden kan kjøres omigjen og man får korrigert feilen.

 

dernest har du et snodig syn på dette med responstid. i et webbasert bestillingsinterface som du nevner som eksempel er responstiden viktig, ikke uviktig. hvis ikke kunden får respons raskt nok blir det business for konkurrenten isteden. (men igjen, dette er litt på siden, tror vi i bunn og grunn er enige om at det som kjører i en webcontainer ligger utenfor det vi forbinder med transaksjonskjøring.)

 

nettopp av denne årsaken lager man bestillingssystemer slik at forretningstransaksjonene foregår asynkront, webgui er responsivt og gir en rask og midlertidig bekreftelse på at bestillingen er registert, mens den endelige bekreftelsen kommer senere f.eks. på mail, etter at noen av de nødvendige transaksjonene er gjennomført - asynkront. og det er da jeg stusser veldig på forestillingen din om at disse asynkrone transaksjonene, og for ikke å snakke om batcheksekverte transaksjoner, krever rt-responstider. igjen; fint om du utdyper.

 

jeg kan jo også tilføye at jeg med "forretningskritiske transaksjoner" ikke utelukkende mener ting som foregår i en database, og det antar jeg ikke du heller mener? databasen har ofte en sentral rolle, også når transaksjonshåndteringen er implementert i java. likeledes har du pekt på javabasert mellomvare. mellomvare kan være forretningskritisk også, litt på samme måte som webcontaineren kan være det, men det er ikke der vi ser for oss at transaksjonsprosesseringen finner sted. mellomvare er forøvrig et ganske "vidt" begrep, alt fra "homebrew" screenscraping mot terminalinterface for å kommunisere med eldgamle systemer, til esb'er som f.eks. tar imot "transaksjonsgrunnlaget" på en webservice og poster det på en JMS-kø eller lagrer i den databasetabell, for videre behandling, og det er denne videre behandlingen som jeg da eksempelvis ville forbinde med den type transaksjonshåndtering vi (eller ihverfall jeg) snakker om.

Endret 30. desember 2010 av quantum

[Del]

Jeg ble litt nysgjerrig på den uthevede delen (språket). I tillegg til JVM fra sun finnes det kommersielle real-time VM laget av andre firmaer, så real-time og latency problemer tilknyttet garbage collection (som er kjerneproblemet med out-of-the-box JVM) kan elimineres. Hvorfor er akkurat språket dårligst egnet til formålene nevnt over?

Du nevner et viktig poeng, nemlig garbage collection som gjør at de vanlige javamaskinene rett og slett ikke kan brukes til hverken rt eller responskritiske oppgaver. Da må man over på mer spesialiserte oppsett, og det i seg selv er et ganske betydelig ankepunkt når du har alternative språk hvor samme kompilator brukes. Et annet punkt som er kontorversielt i den forstand at mange vil være uenig er at Java har overhead sammenlignet med et språk som C. For embedded systemer eller store transaksjonsmaskiner vil en C stack kunne gi deg bedre kontroll, mer forutsigbar eksekvering, med mindre kode opp i minnet til enhver tid. Minimalistisk rett på jernet om du vil. At Java prosjekter (eller .Net for den saks skyld) skal være så fordømt billig og kjapt å utvikle er også sjøsprøyt utfra de prosjektene jeg kjenner, og det er etterhvert et betydelig antall. Problemet er at da forsvinner opp-siden ved å bruke java eller .net.

du har ikke etablert noen verdens ting, annet enn at du er mistroisk og baserer deg på forestillinger tatt ut av lufta (som om du skulle ha oversikt over transaksjonsprosessering i allverdens børser og banker, det faller jo helt på sin egen urimelighet).

Vel, jeg har kjennskap til flere, og har delt noe av det her. At du ikke aksepterer min påstand om at milennium IT kjører c/c++ får jeg vel bare leve med. Jeg har vel også ledet deg til hvilken hardware som typisk brukes i slike system, la meg gjenta:

http://h20338.www2.hp.com/nonstopcomputing/cache/76385-0-0-0-121.html

 

I det hele tatt tror jeg du vet absolutt ingenting om slike systemer, og hvor uaktuelt det er å kjøre java på de.

 

du ser også ut til å velge å tro at alle eksemplene jeg har gitt deg er oppspinn?

Hæh, du snakker om VPS og OSE? Det var jeg som ga deg lenkene dit, har du glemt det? OSE satser på samme system som LSE. Det er ikke Java uansett hvor mye du måtte ønske det. At du har kodet interne VPS systemer i Java er greit nok, men de systemene er altså ikke det jeg sikter til.

det du kanskje har rett i er at vi legger ulike ting i forretningskritiske transaksjoner. jeg vet fortsatt ikke hva du legger i det. jeg vil derfor igjen bare gjenta spørsmålet fra forrige post; hvorfor i all verden krever forretningskritiske transaksjoner rt-egenskaper? kanskje det klarer opp litt om du utdyper dette.

Du blander sammen begreper. Real-time er ikke det samme som minimum responstid, som var det jeg litt sloppy kalte latency-kritisk. Skjønt systemer for bank og børs transaksjoner har en blanding av begge. Les deg opp på begrepene.

 

utfra det du skriver over om nettsider og flytting av penger får jeg inntrykk av at du har et litt pussig syn på enkelte ting;

 

dernest har du et snodig syn på dette med responstid.

Vel, hvis du holder deg til et tema i gangen, så vil det nok bli mye ryddigere. På børstransaksjoner er repsonstid kritisk. På både bank og børs transaksjoner er oppetid og korrekthet ved transaksjonen kritisk, i den sammenheng kommer non-stop systemene jeg lenket til inn i bildet. Hvis du setter deg litt inn i hvordan slike systemer er oppbygd tror jeg du raskt vil finne ut at Java ikke er et naturlig valg. I en web-interface er responstid typisk ikke viktig, så spesial tilpassede JVMs er ikke nødvendig. Brukeren tåler å vente et sekund ekstra hvis tilfeldigvis garbage collectoren finner ut at den skal gjøre noe. Jeg tror din oppfatning av responstid er himmel unna hva en børs opererer med.

nettopp av denne årsaken lager man bestillingssystemer slik at forretningstransaksjonene foregår asynkront, webgui er responsivt og gir en rask og midlertidig bekreftelse på at bestillingen er registert, mens den endelige bekreftelsen kommer senere f.eks. på mail,

Høres jo veldig fint ut, men jeg er redd opplegget ditt tryner når man må inn med eksempelvis verified by Visa dialog, slik som nå er vanlig ved nettkjøp. Da slipper man ikke unna transaksjonsbiten, og utsjekk må gjøres mot akkurat den type systemer jeg snakket om.

[quantum]

Vel, jeg har kjennskap til flere, og har delt noe av det her. At du ikke aksepterer min påstand om at milennium IT kjører c/c++ får jeg vel bare leve med.

 

du benekter jo innholdet i alle fakta jeg har presentert for deg så langt, så du må nok bare leve med det ja.

 

(men jeg tviler som sagt ikke på at det du sier om MilenniumIT system er riktig, du får trøste deg med det dersom nattesøvnen blir dårlig.)

 

Jeg har vel også ledet deg til hvilken hardware som typisk brukes i slike system, la meg gjenta:

http://h20338.www2.hp.com/nonstopcomputing/cache/76385-0-0-0-121.html

 

I det hele tatt tror jeg du vet absolutt ingenting om slike systemer, og hvor uaktuelt det er å kjøre java på de.

 

kan virkelig ikke se poenget ditt i det heletatt. du snakker muligens om en spesiell type transaksjonssystemer hvor rt-responstider er påkrevet? i såfall; case closed. dessverre evner du ikke å klargjøre hva du egentlig legger i begrepet, det eneste vi ser ut til å ha klarhet i er at vi ikke snakker om webapplikasjoner.

 

forøvrig støtter hp java på nonstop, det står jo i linken din. det er rent forbløffende hvordan referansene dine faktisk konsekvent avkrefter påstandene dine. gjør du det med vilje, eller glemmer du å lese det du refererer til.

 

Hæh, du snakker om VPS og OSE? Det var jeg som ga deg lenkene dit, har du glemt det? OSE satser på samme system som LSE. Det er ikke Java uansett hvor mye du måtte ønske det. At du har kodet interne VPS systemer i Java er greit nok, men de systemene er altså ikke det jeg sikter til.

 

vps var nok noe jeg bragte på banen i denne tråden og ikke du. uten at det spiller noen rolle. det interessante er at du ikke anser at systemene deres håndterer forretningskritiske transaksjoner. vi kan godt være enige om at de ikke gjør det, men da må vi også være enige om at vi snakker om en veldig snever definisjon av "forretningskritisk transaksjon". jeg synes det blir litt på siden gitt hva vi hadde som utgangspunkt; nemlig min påstand om at javas rolle "server-side" er vel så viktig som klientsiden. det kan vi jo forsåvidt diskutere og synse om til vi blir blå i trynet, men vi kommer ikke unna at markedene vi snakker om omfatter mye mer enn klientside og spesielle transaksjoner som krever realtime-egenskaper.

 

edit: vil da bare bemerke at begreper som realtime, latency, minimal responstid osv. gjerne kan ha ulikt innhold, men det er uansett begreper som ikke er sentrale når du prosesserer asynkront/i batch.

 

Du blander sammen begreper. Real-time er ikke det samme som minimum responstid, som var det jeg litt sloppy kalte latency-kritisk. Skjønt systemer for bank og børs transaksjoner har en blanding av begge. Les deg opp på begrepene.

 

makan, hvis det er du som ikke klarer å uttrykke deg presis så er det du som har en jobb å gjøre. det andre du skriver er jeg enig i, ulike transaksjoner stiller ulike krav, og det gjelder overalt, ikke bare innen finans.

 

men jeg har fortsatt ikke helt klart for meg om du i det heletatt anerkjenner asynkron transaksjonsprosessering, eller batchbasert prosessering som forretningskritisk. hvis du ikke gjør det blir igrunnen hele diskusjonen basert på feil premisser og dermed også helt uinteressant.

 

På børstransaksjoner er repsonstid kritisk. På både bank og børs transaksjoner er oppetid og korrekthet ved transaksjonen kritisk, i den sammenheng kommer non-stop systemene jeg lenket til inn i bildet. Hvis du setter deg litt inn i hvordan slike systemer er oppbygd tror jeg du raskt vil finne ut at Java ikke er et naturlig valg. I en web-interface er responstid typisk ikke viktig, så spesial tilpassede JVMs er ikke nødvendig. Brukeren tåler å vente et sekund ekstra hvis tilfeldigvis garbage collectoren finner ut at den skal gjøre noe. Jeg tror din oppfatning av responstid er himmel unna hva en børs opererer med.

 

visse transaksjoner krever responstider som ikke gjør java til et naturlig valg, andre gjør det ikke. minner igjen om at du har dokumentert for oss at hp ihvertfall anser java som et naturlig valg oppå nonstoparkitekturen.

 

Høres jo veldig fint ut, men jeg er redd opplegget ditt tryner når man må inn med eksempelvis verified by Visa dialog, slik som nå er vanlig ved nettkjøp. Da slipper man ikke unna transaksjonsbiten, og utsjekk må gjøres mot akkurat den type systemer jeg snakket om.

 

øh, nei man slipper ikke unna transaksjonsbiten, hva du nå måtte mene med det. ved netthandel må det til en transaksjon mot kortselskapet, med eller uten ymse verifisering. så langt henger du visst med. og hvis verifiseringen skal skje synkront. f.eks. i et webgrensesnitt (eller i en betalingsterminal i en butikk), så blir responstiden selvfølgelig viktig. hvis den ikke skal det så blir responstiden mindre viktig. ulike behov, nok en gang.

 

det såkalte "opplegget mitt" - som f.eks. kan være basert på en stack med java helt ned til databasenivå - klarer seg helt fint i et sånt scenario som du trekker fram. den tidskritiske verifiseringen som du snakker om foregår utenfor dette systemet, og de forretningskritiske transaksjonsene foregår *i* systemet ( ... også, verifiseringen hos kortselskapet er også kritisk. men jeg blir litt usikker altså, hva syns du f.eks. om reservasjon av beløp på kort? er det transaksjon i ditt snevre univers? penga flytter jo ikke på seg ... )

 

jeg må dessverre bare meddele deg at det såkalte "opplegget" mitt fungerer helt fint, javabasert og greier.

 

bedre lykke neste år.

Endret 30. desember 2010 av quantum

[Del]

Jeg har vel også ledet deg til hvilken hardware som typisk brukes i slike system, la meg gjenta:

http://h20338.www2.hp.com/nonstopcomputing/cache/76385-0-0-0-121.html

 

I det hele tatt tror jeg du vet absolutt ingenting om slike systemer, og hvor uaktuelt det er å kjøre java på de.

kan virkelig ikke se poenget ditt i det heletatt. du snakker muligens om en spesiell type transaksjonssystemer

Helt korrekt. Jeg snakker om de systemene alle verdens banktransaksjoner bruker. Sjekk når disse oppsettene fikk java-støtte. At det er mulig å kjøre javasnutter på dem i dag betyr ikke at det er spesielt aktuelt. Det ser forøvrig ut til at vi er ved veis ende i denne diskusjonen. Godt nyttår.

[quantum]

Helt korrekt. Jeg snakker om de systemene alle verdens banktransaksjoner bruker. Sjekk når disse oppsettene fikk java-støtte. At det er mulig å kjøre javasnutter på dem i dag betyr ikke at det er spesielt aktuelt.

 

hehe, du trasker videre ute på jordet . . . selvfølgelig kjører man forretningskritiske transaksjoner implementert i java på hp nonstop og tilsvarende arkitektur. og selfølgelig kjører ikke alle verdens banktransaksjoner på hardware a'la hp nonstop. mye kjører fortsatt på stormaskin, f.eks.

 

det innsnevra transaksjonsbegrepet du opererer med er helt meningsløst i denne diskusjonen, markedet består ikke kun av klient på den enesiden og realtime banktransaksjoner på den andre.

 

Det ser forøvrig ut til at vi er ved veis ende i denne diskusjonen. Godt nyttår.

 

takk det samme og bedre lykke i det neste.

[Del]

Nonstop er HP's stormaskin for de som krever høy oppetid Einstein. Det er akkurat disse stormaskinene som er skreddersydd for transaksjoner. De er et resultat av at HP tok over Tandem.

 

Ref. http://en.wikipedia.org/wiki/Tandem_Computers

 

Her har du noen definisjoner å kose deg med inn i det nye året:

http://en.wikipedia.org/wiki/E-commerce Legg spesielt merke til at disse systemene ikke klassifiseres som transaksjonssytemer, selv om de gjerne snakker med et transaksjonssystem. Her derimot:

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

er vel det nærmeste du kommer. Det ville til og med forundre meg om databasene du eventuelt koder mot er basert på Java.

[quantum]

Nonstop er HP's stormaskin for de som krever høy oppetid Einstein. Det er akkurat disse stormaskinene som er skreddersydd for transaksjoner. De er et resultat av at HP tok over Tandem.

 

Ref. http://en.wikipedia.org/wiki/Tandem_Computers

 

Her har du noen definisjoner å kose deg med inn i det nye året:

http://en.wikipedia.org/wiki/E-commerce Legg spesielt merke til at disse systemene ikke klassifiseres som transaksjonssytemer, selv om de gjerne snakker med et transaksjonssystem. Her derimot:

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

er vel det nærmeste du kommer. Det ville til og med forundre meg om databasene du eventuelt koder mot er basert på Java.

 

du linka nå engang til hps intelbaserte servere hvor hp støtter java. de er selvfølgelig fine å kjøre transaksjoner på, men du skjønner vel selv at ikke alle banker i verden kjører på denne arkitekturen?

 

igjen, det snevre transaksjonsbegrepet ditt har ingen relevans i diskusjonen din, java-markedet for oracle er langt større enn bare klient og de helt spesielle transaksjonene du snakker om. dermed er diskusjonen, som du selv skrev i forrige innlegg, over.

 

du må gjerne trekke inn begreper som soa, ecommerce, b2b, olap og blablabla, jeg sier bare jatakk, det er jo alt sammen illustrasjon av at det ikke er klientsiden som er det viktigste markedet for java.

 

og hvorfor i alle dager begynner du å tyte om javabaserte databaser? du er jo helt på bærtur, de har vel ingen rolle i det noen av oss snakker om?

 

nei, nå må du bare ta dine egne ord inn over deg og sette punktum.

[Del]

du linka nå engang til hps intelbaserte servere hvor hp støtter java. de er selvfølgelig fine å kjøre transaksjoner på, men du skjønner vel selv at ikke alle banker i verden kjører på denne arkitekturen?

Jo, dette er det beste eksempelet på den type arkitektur banktransaksjoner kjører på. Disse maskinene ble skreddersydd for formålet. Jeg blir sliten av å måtte gjenta for deg, så vennligst forsøk å følge med denne gangen, så skal jeg forsøke å gjøre det enda klarere. Disse systemene setter helt andre krav enn vanlige servere. Hvis et slikt system har nedetid et par timer, så lager det avisoverskrifter. Det fordrer et nivå av RAS som få systemer kan tilby, og spesielt har ikke x86 baserte systemer vært konkurransedyktige på dette tidligere. Dette kan endre seg fremover nå som siste generasjon x86 har fått mye av den samme RAS som topplinje stormaskiner kan tilby.

 

Les lenken jeg gir deg denne gangen, så slipper jeg å gi den til deg en gang til:

http://en.wikipedia.org/wiki/Reliability,_Availability_and_Serviceability

igjen, det snevre transaksjonsbegrepet ditt har ingen relevans i diskusjonen din, java-markedet for oracle er langt større enn bare klient og de helt spesielle transaksjonene du snakker om. dermed er diskusjonen, som du selv skrev i forrige innlegg, over.

Prøv å les hva du selv skriver her. Er det i det hele tatt mulig å forstå hva du mener? Når jeg forklarer deg at klientsiden også er viktig, så tolker du det dit at server ikke er viktig? Her skal jeg gjenta litt mer for deg, med en forklarende lenke:

http://no.wikipedia.org/wiki/Erasmus_Montanus

Les spesielt denne delen:

Bondesønn Rasmus Berg har blitt bekostet utdannelse i byen, og da han returnerer, snakker han latin til sine foreldre. Han vil også bare «disputere», og beviser senere at moren er en stein og at fyll er bra, ettersom fyll får en til å sove, den som sover synder ikke, ergo den som er full synder heller ikke. Han beviser senere at Per Degn er en hane.

du må gjerne trekke inn begreper som soa, ecommerce, b2b, olap og blablabla, jeg sier bare jatakk, det er jo alt sammen illustrasjon av at det ikke er klientsiden som er det viktigste markedet for java.

Nei, det forteller deg hvilke markeder på serversiden som er viktig for Java. Hvis du virkelig ønsker å vite hvilke server-laster Java typisk brukes til er det også ganske enkelt. Du skjønner SPEC tar mål av seg til å følge bruken av diverse laster på servere (ref. http://en.wikipedia.org/wiki/Standard_Performance_Evaluation_Corporation ). Der vil du kunne følge utviklingen av benker hvor Java er hoveddelen eller viktig. Disse finner du her:

http://www.spec.org/benchmarks.html#java

 

Hvis du titter litt der finner du at ecommerce er et slikt viktig marked. Legg spesielt merke til at transaksjonssystemer er nærmest fraværende, og i den grad de er med så er Java gjerne på management biten. En liten øvelse for deg er å sjekke hvor mange non-stop systemer som testresultater er tilgjengelige for.

og hvorfor i alle dager begynner du å tyte om javabaserte databaser? du er jo helt på bærtur, de har vel ingen rolle i det noen av oss snakker om?

Mange definerer database operasjoner som transaksjoner, men jeg forstår at du ikke er blant dem. Jeg antar videre at påstanden min da er bekreftet, du ser altså ikke Java baserte databaser i bruk hos noen av dine eksempler.

[quantum]

Jo, dette er det beste eksempelet på den type arkitektur banktransaksjoner kjører på.

 

noen banktransaksjoner kjører på den arkitekturen, mens andre ikke gjør det. banker er ganske konservative og mange transaksjoner prosesseres fortsatt på stormaskin f.eks. men det har jeg sagt før, og nå har jeg ikke noe behov for å gjenta det flere ganger.

 

Prøv å les hva du selv skriver her. Er det i det hele tatt mulig å forstå hva du mener? Når jeg forklarer deg at klientsiden også er viktig, så tolker du det dit at server ikke er viktig?

 

din påstand var at microsofts døende silverlight-teknologi var den viktigste årsaken til at sun åpnet java. min påstand er at jeg ikke tror det stemmer da java-markedet serverside er mye mer verdt og det begynner det å se ut som du også begynner å ta inn over deg. god start på det nye året, det.

 

Mange definerer database operasjoner som transaksjoner, men jeg forstår at du ikke er blant dem. Jeg antar videre at påstanden min da er bekreftet, du ser altså ikke Java baserte databaser i bruk hos noen av dine eksempler.

 

nok en gang, javabaserte databaser har ingen rolle i det vi diskuterer. hvor mange ganger skal vi gjenta det?

 

når det gjelder databaser generelt kan de definitivt inngå i det jeg mener med forretningskritisk transaksjonsprosessering, som forøvrig er noe helt annet enn du legger i begrepet.

[Del]

noen banktransaksjoner kjører på den arkitekturen, mens andre ikke gjør det. banker er ganske konservative og mange transaksjoner prosesseres fortsatt på stormaskin f.eks.

OK, la meg prøve en gang til. Så enkelt som jeg overhodet kan få det til:

1. HP's non-stop er ikke den eneste, men det er det beste eksempelet. IBM har naturligvis en konkurrent i dette markedet også. Les mer om det produktet her:

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

les til øyene dine blir våte om Java-støtten hos IBM.

2. Sannsynligvis kjører alle vesentlige banktransaksjoner i verden på denne type systemer av åpenbare grunner som jeg allerede har forklart deg i klartekst i forrige post.

3. Dette er stormaskiner. Dette er kremeksempler på stormaskiner. Gettit? Når folk du møter referer til stormaksiner er det akkurat slike (eller beslektede systemer med mindre RAS) det er snakk om.

din påstand var at microsofts døende silverlight-teknologi var den viktigste årsaken til at sun åpnet java. min påstand er at jeg ikke tror det stemmer da java-markedet serverside er mye mer verdt og det begynner det å se ut som du også begynner å ta inn over deg.

Når du spurte, sa jeg

Silverlight er siste skudd fra MS for å fremme .net. I det ligger det en umiddelbar erkjennelse av at det er den siste i en rekke skudd mot Java, hor .Net er rammeverket som skal ta Java. Klientsiden representert ved blant annet Android i dag, viser at klientsiden er viktig. Akkurat hvor viktig klientsiden er trenger du litt større briller for å se. Både Canonical og Microsoft innså tidlig at veien til serverrommet gikk via klient. Sun gjorde også i stor grad det, noe som vises ved satsingen på OpenOffice (hvor bruk av Java faktisk har vært omdiskutert, en liten interessant avsporing). Uten klientsiden tror jeg Java ville gått en sakte død i møte, så ja, jeg mener klientsiden faktisk er viktigst.

Endret 1. januar 2011 av Del

[doloop]

noen banktransaksjoner kjører på den arkitekturen, mens andre ikke gjør det. banker er ganske konservative og mange transaksjoner prosesseres fortsatt på stormaskin f.eks.

OK, la meg prøve en gang til. Så enkelt som jeg overhodet kan få det til:

1. HP's non-stop er ikke den eneste, men det er det beste eksempelet. IBM har naturligvis en konkurrent i dette markedet også. Les mer om det produktet her:

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

les til øyene dine blir våte om Java-støtten hos IBM.

2. Sannsynligvis kjører alle vesentlige banktransaksjoner i verden på denne type systemer av åpenbare grunner som jeg allerede har forklart deg i klartekst i forrige post.

3. Dette er stormaskiner. Dette er kremeksempler på stormaskiner. Gettit? Når folk du møter referer til stormaksiner er det akkurat slike (eller beslektede systemer med mindre RAS) det er snakk om.

din påstand var at microsofts døende silverlight-teknologi var den viktigste årsaken til at sun åpnet java. min påstand er at jeg ikke tror det stemmer da java-markedet serverside er mye mer verdt og det begynner det å se ut som du også begynner å ta inn over deg.

Når du spurte, sa jeg

Silverlight er siste skudd fra MS for å fremme .net. I det ligger det en umiddelbar erkjennelse av at det er den siste i en rekke skudd mot Java, hor .Net er rammeverket som skal ta Java. Klientsiden representert ved blant annet Android i dag, viser at klientsiden er viktig. Akkurat hvor viktig klientsiden er trenger du litt større briller for å se. Både Canonical og Microsoft innså tidlig at veien til serverrommet gikk via klient. Sun gjorde også i stor grad det, noe som vises ved satsingen på OpenOffice (hvor bruk av Java faktisk har vært omdiskutert, en liten interessant avsporing). Uten klientsiden tror jeg Java ville gått en sakte død i møte, så ja, jeg mener klientsiden faktisk er viktigst.

 

#1)

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

 

#2)

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

 

JAVA

OS

HARDWARE

 

ikke

 

JAVA

HARDWARE

 

For litt enklere løsninger enn top 500 maskiner(ingen banker kjører top500 maskiner for banktransaksjoner) har jo iBM også JBOSS, en applikasjons-server som out of the box tar seg av clustering uten noe hassel for utvikler. Det å prosessere banktransaksjoner er ei heller noe som er ekstremt ytelseskrevende (i forhold til feks simulasjoner)

 

Du kan nå nyte godt av java sin parallellprogrammering (nå har vi jo Clojure også) i motsetning til C.

 

#3)

Du ser veldig bekymret ut over transaksjonstid, eg vet ikke om du har hørt om JRockit jeg? Transaksjonstid vil typisk ikke bety noe når det er IO involvert. Det er snakk om at java out of the box ikke egner seg på programmer som krever nøyaktighet på millisekundet, ikke for nettverkstransaskjoner.

 

#4)

Disse diskusjonene har da ingen ting med den originale diskusjonen: Er java et tregt språk?

 

Til det svarer jeg fortsatt:

 

Nei java er ikke et tregt språk. Det kan konkurrere med c/c++ kode, dog jeg innrømmer i de fleste tilfeller vil c++ kode yte noe bedre på enkle operasjoner, men du kan finne eksempler der JIT vil la java faktisk slå den. Sitter du å bruker oljefondet på utvikling av programmet kan du sikkert klare å optimalisere koden perfekt i c, eller kanskje bare skrive alt i assembly? Vi må holde oss til den virkelige verden dog.

 

Den enorme fordelen med java fremfor c og c++, som også er hvorfor det er et av de språkene med mest aktivitet i dag [1], er at det har betydelig lavere utviklingskostnader. Parallellprogrammering er ikke enkelt i noe språk, men java gjør det ihvertfall enklere enn c og c++. Jeg sier ikke at java vil knuse c eller c++ kode (eller c#), jeg sier at det ikke er et tregt språk.

 

1 = http://lang-index.sourceforge.net/