[Java] Waarom main(String[] args)?

[Verwijderd]

Wat ik me al een tijdje afvraag: Stel je hebt een applicatie. Op het moment ziet die er zo uit.

code:

class Test
{
   public static void main(String[] args)
   {
    System.out.println("Hallo wereld");
   }
}

Wat is de reden dat ze hier voor die main() methode gekozen hebben, waarom niet gewoon een constructor?

code:

class Test
{
   public Test(String[] args, InputStream in, PrintWriter out)
   {
    out.println("Hallo wereld");
   }
}

Dat is toch veel logischer? Daarmee kun je ook makkelijk een programma eromheen schrijven die meerdere java applicaties in 1 JDK kan draaien. Verder is het een stuk natuurlijker naar mijn idee. Er zal wel iets achter zitten, maar ik zie het zo niet...

[Glimi]

Het rijmt bij mij niet helemaal. Een constructor maakt een object. Er moet alleen helemaal geen object gemaakt worden, maar gewoon een methode van een object aangeroepen worden. Daarom moet de methode dus statisch zijn

[MisterData]

Op die manier zou je dus vanuit de java runtime ook objecten als String uit kunnen voeren als applicatie, denk niet dat dat de bedoeling is. Niet alles met een constructor is een applicatie, en door met een main methode te werken is er gelijk ook een standaard manier om parameters binnen te krijgen.

[B-Man]

De methode main() zorgt ervoor dat je een class vanaf een commandoprompt kunt starten. Een class zonder de main() methode niet.

Binnen je klasse(n) kun je gewoon met constructors werken. De main methode maakt dus het onderscheid tussen direct aanroepbaar en niet direct aanroepbaar. Klassen zonder een main() methode zijn dus alleen als objecten te instantieren vanuit een andere klasse.

[Verwijderd]

Op maandag 25 februari 2002 17:09 schreef Glimi het volgende:
Het rijmt bij mij niet helemaal. Een constructor maakt een object. Er moet alleen helemaal geen object gemaakt worden, maar gewoon een methode van een object aangeroepen worden. Daarom moet de methode dus statisch zijn

Waarom zou een applicatie geen object zijn?

Op maandag 25 februari 2002 17:09 schreef MisterData het volgende:
Op die manier zou je dus vanuit de java runtime ook objecten als String uit kunnen voeren als applicatie, denk niet dat dat de bedoeling is. Niet alles met een constructor is een applicatie, en door met een main methode te werken is er gelijk ook een standaard manier om parameters binnen te krijgen.

Niet alles met een constructor is een applicatie, maar als je een constructor hebt met een array van Strings, een input, output en error stream zou dat weer wel zo kunnen zijn...

[Verwijderd]

Op maandag 25 februari 2002 17:11 schreef B-Man het volgende:
Binnen je klasse(n) kun je gewoon met constructors werken. De main methode maakt dus het onderscheid tussen direct aanroepbaar en niet direct aanroepbaar. Klassen zonder een main() methode zijn dus alleen als objecten te instantieren vanuit een andere klasse.

Wat zou er op tegen zijn om van die main dan een constructor te maken met een standaard set parameters?

[tomato]

Naar mijn idee wil je alleen een methode uit een klasse aanroepen bij de start van een applicatie, dit moet dus een static method zijn.

Je kunt volgens mij vervolgens wel zoiets doen als je wilt:

code:

class Test {

   public Test () {
    System.out.println ("Hallo Wereld");
   }

   public static void main (String[] argv) {
    Test t = new Test ();
   }

}

code:

>java Test
Hallo wereld

>

[Verwijderd]

Maar als je je nou voorsteld dat alle applicaties in 1 JVM draaien. Het kan best zo zijn dat je meerdere instansies van 1 programma tegelijk wilt draaien. Logisch lijkt het mij dan om van elke programma afzonderlijk ook een object te maken (is het al), die je kunt instantieren met een constructor. Met de huidige public static void main sluit je die mogelijkheid eigenlijk uit.

