Java Programmering.

I C/C++ når du bruger #include, siger du til preprocesseren at den skal kopiere indholdet fra filen ind. Når du skriver import i Java siger sker der ikke sådan en kopiering, i stedet fortæller du compileren/runtimen hvor den finder afhængigheder henne.

Lad os sige du står i mappen X i kommandolinjen. I X har du mappen A og B, samt jar-filen other-library.jar. Mappen B og jar-filen er tredjepartsbiblioteker som du bruger. Der ser sådan her ud:

X\A\org\wunderstrudel\webstuff\Program.java
X\A\org\wunderstrudel\webstuff\Optimisme.java

X\B\org\third-party\AwesomeWebSocketServer.java
X\B\org\third-party\AwesomeWebSocketServer.class

X\other-library.jar

Du vil gerne køre X\A\org\wunderstrudel\webstuff\Program.java som har en main-metode. Inde i Program.java har du linjerne:

package org.wunderstrudel.webstuff;

import org.third-party.*;
import org.venture.insanity.*;

Den første siger hvilken pakke (package) Program-klassen hører til og skal passe med mappestrukturen. Den anden linje med import referer til at du har brug for java kode i pakken org.third-party (som ligger i X\B), og den tredje at du har brug for kode fra en anden pakke (ligger i .jar-filen). Først skal du kompilere dine .java filer til .class filer, hvilket allerede er gjort for X\B\*. Men dit kode i X\A bruger X\other-library.jar samt kode fra X\B så du skal huske at sætte din classpath.

Så du kører kommandoen

javac -classpath "X\B;other-library.jar" "X\A\org\wunderstrudel\webstuff\*.java"

for at kompilere din .java filer til .class filer (på Mac/Linux skal du bruge forward slash og ':' i stedet for ';' som separator).

Nu har du alt koden kompileret og vil gerne køre det. Så skal .class path være det samme, men nu også inkludere dit kode Program.java, og du skal skrive stierne til pakkerne i 'classpath':

java -classpath "X\A;X\B;other-library.jar" org.wunderstrudel.webstuff.Program

Baseret på classpath og mappestrukturen finder java og kører dit program.

Dette kan godt blive bøvlet og vi har egentlig computere til at automatisere sådan noget for os, så find en måde at automatisere det på i Sublime. Jeg bruger selv Sublime, også til C++, men til Java udvikling foreetrækker jeg et IDE.


Til dit andet spørgsmål:

Det smarte ved WebSockets er det giver tovejskommunikation hvilket almindelig HTTP ikke giver. Hvad der ville være mest effektivt afhænger af dine behov. Men givet at du overvejer WebSockets, er det som dan siger bedre at bruge en asynkron teknologi som f.eks. node.js. En typisk PHP/Apache kombo, f.eks., er bedre til cpu-tunge requests. Du har X-handlers: hver handler kan acceptere et request, laver noget data-behandling, sende et svar, og er så klar til et nyt request. Men hvis forbindelserne varer længe, som med WebSockets, bliver alle dine handlers hurtig optaget og ingen kan forbinde. Dette problem har node.js ikke fordi det fungerer på en anden måde, og kan derfor have flere tusinde forbindelser på samme tid. Du kan dog også finde servere med samme principper some node.js i andre sprog, f.eks. Netty til Java.

Go er objekt orienteret, men det fungerer ikke på samme måde som Java/C#/C++, men der er både arv/polymorfi, data indkapsling, data hiding, tilstand/opførsel, og alt andet der giver objekt orientering.

WunderStrudel, er det fordi du vil lære, hvordan netværksprogrammering fungerer og derfor vil forsøge dig med at lave en webserver (med websocket understøttelse) fra bunden? For det er en glimrende ide! No, really, jeg mener det. Jeg har selv gjort det, endda i forbindelse med mit arbejde hvor jeg er backend udvikler i et spilfirma og alle vores spil snakker med backend via websockets, hvor jeg så har lavet den del, der tager imod web protokol delen.

Det er dog noget, som tager en del tid at gøre, og vil du lave et reelt produkt, så giver det mere mening at bygge på noget, som allerede fungerer. Som dan foreslår, så er node.js og Go ganske glimrende alternativer.

Men skal det absolut være Java så kig på Java NIO som giver dig netværks multiplexing (ala select()/poll() i C). Derefter på HTTP protokollen generelt og så websocket protokollen i særdeleshed.

hvis det skal være til meget rest / async håndtering. Ville jeg næsten foreslå node.js frem for Java.

