Oracle: Derfor er Java relevant for Internet of Things

Knaphed på udviklere til indlejrede systemer og muligheden for at bruge den samme platform på mange typer enheder er de kvaliteter, som skal sikre Java en plads i Internet of Things.

Idéen om milliarder af enheder, som kommunikerer med hinanden via internettet, er en idé, som var en del af grundlaget for udviklingen af programmeringssproget Java og den tilhørende platform. Det var i begyndelsen af 1990'erne, men det er først nu, at 'Internet of Things' for alvor ser ud til at stå over for sit gennembrud.

Det rejser spørgsmålet om, hvorvidt Java stadig er relevant som platform for alt fra termostater til det berygtede intelligente køleskab? Især set i lyset af, at Java også var udset til at danne grundlaget for smartphones.

»Smartphones er drevet af forbrugerefterspørgsel, så Apple-modellen med en integreret stak fra chips over styresystem til apps var nærmest et krav for at kunne levere oplevelsen af at være let at bruge. Internet of Things vil ikke være drevet af forbrugerne, men vil mere minde om det, vi ser i store virksomheder. Det vil være nødvendigt at indgå i økosystem, så det vil ikke være ét firma, der bygger det hele fra grunden,« siger Amit Jasuja, chef for produktudvikling for Java, mobil sikkerhed og identitetsstyring hos Oracle, til Version2.

Pointen er ifølge Amit Jasuja, at enhederne i Internet of Things skal kunne fungere sammen og passe til allerede eksisterende systemer. Eksempelvis skal et parkometer kunne tale med kommunens økonomisystem og gøre det muligt for bilisterne at betale for parkering via en mobil-app.

Når kommunen skal udvikle og vedligeholde systemet, så vil det ifølge Oracles ræsonnement være mere oplagt at vælge en platform som Java, der har flere redskaber til at integrere med andre systemer, end eksempelvis at basere parkometret på software skrevet i C eller assembler.

Ikke mindst fordi alternativet vil være at skulle slås om de udviklere, som er vant til at arbejde med de sprog, som i dag anvendes i indlejrede systemer.

»Hvis der i dag findes en milliard kodelinjer i forskellige indlejrede enheder, og der om 3-5 år skal være 10 milliarder kodelinjer, så vil det lægge enormt pres på økosystemet, hvis det ligesom i dag skal skrives i C, assembler eller direkte til chippen. Det vil skabe et pres for at gå over til et højniveausprog som Java,« siger Amit Jasuja.

Skal arbejde på sikkerheden

Han erkender dog, at selvom Java er udviklet til at blive brugt i indlejrede systemer og allerede bruges i mange forskellige enheder, så er der stadig et stort stykke arbejde på Oracles bord.

»Vi har mere arbejde foran os inden for blandt andet sikkerhed. Vi skal også understøtte flere protokoller, og så skal vi udbygge en hel cloud-platform med tjenester til at understøtte Internet of Things,« siger Amit Jasuja.

Sikkerhed er ikke nødvendigvis noget, de fleste brugere forbinder med Java på grund af de omfattende problemer, der har været med Java-pluginet til browsere. Det er dog en lille niche af Java-universet, som ikke nødvendigvis afspejler sikkerheden i de indlejrede systemer.

Javas runtime-miljø understøtter således muligheden for at signere og opdele applikationer, så kun nogle udvalgte får adgang til systemet. Det kan selvfølgelig være sårbart i tilfælde af sikkerhedshuller, men den basale arkitektur for sikkerhed eksisterer i et vist omfang.

Netop sikkerhedshuller i både platformen og den software, som kører på den, er faktisk også blandt Oracles argumenter for at anvende Java. Der er nemlig også en platform på plads for udrulning af opdateringer, hvilket ikke nødvendigvis er tilfældet for visse af de platforme som findes i eksisterende sensorer.

Men opdateringer giver også andre muligheder i forhold til chips, hvor softwaren ligger fast fra fabrikken.