[Jelmer]

Uh, volgens mij is dat voorbeeld van tomato perfect. Die 'applicatie' kun je meerdere keren starten en toch zijn het allemaal verschillende instanties, ook binnnen 1 VM

[Verwijderd]

Op maandag 25 februari 2002 17:51 schreef Jelmer Barhorst het volgende:
Uh, volgens mij is dat voorbeeld van tomato perfect. Die 'applicatie' kun je meerdere keren starten en toch zijn het allemaal verschillende instanties, ook binnnen 1 VM

Als iedereen het zo zou doen in principe wel ja, maar waarom zou je het niet afdwingen?

[Stephan Oudmaijer]

reden ervoor dat je geen input en output stream meegeeft is omdat deze al aanwezig zijn. De main IS !!!! een constructor. Met als parameter een String array.

vb als ik m`n programma run zo:

java MyClass "Hello World"

dan kan ik dus de parameters opvragen:

class MyClass
{
public static void main( String [] a )
{
System.out.println( a[0] );
}
}

aangezien er standaard al een input en output stream zijn is het dus onlogisch deze mee te geven. Wil je de standaard output stream voor je eigen applicatie gebruiken, dan moet je hem simpelweg even vertellen waarheen hij moet verwijzen.

System.setin( MyInputStream() );

idem voor de output stream.


Het sterke van java is JUIST dat niet alle programma`s in de zelfde VM space draaien, denk aan beveiliging

[MisterData]

de main methode is dus eigenlijk een soort van statische constructor

[Verwijderd]

Op maandag 25 februari 2002 17:58 schreef CK het volgende:
[..]
aangezien er standaard al een input en output stream zijn is het dus onlogisch deze mee te geven. Wil je de standaard output stream voor je eigen applicatie gebruiken, dan moet je hem simpelweg even vertellen waarheen hij moet verwijzen.

Maar dit is globaal voor de hele JVM, als ik de input/output van de eene instantie wil koppelen aan iets anders dan een tweede instantie heb ik een probleem. Stel ik maak een soort desktop applicatie in Java waarin ik andere java applicaties wil laten draaien. Daarvoor emuleer ik verschillende consoles binnen die applicatie. Ik wil niet dat alle output van alle draaiende applicaties naar de standaard output maar in die verschillende consoles belandt, dat kan niet op het moment. Ik vraag me dan af waarom ze deze extra flexibiliteit niet geven. Voor servlets/applets is er ook zoiets. Waarom voor standalone applicaties niet?

[Stephan Oudmaijer]

Op maandag 25 februari 2002 18:03 schreef Zef het volgende:

[..]

Maar dit is globaal voor de hele JVM, als ik de input/output van de eene instantie wil koppelen aan iets anders dan een tweede instantie heb ik een probleem. Stel ik maak een soort desktop applicatie in Java waarin ik andere java applicaties wil laten draaien. Daarvoor emuleer ik verschillende consoles binnen die applicatie. Ik wil niet dat alle output van alle draaiende applicaties naar de standaard output maar in die verschillende consoles belandt, dat kan niet op het moment. Ik vraag me dan af waarom ze deze extra flexibiliteit niet geven. Voor servlets/applets is er ook zoiets. Waarom voor standalone applicaties niet?

dat kan zeker wel hoor! Gewoon een singelton gebruiken voor je instantie van een class. Kun je gewoon met main hem runnen maar er is maar 1 object in de VM!

[JungleJim]

Edit: Laat maar, thread niet goed gelezen. Beetje dom

[mbravenboer]

Haha wat grappig . De main methode is altijd een van mijn vaste punten van kritiek op Java . Eerlijk gezegd staat jouw oplossing mij ook niet echt aan .

Allereerst eventjes op een rijtje wat je nu eigenlijk wilt: er moet simpelweg een entry-point zijn voor je applicatie. Deze moet aangeroepen kunnen worden door de JVM om de applicatie ook daadwerkelijk te starten.

De klassieke static main methode is in feite een soort afspraak van het platform. Als je een applicatie wilt maken ben je verplicht om een static main methode te implementeren.

Als je goed leest herken je hier een bekende constructie: een interface. Interfaces gebruik je om voorwaarden vast te leggen waaraan een klasse moet voldoen. Ze geven in feite de mogelijkheden van een object aan. Dat mechanisme zou je denk ik ook moet gebruik voor een applicatie.

Je krijgt dan bijvoorbeeld deze interface:

code:

public interface Application {
    public void run(String[] ps);
}

Simpel .

Je hebt nu binnen de mogelijkheden die de taal al biedt kunnen aangeven waaraan een applicatie moet voldoen. Hier is geen aparte afspraak voor nodig en dat is prettig . Het biedt gelijk duidelijkheid voor beginnende programmeurs: er is geen obscure main constructie, maar gewoon een interface die geimplementeerd moet worden. Als ze een applicatie maken zonder een run methode waarschuwt de compiler, wat op dit moment niet mogelijk is.

Er is wel een kleien opmerking bij te maken:

Hoe wordt die methode dan aangeroepen? Java biedt standaard al mogelijkheden om via reflectie een instantie van een klasse aan te maken. Dit kan je hier perfect gebruiken. Hierbij speelt echter een probleem: je kan alleen een instantie aanmaken als je ook een manier hebt om aan te geven waaraan een constructor moet voldoen. Dit is niet zozeer een probleem wat specifiek hierop van toepassing is. Het is eigenlijk een probleem van heel het reflectie systeem van Java: je kunt niet vastleggen dat je bepaalde constructoren wilt zien. Aan de ene kant is dat prettig, aan de andere kant is dat best wel vervelend...

Dit is ook precies het probleem van jouw oplossing: je kan geen vereisten oploggen aan een constructor. In mijn voorstel geef je meer een mogelijkheid aan van een applicatie dan een methode om een applicatie te construeren. Impliciet vereist is daarbij dat de applicatie een constructor zonder parameter heeft....

Je ziet deze constructie overigens ook al terug bij Applets en Servlets. Het is dus een hele logische stap.

Maar helaas: soms hangt men net iets teveel naar het verleden in een commerciele omgeving .

[Verwijderd]

Hmm, ja idd zo'n interface is nogal wat mooier dan zo'n constructor. Jammer dat ze zoiets niet direct geimplementeerd hebben, nu is het te laat...

[Soultaker]

Op dinsdag 26 februari 2002 14:59 schreef Zef het volgende:
Hmm, ja idd zo'n interface is nogal wat mooier dan zo'n constructor. Jammer dat ze zoiets niet direct geimplementeerd hebben, nu is het te laat...

Hoezo?

code:

public interface Application {
    public static void main(String[] args);
}

En je hebt je in principe wat je wilt. In een volgende versie zou de JRE dan ook kunnen controleren of de aangeroepen klasse de Application interface implementeerd, hoewel dat misschien niet zo fijn is ivm backwards compatibility. Een (deprecation) warning kan dan natuurlijk wel.

[Verwijderd]

Op dinsdag 26 februari 2002 15:46 schreef Soultaker het volgende:

[..]

Hoezo?

code:

public interface Application {
    public static void main(String[] args);
}

En je hebt je in principe wat je wilt. In een volgende versie zou de JRE dan ook kunnen controleren of de aangeroepen klasse de Application interface implementeerd, hoewel dat misschien niet zo fijn is ivm backwards compatibility. Een (deprecation) warning kan dan natuurlijk wel.

Andere posts gelezen?

[mbravenboer]

Soultaker:

code:

public interface Application {
    public static void main(String[] args);
}

Hum.... static methode in een interface?

[Stephan Oudmaijer]

wat is je hele probleem eigenlijk? c++ heeft ook een main net als bijna elke taal...

[Verwijderd]

Op dinsdag 26 februari 2002 16:41 schreef CK het volgende:
wat is je hele probleem eigenlijk? c++ heeft ook een main net als bijna elke taal...

Lekker ruimdenkend Ja C en C++ hebben het ook, dat is dan ook de reden dat Java het heeft, niet omdat het zo ideaal is (was dus mijn stelling). Verder is die main methode een overblijfsel uit C en hoort hij niet in een echte OO taal (was dus mijn stelling ).

[Stephan Oudmaijer]

Op dinsdag 26 februari 2002 16:45 schreef Zef het volgende:

[..]

Lekker ruimdenkend Ja C en C++ hebben het ook, dat is dan ook de reden dat Java het heeft, niet omdat het zo ideaal is (was dus mijn stelling). Verder is die main methode een overblijfsel uit C en hoort hij niet in een echte OO taal (was dus mijn stelling ).

wat een gelul, iets moet toch je entrypoint zijn, kan gewoon niet oo zijn want een entrypoint is niet oo.

[mbravenboer]

CK: wat een gelul, iets moet toch je entrypoint zijn, kan gewoon niet oo zijn want een entrypoint is niet oo.

Hum... als je nu eens eerst alle posts goed leest (bijvoorbeeld de mijne) dan zal je zien dat het best fraaier kan....

'Gelul' vind ik ik in ieder geval een vrij onzinnige opmerking in dit verband .

[Soultaker]

Op dinsdag 26 februari 2002 15:47 schreef Zef het volgende:
Andere posts gelezen?

Ja hoor, hoewel sommige wat oppervlakkig. Op zich vind ik het niet erg dat je commentaar hebt op mijn bericht, maar wil je dan in het vervolg wel vermelden waar je precies over valt? Hier heb ik (en iemand anders) niets aan.

[Verwijderd]

Op donderdag 28 februari 2002 02:03 schreef Soultaker het volgende:

[..]

Ja hoor, hoewel sommige wat oppervlakkig. Op zich vind ik het niet erg dat je commentaar hebt op mijn bericht, maar wil je dan in het vervolg wel vermelden waar je precies over valt? Hier heb ik (en iemand anders) niets aan.

Wat ik bedoel is dat het handig zou zijn dat ALLE applicaties zo'n interface implementeren. Maar aangezien Java nu al een tijd bestaat en er veel applicaties in geschreven zijn krijg je het niet meer voor mekaar dat alsnog in te voeren.

[MisterData]

Als je het gewoon implementeert in de java.lang.Object klasse, die door alle klassen wordt ge-extend, dan zit die emthode er dus altijd in en kan ie toch worden vervangen door subklassen

[Tomatrix]

Op donderdag 28 februari 2002 12:37 schreef MisterData het volgende:
Als je het gewoon implementeert in de java.lang.Object klasse, die door alle klassen wordt ge-extend, dan zit die emthode er dus altijd in en kan ie toch worden vervangen door subklassen

Dit wil je dus echt niet! Hiermee geef je aan dat elke klasse 'executable' is, wat niet het geval is. Nee, gewoon een leuk interface met 1 methode 'execute (String[] args)' is veel mooier.

[Soultaker]

Op donderdag 28 februari 2002 10:12 schreef Zef het volgende:
Wat ik bedoel is dat het handig zou zijn dat ALLE applicaties zo'n interface implementeren. Maar aangezien Java nu al een tijd bestaat en er veel applicaties in geschreven zijn krijg je het niet meer voor mekaar dat alsnog in te voeren.

Ah, daar kan ik meer mee =)

Mijn punt was, dat je nu wel zo'n interface kan toevoegen en een nieuwe methode hanteren (waarbij de oude methode als deprecated wordt beschouwd), zonder dat er iets hoeft te veranderen aan Java zoals we het kennen. In een latere versie kan de oude manier verboden worden.

Ik neem tenminste aan dat Sun niet van plan is alle klassen en methoden die nu al deprecated zijn, tot in het einde der tijden te ondersteunen. Ik kan me voorstellen dat je ze bij (bijvoorbeeld) release 2.0 er allemaal uitgooit.

[Verwijderd]

Dat zou kunnen, maar zo'n nieuwe interface voor applicaties is wel even wat anders dan een methode depreciaten. Het betekent dat ALLE java standalone applicaties aangepast moeten worden, en dat is toch even wat anders dan een methode hier en daar.

[Verwijderd]

Op dinsdag 26 februari 2002 14:59 schreef Zef het volgende:
Hmm, ja idd zo'n interface is nogal wat mooier dan zo'n constructor. Jammer dat ze zoiets niet direct geimplementeerd hebben, nu is het te laat...

Zou het fout kunnen hebben maar een groot probleem is volgens mij dat de entry point een static methode moet zijn (en dat mogen methodes in een interface niet zijn)...

Indien je een interface zou gebruiken als entry point zou de JVM eerst de default constructor aan moet roepen (de classe initializeren) en daarna de methode "run" in de interface... Dit lijkt mij niet echt gewenst...

[Soultaker]

Op donderdag 28 februari 2002 14:33 schreef tijnbraun het volgende:
Zou het fout kunnen hebben maar een groot probleem is volgens mij dat de entry point een static methode moet zijn (en dat mogen methodes in een interface niet zijn)...

Conceptueel lijkt me er niets mis met static methods in een interface. Dat 't niet kan in Java is dan een tekortkoming in die taal, die natuurlijk tegelijkertijd met het toevoegen van de Application interface aangepast kan worden zodat het wel kan. Ook dit is volledig backwards compatible.

[drm]

* drm vindt dat Zef gelijk heeft, en geeft de voorkeur aan mbravenboer's idee.

Het past veel beter in het OO-idee.

mbravenboer: Het is eigenlijk een probleem van heel het reflectie systeem van Java: je kunt niet vastleggen dat je bepaalde constructoren wilt zien.

Maar je kunt in de interface wel aangeven over wat voor methodes zo'n applicatie moet beschikken. Bijvoorbeeld run (), quit () etc...

Als 1 van die abstracte methodes dan bijvoorbeeld

code:

setArgs ( String args [] )

is (ofzo), en

code:

setIO ( InputStream in, PrintWriter out )

Wat de JVM nu moet doen is een instantie maken van de Application en de juiste variabelen zetten. Hoeft toch niet perse via de constructor? Tja, het is wel netter, maar een absolute must is het niet. Er zijn tenslotte ook applicaties denkbaar die die 3 bovengenoemde argumenten helemaal niet gebruiken (argumenten, input en output).

code:

a = new DerivedApplication ();
a.setArgs ( blah );
a.setIO ( blaIn, blaOut );
a.run ();

zoiets. simplified

[MisterData]

Op donderdag 28 februari 2002 13:09 schreef Tomatrix het volgende:

[..]

Dit wil je dus echt niet! Hiermee geef je aan dat elke klasse 'executable' is, wat niet het geval is. Nee, gewoon een leuk interface met 1 methode 'execute (String[] args)' is veel mooier.

Mooier : ja
Handiger : nee

Dan moet je alle apps in java gaan omzetten om die methode te gebruiken, bouw gewoon een static methode in in java.lang.Object die een foutje genereert ofzo, dan is toch niet alles gelijk een applicatie ? Alleen als de methode wordt veranderd door een subklasse