Tusind tak for svarene begge to!
Det var lige præcis hvad jeg var ude efter Søren, det kommer til at gøre mit liv noget nemmere! Grunden til at jeg har holdt mig fra node.js indtil videre er, at jeg typisk gerne skrive "min egen udgave" af tingene, før jeg begynder at bruge standarderne. Jeg synes det gør at jeg får noget mere ud af det, hvis jeg er 100% sikker på at jeg kan det hele på rygraden. Så det er egentlig fordi jeg er i søgen efter at lave noget, som tillader mig noget alle det samme som node.js, men hvor jeg selv får lov til at skrive node.js delen. (I meget simpel udgave ift. selfølgelig).

Lyder lidt som om du misforstår hvad node.js er? node.js er bare javascript. Der kan du bygge hvad du vil, fra bunden. Eller du kan bygge oven på eksisterende frameworks. Som Meteor eller Express.

ye ved ikke meget om node.js, jeg ved hvad det bruges til, men ikke meget om hvordan. Jeg kiggede en gang for nogen tid siden lidt i deres src code, og som det så ud så køre det kun igennem AJAX/websocket ikke? Det er i hvert fald det jeg synes at kunne huske, og da jeg gerne ville væk fra ajax så virkede websockets, som det bedste alternativ, og tænker at hvis man skal bruge websockets i node.js så skal man vel også bruge en/deres socket server?
Igen det er ikke meget jeg har kigget ind i det, så aner ikke så meget om det, men tænkte at jeg hellere ville lære at skrive min egen socket server istedet. Jeg tror stærkt på at genopfinde den dybe tallerken d:

Du har ret, du ved ikke hvad node.js er. Jeg kunne godt tænke mig at vide hva det er for en socket server du snakker om du har set sourcecode til.

Et alternativ til både java og node.ja kunne være Go eller Golang som det også kaldes. Det skulle være både hurtigere end begge.

Det var da en ekstremt nedladende og umoden måde at besvare på, men dig om det.
Hvis ikke du har lyst til at være konstruktiv, men bare er her for at have en pisse konkurrence. Så spilder du squ både min, og din egen tid. (:

Til den del hvor du ren faktisk er halvt konstruktiv, så har jeg kigget på Go tidligere, men bryder mig ikke om ikke at have OOP, men kan ikke sige at jeg ikke kommer til at kigge videre på det senere. Det er dog ikke så meget et sprog jeg er ude efter, men mere hvor jeg kan finde noget om, hvad jeg skal gøre med sprogene. Det kan være relativt svært at finde noget om, hvordan man skriver evt. en node/server i java, og laver en tilsvarende client i browseren. Uden at bruge noget som fx. node.js. Er ikke lige pt. ude efter en roman af en forklaring men mere pointers til hvor jeg kan finde mere om det. (:

Jeg er lidt ked af du mener det er nedladende, det var mere en konstatering. For mig er det ikke en pisse konkurrence, men på den måde du skriver dine indlæg virker din viden meget tilfældig. Som i den sidste. Hvor sidste skriver at du ikke vil Golang fordi det er OOP. Men du vil gerne Java, som også er rent OOP. Så mange af tingene du siger giver ikke helt mening.

Som udgangspunkt med wevsockets vil man næsten altid have en webserver til at stå og tage imod requests og oprette forbindelsen mellem serverside og klienten. Hvilket sprog webserveren så starter må være op til dig.

Med nogle sprog har du dog muligheden for at implementere selve webserveren også. F.eks. Java, Go, Node.js, men det ville man nok ikke gøre i PHP. Men det giver nok heller ikke mening i forhold til de andre sprog, da du så skal have gang i den helt store trædemølle.

De fleste sprog har dog et library eller noget til at opbygge websocket forbindelser, og det er her jeg vil foreslå du starter.

Dan jeg har en teori om at du enten "skimter" mine beskeder, eller ikke forstår mine dobbelt negativer. Jeg siger at jeg ikke har lyst til at bruge Go fordi det ikke er OOP som så, men er baseret på structs i stedet. Jeg elsker mine classes, og jeg elsker at være i stand strukturerer min kode på den måde. Det er dog igen et område hvor jeg ikke har lavet voldsomt meget research da jeg har haft focus på andre ting. Plus jeg prøver på ingen måde at være negativ. Jeg er her kun for at lære fra jer, hvilket også er grunden til at eg kommenterede tidligere. Da jeg virkelig kun kan bruge det konstruktive til noget, og jeg tolkede det som nedladende pga. "opsætningen". (:

Så man ville fx. lave en MVC REST api i Java, og response med json/xml, eller ville det være en forkert tilgang? Har leget lidt med sockets i Java, men er ikke sikker på hvordan man typisk ville opbygge sådanne server applications, og alt jeg har kune finde på det har være tomcat eller node.js osv.

Igen tak for svarene. (: