18 svar · 596 visningar · startad av The_L
Skrev ett liknande inlägg förut, men den är nu lite förenklad.
1.Är det nån som vet om det går att skicka serializerade java- objekt som skickas via bytevektorer o ta emot dessa i c? Vanlig c alltså, inte c++. Utan att ha nån sorts middleware.
2. Om detta inte är möjligt, går det att skicka serializerade strängar i bytevektorer o ta emot dessa i c? Även här vanlig c och utan middleware.
3. Om detta inte heller är möjligt. Vad kan man då använda sig av? Nån som har försökt?
Sök på Corba så har du svaret...
Handlar om sockethantering så ja, det ska gå.
XML-RPC är ett alternativ också...
http://xmlrpc-c.sourceforge.net/
http://ws.apache.org/xmlrpc/
Utan "middleware" lär det inte gå. Ivf om du menar java(bytekod) -> C (maskinkompilerad & klar). Det fallerar iom hur exekvering sker (JVM != cpu). Så det blir till att 'workaround' som ovan redan föreslaget.
PeW, du har fel.
Alla programspråk jag känner till klarar på ett eller annat sätt av att hantera byteströmmar, från fil, tangentbordsinmatning, sockets eller liknande.
Att skicka en ström med ettor och nollor är trivialt, det är tolkningen av dessa som kan ställa till problem. Att säga att det inte går att kommunicera mellan maskinkompilerad kod och Java-kod, som för övrigt görs om till maskinkod i JVM:en, är något som nomalt bara personer som inte kan Java eller som förespråkar något annat programspråk tar till för att dissa Java.
Ta exemplet med Tomcat Server och IE. Det är inte några som helst problem att anropa en webbserver skriven i Java från en browser skriven i C, C++...
Allt handlar alltså om hur man tolkar den byteström som kommer farande. Skillnaden mellan en sträng och ett objekt är att en sträng är ett objekt som man vet bara innehåller text. Sedan ansluter jag mig visserligen till Spango och säger att det finns så många som redan har skapat bra ramverk för att skicka data fram och tillbaka så det är dumt att uppfinna hjulet en gång till.
Länkar?
Undrar om Lime kanske har några länkar där man kan kolla det här om att ta emot byteströmmar. Vore jäkligt bra i så fall.
//The_L
Lime skrev:
PeW, du har fel.
Alla programspråk jag känner till klarar på ett eller annat sätt av att hantera byteströmmar, från fil, tangentbordsinmatning, sockets eller liknande.
Att skicka en ström med ettor och nollor är trivialt, det är tolkningen av dessa som kan ställa till problem. Att säga att det inte går att kommunicera mellan maskinkompilerad kod och Java-kod, som för övrigt görs om till maskinkod i JVM:en, är något som nomalt bara personer som inte kan Java eller som förespråkar något annat programspråk tar till för att dissa Java.
Ta exemplet med Tomcat Server och IE. Det är inte några som helst problem att anropa en webbserver skriven i Java från en browser skriven i C, C++...
Allt handlar alltså om hur man tolkar den byteström som kommer farande. Skillnaden mellan en sträng och ett objekt är att en sträng är ett objekt som man vet bara innehåller text. Sedan ansluter jag mig visserligen till Spango och säger att det finns så många som redan har skapat bra ramverk för att skicka data fram och tillbaka så det är dumt att uppfinna hjulet en gång till.
Nej jag har inte fel. Det du radar upp är med i det redan omtalade "middleware" -et.
För att i en vanlig stackmaskin på lågnivåbasis läsa ut vad en javabytesekvens innebär behövs en tolkning av av detsamma. Om du skriver en metod i Java så är inte det per definition för bitmönster, detsamma som en funktion i C eller en procedur i assembler. Instruktionerna för en JVM är inte desamma som för en cpu och det är därför det behöver konverteras - genom "middleware"-et.
Vidare så är den vanliga läsningen av strömmar på operativsystemsnivå varvid JVM:et och vilket annat för operativet kompilerat språk somhelst kan kommunicera, eftersom de begagnar sig av de för operativet uppbyggda systemanropen och kommunikationsmekanismer för processer.
Det du skriver om är på en högre nivå än vad jag menade och på den nivån ter sig det jag skriver som dolt - under huven. :)
Det är skillnad på att vilja och kunna ta emot byteströmmar. Java har ju väldigt behagliga serialiseringsfunktioner, men de är inte så sexiga att prata direkt med i något som inte rullar på en JVM (t.e.x. ett C-program).
Annars kan du ju alltid använda t.ex. DataOutputStream som du kopplar till en socket (för jag antar att det är på två olika burkar programmen rullar?) för att skriva primitiva datatyper direkt, men eftersom C och Java normalt har olika ordning på byten i datatyper större än en byte måste man då vända på dem (inte så svårt att göra med bitskiftning, egentligen, men det är bra att vara medveten om det :) ).
At skicka strängar är ju förstås det enklaste. Eller, egentligen inte, men det är minst lågnivåmeckande (och därmed inte lika skoj ;) ). Det är bara att koppla t.ex. en PrintWriter till en socket och köra.
Vilket som är bäst för dig är som vanligt svårt att svara på utan lite mer vetskap om hur applikationerna är tänkta att funka, vilka krav som finns et.c.
PeW skrev:
Nej jag har inte fel. Det du radar upp är med i det redan omtalade "middleware" -et.
För att i en vanlig stackmaskin på lågnivåbasis läsa ut vad en javabytesekvens innebär behövs en tolkning av av detsamma. Om du skriver en metod i Java så är inte det per definition för bitmönster, detsamma som en funktion i C eller en procedur i assembler. Instruktionerna för en JVM är inte desamma som för en cpu och det är därför det behöver konverteras - genom "middleware"-et.
Vidare så är den vanliga läsningen av strömmar på operativsystemsnivå varvid JVM:et och vilket annat för operativet kompilerat språk somhelst kan kommunicera, eftersom de begagnar sig av de för operativet uppbyggda systemanropen och kommunikationsmekanismer för processer.
Det du skriver om är på en högre nivå än vad jag menade och på den nivån ter sig det jag skriver som dolt - under huven. :)
Jo, jag hävdar fortfarande att du har fel i påståendet "utan midleware lär det inte gå" eftersom midlewaret gör exakt det som du påstår inte går... nämeligen översätter från Java-bitströmmar till maskinläsbara strömmar som kan tas emot av t.ex C/C++.
Har själv implementerat ett par JVM:er för olika processorer för inbyggda system och där är just detta med att översätta bitströmmar från java till processorn det som brukar ta längst tid att få rätt.
För du har rätt i att det är ett litet helvet och det är mycket lättare att skaffa sig ett middleware som gör det åt en.. :-)
Kan ni sluta klyva hår och jämföra äpplen och päron nu, tack? Det är väl rätt uppenbart att det inte går att göra något i Java utan en JVM, så vi kan väl rätt enkelt dra slutledningen att vad The_L menade med middleware inte innefattade JVM:er.
Sure... forumet klarar sig bra utan diskussioner.
Lime.
Jag tror att vi menar olika saker med "middleware". Jag menar att man inte kan direkt mappa javabytekod (exempelvis en class eller metod) till något begripligt för ett vanligt c-program utan att göra nån form av wrap. Denna "wrap" kan ju bestå i redan utvecklade rutiner/api:er eller så skriver man en egen för just den appsen. Ivf, så behövs det minst ett mellansteg hur man än vrider och vänder på det :)
Det instämmer jag fullständigt med PeW.
Tillvägagångssättet när man håller på med den här typen av problematik är att först bestämma sig vilket protokoll eller standard man ska använda sig av; XML, SOAP, Corba, valfritt 3GPP-protokoll... och sedan bestämma sig för om man ska hacka allt själv enligt spec eller köpa från någon annan.
Men i praktiken är det inte så jäkla svårt att få en java-applikation och en C-applikation att prata med varandra bara tråkigt och det finns lyckligtvis andra som tycker att det är kul att kunna ta betalt för att ha gjort just det tråkiga jobbet.
Lyckat test men...
Spango skrev:
At skicka strängar är ju förstås det enklaste. Eller, egentligen inte, men det är minst lågnivåmeckande (och därmed inte lika skoj ). Det är bara att koppla t.ex. en PrintWriter till en socket och köra.
Jag testade att använda mig av en printwriter och skickade en sträng till en c-klient från java. C-klienten skrev ut det utan problem. Samma sak när jag använde mig av en int, men det beror väl på att printwriter gör om int:en till en sträng innan den skickar över den. Så just den delen fungerar alltså. Nu är det tänkt att vi ska skicka över en bytevektor till c istället. Någon som vet vilken sorts ström man ska använda i java för att skicka byteströmmar? Använder man printwriter så tolkar den bytesen som nån text bara. Och vad jag förstår så är det en chararray man ska använda för att ta emot bytevektorn i c.
//The_L
Men vad är en text? Jo, en sekvens av byten vilka formar läsbara ord som är terminerade med 0. För att kringgå termineringen vid 0 kan du ju öka på värdet av varje byte som är 0 till _annat_tecken_, för att uppnå ej avbrytna sekvenser. Sen är det bara att göra det omvändna i andra ändan. Dvs göra om _annat_tecken_ till 0.
Kanske inte alls löser det du vill eller frågar efter, men kan vara ett sätt att kringå problematiken med strängar vs bytesekvenser. Gäller väl även då att beakta skillnaden mellan unicode och char, ifall printWriter föredrar unicode - menar jag.
Re: Lyckat test men...
Någon som vet vilken sorts ström man ska använda i java för att skicka byteströmmar? Använder man printwriter så tolkar den bytesen som nån text bara. Och vad jag förstår så är det en chararray man ska använda för att ta emot bytevektorn i c.
Du kan t.ex använda dig av en BufferedOutputStream och metoden write(byte[] b) som BufferedOutputStream ärver från FilteredOutputstream.
Uppfattat
sgtpepper skrev:
Du kan t.ex använda dig av en BufferedOutputStream och metoden write(byte[] b) som BufferedOutputStream ärver från FilteredOutputstream.
Ok, ska testa det då. Tack igen!
//The_L