»Når først du har brændt koden ind i chippen, så har du begrænset enhedens levetid. Med en runtime som Javas kan du opdatere softwaren efterfølgende,« siger Amit Jasuja.

Dermed vil man altså ifølge Oracle kunne give en enhed længere levetid, fordi softwaren vil kunne følge med udviklingen.

Skalere fra chipkort til servere

Flere af disse argumenter er imidlertid også gældende for mere komplette styresystemer, som også er i spil til enhederne i Internet of Things. Det gælder især varianter af Linux og lignende styresystemer, som også findes til indlejrede systemer.

»Fordelen ved Java i forhold til eksempelvis Linux er, at vi kan gå fra noget, der kan ligge på en chip på et kreditkort, hvor hverken Google eller Microsoft har noget, der kan komme i nærheden, og op til lidt større sensorer med Java ME og helt op til Java SE,« siger Amit Jasuja.

Den fleksibilitet er ét af de væsentligste kort, som Oracle mener at have på hånden i forhold til Internet of Things. Udfordringen lige nu er dog, at selvom Java er på markedet, så er der ikke mange af den type enheder, som er en del af Internet of Things anno 2014, som kører Java. Og det er en udfordring for Oracle.

»Hvis du for eksempel vil lave en elpære med indbygget sensor, så vil du formentligt bruge chips fra én eller flere leverandører, som der findes mange af. Men spørgsmålet er, om vi har en Java-udgave, der er kompatibel med netop de chips. Det er en udfordring,« siger Amit Jasuja.

Omvendt kan det falde ud til Oracles fordel, hvis selskabet kan tilbyde producenterne af enhederne mulighed for at vælge mellem flere chipleverandører, uden at skulle ændre programkoden til deres applikationer.

Et helt afgørende spørgsmål er dog, om tiden virkelig er moden til det Internet of Things, som der har været talt om siden Javas barndom?

»Det sker allerede og er drevet af effektivisering. Hotellets minibar kan se, hvilket stykke chokolade du tager og trække det fra dit kreditkort. Den slags er mikrotransaktioner, som vil være forfærdeligt dyre, hvis du skal blande mennesker ind i det,« siger Amit Jasuja.

Tilsvarende er det oplagt at gøre større brug af billige sensorer til at spare energi ved eksempelvis kun at oplyse de dele af en kontorbygning, hvor der opholder sig folk.

Det næste skridt vil ifølge Amit Jasuja være at kombinere det hele via cloud-tjenester, så hvert enkelt element ikke er et selvstændigt, lukket system, men kan indgå i et netværk med andre enheder.

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Kommentarer (21)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Chris Bagge

Der er mange der tænker på moderne mobiltelefoner, når man tænker på IoT, men når det først rigtigt bliver 'Things' så melder virkeligheden sig. Man kan sagtens lave en masse spændende ting f.eks. med en Raspberry Pi, men når der pludselig kun er microAmpere og kilobyte til rådighed, så ender man nede i 'C' igen.

  • 3
  • 0
Kenn Nielsen

Og når alle IoT devices laves til java, - hvormeget Oracle-Skat skal vi mon så ende med at betale ?

K

Edit; mellemregning tilføjet:
Skal ses i lyset af Oracle vs Google, om Copyright på API.

  • 0
  • 0
Casper Paulsen

Ingen? Hvis de gør det så dør Oracle/Java med det samme og JVM'en bliver forked ligesom den er nu i OpenJDK, og vi vil se alle de sprog der køre på JVM få et kæmpe boost, om end de ikke allerede gør det nu.

  • 1
  • 0
Christian Nobel

Jeg kan heller ikke se meningen i at proppe et kæmpe overhead ind i form af mange megabyte runtime engine, udelukkende for at kunne tænde og slukke en lampe, hvilket kan klares med få liniers assembler.

Og taler vi ultra low power devices, som f.eks. MSP430, så giver det ingen mening.

  • 1
  • 0
Kenn Nielsen

Ingen? Hvis de gør det så dør Oracle/Java med det samme og JVM'en bliver forked ligesom den er nu i OpenJDK, og vi vil se alle de sprog der køre på JVM få et kæmpe boost, om end de ikke allerede gør det nu.

Hmm..måske jeg har misforstået noget, men...

Hvis API'et anses for proprietært, men åbent, er det vel ligemeget hvor mange kloner der er, hvis de alle skal benytte det proprietære API ?

K

  • 0
  • 0
Martin Brandt

Det var også en del af min fantasi, men de bitte små enheder får også flere muskler. Jeg kan jo bare kigge på den telefon jeg har i hånden nu. Fjernede man alt det unødvendige, skærm, kamera lys og behov for ui/ux kunne man have en rimelig potent lille enhed. Kigger jeg på den 'gamle' der ligger i skuffen kan jeg jo se en udvikling som går temmelig hurtigt og der er jo i princippet ingen der siger at Java Runtime bliver ved med at være en stor klump. Det kan måske også i fremtiden skalere og deles op i relevante libraries som kan kaldes efter behov.

Men det er jo bare min fantasi :-)

  • 0
  • 0
Martin Brandt

Det var også en del af min fantasi, men de bitte små enheder får også flere muskler. Jeg kan jo bare kigge på den telefon jeg har i hånden nu. Fjernede man alt det unødvendige, skærm, kamera lys og behov for ui/ux kunne man have en rimelig potent lille enhed. Kigger jeg på den 'gamle' der ligger i skuffen kan jeg jo se en udvikling som går temmelig hurtigt og der er jo i princippet ingen der siger at Java Runtime bliver ved med at være en stor klump. Det kan måske også i fremtiden skalere og deles op i relevante libraries som kan kaldes efter behov.

Men det er jo bare min fantasi :-)

  • 0
  • 0
Frithiof Andreas Jensen

Java kan ingenting i det marked. En embedded controller er præcis som en iPhone: 95% af koden kommer med chippen, der er et API som applikationskoden kalder. I en chip til 5 USD er der ikke plads til noget Oracle IP - selv hvis det virkede til formålet. Derfor ender java på anvenderen.

Der er forhåbentlig ingen det vil betale en licens for en JVM blot for at kunne lægge 1000 linier java oveni. Python, Lua, et cetera løser den slags små opgaver direkte i modsætning til java som et overkompliceret og bureaukratisk. Det giver ingen værdi overhovedet at man kan signere og manage kode i en dims som er smidt væk om fem år og i øvrigt aldrig vedligeholdes.

  • 1
  • 0
Christian Nobel

Det var også en del af min fantasi, men de bitte små enheder får også flere muskler.

Jo jo, men i det store hele er det meste på chippen (det vigtigste er faktisk en netværkssstak) som Frithiof siger, så tilbage står at afvikle få hundrede eller tusinde liniers kode.

Og så en meget væsentlig pointe - IOT dimser må på ingen måde bruge strøm på samme måde som en telefon, vi taler micro Ampere, og at de skal kunne holde i flere år på en knapcelle, hvilket ikke de første par tusinde år er foreneligt med en Java Runtime Engine.

  • 0
  • 0
Hans Schou

Hvis du for eksempel vil lave en elpære med indbygget sensor

Jeg ville pt lave prototypen med en Arduino Leonardo, og kan ikke helt se hvordan den skulle kunne masseproduceres billigere med Oracle/Java, kontra en ATmega32u4/C. Hvis man skal vælge andet end C til et micro/embedded projekt, så skal der være meget vægtige grunde der gør det.

  • 0
  • 0
Thomas Peter Berntsen

Ja, helt enig.

For os har det fungeret godt at køre flere af vores projekter med en Arduino-baseret prototyping af funktionalitet og interaktion for så herefter at vælge en ATmega-controller med de relevante karakteristika, hvortil funktionaliteten evt. genimplementeres i ren C (især hvis der skal være megen vægt på at styre kredsløbets kørselstilstande/strømforbrug).

  • 0
  • 0
Log ind eller Opret konto for at kommentere