_{maar 't is niet netjes nee}

[Verwijderd]

Ik denk dat de java designers wel hebben nagedacht over dit bootstrapprobleem. Je _moet_ altijd een vast punt hebben waar de uitvoerbare code moet beginnen.

1/ Static methods in een interface kunnen ideologisch niet omdat de 'static' eigenschap implementatiespecifiek is. En dat breekt met het concept van een interface.
2/ Verder zijn static methods niet-virtual (bindt aan het gedeclareerde type ipv het runtime-type), en interfaces hebben geen implementatie.

conclusie: los bootstrap problemen op met het singleton design pattern.

[Verwijderd]

Op donderdag 28 februari 2002 17:10 schreef Dessignator het volgende:
Ik denk dat de java designers wel hebben nagedacht over dit bootstrapprobleem. Je _moet_ altijd een vast punt hebben waar de uitvoerbare code moet beginnen.

Dat wel, maar dat punt hoeft niet static te zijn. Objecten kunnen natuurlijk niet uit het niets ontstaan, maar de JVM kan wel automatisch een instantie van een applicatie aanmaken en dan een bepaalde methode runnen.

[Verwijderd]

Op donderdag 28 februari 2002 17:20 schreef Zef het volgende:

Dat wel, maar dat punt hoeft niet static te zijn. Objecten kunnen natuurlijk niet uit het niets ontstaan, maar de JVM kan wel automatisch een instantie van een applicatie aanmaken en dan een bepaalde methode runnen.

Voor de static aanpak heeft er niets moeten veranderen in het JVM model. Hier hoef je immers maar 1 methode voor te implementeren. En wat hier wordt genoemd vraagt veel aanpassingen van de JVM specificatie, speciaal voor dit probleem.

Het doel van Sun is/was om de JVM zo simpel mogelijk te houden.

[Verwijderd]

Op donderdag 28 februari 2002 17:40 schreef Dessignator het volgende:
[..]
Voor de static aanpak heeft er niets moeten veranderen in het JVM model. Hier hoef je immers maar 1 methode voor te implementeren.

Op zich vind ik 'veel' aanpassingen in de JVM niet een reden om door te filosoferen over hoe het had moeten zijn

En wat hier wordt genoemd vraagt veel aanpassingen van de JVM specificatie, speciaal voor dit probleem.

Het gaat hier niet alleen om dit specifieke probleem maar gewoon om de schoonheid van de oplossing. Persoonlijk heb ik iets van: Java is bijna helemaal object georienteerd, op die stomme public static void main na dan. Dat is gewoon iets waarvan ik (en klaarblijkelijk meer mensen) van vinden dat het mooier kan.

Het doel van Sun is/was om de JVM zo simpel mogelijk te houden.

Is dat zo? Hmm, in dit geval zou ik puriteit boven simpliciteit kiezen (verder vindt ik mbravenboers oplossing ook niet veel complexer).

[ronaldmathies]

Het is niet zo moeilijk opzich maar het vergt enige kennis.

Hier een voorbeeld,

class myClass {
public myClass () {
}

static {
}
}

Dit mag gecompileerd worden, elke klasse heeft in principe een standaard static method, deze word echter zeldsaam gebruikt. Je kan het goed zien in JBuilder bijvoorbeeld als je deze klasse maakt dan zie je links onderin het volgende staan :

<initializer>

Als je naar de volgende klasse kijkt :

public class myClass{

public myClass() {
System.out.println ("C");
}

static {
System.out.println ("A");
}

public static void main(String[] args) {
System.out.println ("B");
}
}

Dan zie je als output :

A
B
C

Dat is nu wat ik grappig vind, de static initializer word voor de main functie aangeroepen.

Dat er gekozen is voor een main proc heeft alleen maar met afspraken te maken, want elke klasse zou theoretish gestart kunnen worden, omdat elke klasse automatisch een initializer heeft.

Maar om de JVM nu goed te laten bepalen welke de echte start functie is hebben ze gekozen voor een main method.

[Soultaker]

Op donderdag 28 februari 2002 17:10 schreef Dessignator het volgende:
1/ Static methods in een interface kunnen ideologisch niet omdat de 'static' eigenschap implementatiespecifiek is. En dat breekt met het concept van een interface.

Wat bedoel je precies met implementatiespecifiek? En waarom mag dat niet? Een interface is alleen maar een klassificatie van een object in de zin dat een object dat die interface implementeert, ook een aantal methodes implementeert. Ik zou niet weten waarom daar geen statische methoden bij zouden kunnen zitten?

2/ Verder zijn static methods niet-virtual (bindt aan het gedeclareerde type ipv het runtime-type), en interfaces hebben geen implementatie.

Dat geloof ik niet en ga ik dus even uitproberen.

edit:
Het is inderdaad waar. Wat een vreemde implementatiekeuze! Als ik dus een het keyword 'static' aan een methode toevoeg, veranderd impliciet ook de binding. Dat vind ik niet erg netjes en ik snap de reden ook niet. Wat is dan nog het nut van het gebruik van statische methoden in plaats van gewone globale functies (in plaats van dat ze aan een specifieke klasse gekoppeld worden)?

[ronaldmathies]

Een static function is niet object uniek, de static function bestaat over alle geinstantieerde object maar één keer.

Dat is nu eenmaal de eigenschap van static, dit heeft ook grote voordelen, als ik een Instantie van een java.sql.Connection bewaar in een static variabele dan kan ik deze impliciet overal in mijn code aanroepen, en hoef ik de variabele niet continue als parameter bijvoorbeeld mee te sturen.

De static function word daarom ook veel gebruikt bij bijvoorbeel connection pooling.

[ronaldmathies]

Hier is een stukje voorbeeld code van me, dit stukje is een connectionManager deze instantieerd nieuwe verbindingen naar een server onderdeel. Dit is in principe altijd hetzelfde object dat kan runnen waarbij ik ook niets hoef te instantieren.

code:

package com.jinstance.networking;

import java.io.*;
import java.net.*;

/**
 * The <code>SocksManager</code> class is used for instantiating a new
 * <code>SocksCommunicator</code> class for communication between server->client
 * or client->server. This class is a stackic class so you cannot instantiate it.
 * <p>
 * Example :
 *
 * <pre>
 *    SocksManager.newConnection(myMessageHandler, "server.domain.com", 8170);
 * </pre>
 *
 * This will start a new SocksCommunicator with the given <code>SocksMessageHandler</code>
 * implemented class.
 *
 * <P>
 * @see <a href="SocksCommunicator.html">com.jinstance.networking.SocksCommunicator</a>
 * @see <a href="SocksListener.html">com.jinstance.networking.SocksListener</a>
 * @see <a href="SocksMessageHandler.html">com.jinstance.networking.SocksMessageHandler</a>
 * @see <a href="SocksDatagram.html">com.jinstance.networking.data.SocksDatagram</a>
 * @version 1.00 21-FEB-02
 *
 * @author Ronald Mathies ([e-mail])
 */

public final class SocksManager {

  /**
   * This is the default port on wich we work. (is the same default port as for the listener)
   *
   * @see SocksListener
   */
  private static int int_listenerPort = 8170;

  public SocksManager() {
  } // SocksManager

  /**
   * Creates a new connection to a server or client.
   *
   * @param socksMessageHandler A message handler, this is a class that implements the <code>SocksMessageHandler</code> interface.
   * @param pshostname The host name to wich we should connect.
   * @param int_port   The port from the <code>pshostname</code> to wich we should connect.
   *
   * @throws Exception If the function cannot connect to the remote client/server than this exception will be thrown.
   *
   * @see <a href="SocksMessageHandler.html">com.jinstance.networking.SocksMessageHandler</a>
   */
  public static void newConnection(SocksMessageHandler socksMessageHandler, String pshostname, int int_port) throws Exception{

    try {
      Socket socketChanel = new Socket(pshostname, int_port);

      new SocksCommunicator(socksMessageHandler, socketChanel).start();
    } catch (IOException ioException) {
      throw new Exception("SocksManager.newConnection : " + ioException);
    }

  } // newConnection

  /**
   * Creates a new connection to a server or client.
   *
   * @param socksMessageHandler A message handler, this is a class that implements the <code>SocksMessageHandler</code> interface.
   * @param pshostname The host name to wich we should connect.
   *
   * @throws Exception If the function cannot connect to the remote client/server than this exception will be thrown.
   *
   * The port will be the default port of the SocksManager (this is the same as the default port for the <code>SocksListener</code>.
   *
   * @see <a href="SocksMessageHandler.html">com.jinstance.networking.SocksMessageHandler</a>
   */
  public static void newConnection(SocksMessageHandler socksMessageHandler, String pshostname) throws Exception{

    try {
      Socket socketChanel = new Socket(pshostname, int_listenerPort);

      new SocksCommunicator(socksMessageHandler, socketChanel).start();
    } catch (IOException ioException) {
      throw new Exception("SocksManager.newConnection : " + ioException);
    }

  } // newConnection

  /**
   * Creates a new connection to a server or client.
   *
   * @param socksMessageHandler A message handler, this is a class that implements the <code>SocksMessageHandler</code> interface.
   * @param socketChanel A life socket connection to a client/server.
   *
   * @throws Exception If the function cannot connect to the remote client/server than this exception will be thrown.
   *
   * @see <a href="SocksMessageHandler.html">com.jinstance.networking.SocksMessageHandler</a>
   * @see Socket
   */
  public static void newConnection(SocksMessageHandler socksMessageHandler, Socket socketChanel) throws Exception  {

 //   try {
    new SocksCommunicator(socksMessageHandler, socketChanel).start();
//    } catch (IOException ioException) {
 //  throw new Exception("SocksManager.newConnection : " + ioException);
 //   }

  } // newConnection

  /**
   * Sets the new default port number.
   *
   * @param int_port The new port number that overides the default port number. (this will not automaticaly
   *             update the <code>SocksListener</code> port)
   *
   * @throws Exception This exception is thrown if the new portnumber is smaller than 2100 or larger than 32000.
   */
  public static void setPort(int int_port) throws Exception {

    if (int_port < 2100) {
    throw new Exception("SocksManager.setPort : The port number must be larger than 2100.");
    } else if (int_port > 32000) {
    throw new Exception("SocksManager.setPort : The port number must be smaller than 32000.");
    }

    int_listenerPort = int_port;

  } // setPort

  /**
   * Creates a new connection to a server or client.
   *
   * @return int The current port number. (if the <code>setPort</code> function has been used than this port number
   *         will be retured, otherwise it will be the default port)
   */
  public static int getPort() {

    return int_listenerPort;

  } // getPort

}

edit:

Ik hoop dat dit voorbeeld een beetje duidelijk is waarvoor je een static kan gebruiken.

als er vragen zijn dan hoor ik die wel.

[Soultaker]

Uhm... bedankt voor de uitgebreide uitleg, maar die enorme berg code had niet gehoeven hoor =)

Ik denk dat de term 'static' een beetje verwarrend is. In imperatieve programmeertalen betekent 'static' dat de inhoud van een lokale variabele over verschillende aanroepen behouden blijft (feitelijk is het dus een globale variabele met een lokale scope).

Dit concept is overgenomen in het object-georiënteerd programmeren, maar het lijkt me niet correct om nu te stellen dat 'static' variabelen en methoden dus ook in een OO-omgeving globale variabelen zijn. Wat mij betreft zijn het eigenschappen van een klasse in plaats van een instantie van een klasse. Dat betekent dus ook, dat je ze prima dynamisch kan binden, net zoals je dat bij instantiemethodes kan doen EN je al bij statische variabelen doet!

Mijns inziens kan in Java het aanroepen van statische methoden van objecten beter verboden worden, aangezien dit geen meerwaarde oplevert (het is toch altijd equivalent met het aanroepen van de statische methode van de klasse waarnaar je 'm zelf gecast hebt) en het verwarring vanwege de inconsequente binding voorkomt.