Win a copy of The Little Book of Impediments (e-book only) this week in the Agile and Other Processes forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

jar file

 
Christy Keane
Ranch Hand
Posts: 32
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Folks,

My instructions say:

When you submit your assignment, each part (client and server) must be executable using a command of this exact form:

java -jar <path_and_filename> [<mode>]


I have assumed from this that I have one jar file which contains both the server and client.

In this jar file, there is a class with a main method which starts either the server, the client, or the non-networked application based on the mode flag.

This seems a little strange - wouldn't it be preferable to have seperate jars for the client and the server?

Also, do you put this "starter" class in the client or the server code?

I have seen this topic on threads from a few months ago, and people seemed to be thinking along the same lines as me...I guess I just would like to know the thoughts of any new people on the forum.

Thanks,

Christy.
 
John Smith
Ranch Hand
Posts: 2937
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I have assumed from this that I have one jar file which contains both the server and client.

My interpretation is that they want to be able to start the server:
java -jar server
And the client:
java -jar client

Also, do you put this "starter" class in the client or the server code?

Do you mean the Main-Class entry of the manifest? You should have one main class for the server.jar and one main class for the client.jar.
 
Darya Akbari
Ranch Hand
Posts: 1855
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Christy,

your assumption about runme.jar are absolute correct.

In your runme.jar you have a manifest file and there you link your starter class with the runme.jar

Concerning the starter class, this is the place where you distinguish between server, client or standalone start of your one application.

There is no need to provide seperate server.jar and client.jar or the like. You provide the one and same runme.jar to server and client.

According to the mode your choose with runme.jar you starter class (behind runme.jar) start your applicaton as server application or client application or standalone application.

So these are the modes of use in my assignment (B&S):
  • java -jar runme.jar server - start the server application
  • java -jar runme.jar - start the client application
  • java -jar runme.jar alone - start the application as standalone


  • The runme.jar in all cases is the same file. The starter class takes care that the right portion of your application is started according to the mode you chose.

    Hope I could spare you some time of confusion

    Regards,
    Darya
     
    Darya Akbari
    Ranch Hand
    Posts: 1855
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    After reading John's comment I must add that I have the Bodgitt & Scarper Version 2.1.3 assignment, because John maintain to talk about client.jar and server.jar. So maybe this is a requirement in your assignment

    The starter class in my case reside in the suncertify.gui package similar to Max Habibi's approach.
     
    John Smith
    Ranch Hand
    Posts: 2937
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    It looks like you requirements are different enough from mine, so you should ignore my comments about packaging.
     
    Lara McCarver
    Ranch Hand
    Posts: 118
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    I have a version of B&S with the same weird requirement as Christy. Yes, it certains seems from the instructions that you are supposed to have a single jar file and depending on the argument you supply, main() switches which classes it creates (either the client classes or the server classes or the standalone classes). I couldn't imagine anyone writing an actual program like this, other than for this test.

    The only justification I can see to this is that the standalone case is going to have most of the classes of both the client and the server. I wonder, for those people who got older (I presume) assignments with separate .jar files for client and server, did you have a requirement that things were supposed to run in standalone mode? And if so, was this supposed to work with client.jar?
     
    Reza Rahman
    author
    Ranch Hand
    Posts: 580
    5
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    I also have the same requirement and handled it the same way as Lara and Darya (i.e. a common launcher class). Hope this helps.
     
    John Smith
    Ranch Hand
    Posts: 2937
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    I wonder, for those people who got older (I presume) assignments with separate .jar files for client and server, did you have a requirement that things were supposed to run in standalone mode?

    Yes, same requirement: the client should work in a networked mode and the non-networked mode. The switch from one mode to another could be made either dynamically (while the client is running), or at the start (using a parameter indicating the desired mode). I would also note that the requirement didn't "contain" separate jar files, nor did it prescribe using separate jars. It's just most people had enough common sense to break it in that manner.

    For the newer requirements posted as

    When you submit your assignment, each part (client and server) must be executable using a command of this exact form:
    java -jar <path_and_filename> [<mode>]


    I still don't see where runMe.jar comes from. Unless you have some additional requirements, that quote above tells me that they just want to see both client and server started from a jar, and the only allowed parameter is the "mode". In the old days, the folks used to submit their solutions where they would pass all sorts of junk on the command line (such as RMI security manager settings, timeout settings for lock() (don't ask me why), locations of databases, property file locations, etc.). Some didn't even bother to package their app to a JAR and required the grader to set the classpath. Sun obviously got tired with that nonsense and thus the above requirement.

    However, I don't think that it implies that both client and server must run from the same jar. In fact, why would anyone deploy the server code on the client machine (except possibly for the RMI stubs)? It's just a waste of space and bandwidth, not to mention the potential security issues (client mangling the server code). And if that's not convincing, consider this: suppose you distributed your program to all the remote clients. Now you decide to update the server code (without changing any of the interfaces). What are you going to do -- burn the CDs and ship 'em to your 10,000 clients, or send them a notice: "Please download and install our server code to your client machine, or you are toast"? Redefines the term "thick client", doesn't it?

    Perhaps you are planning to have three jars: server.jar (distributed to the servers), client.jar (distributed to the clients), and runMe.jar (distributed to both, serving as a getaway). That would be a little better than packaging everything together, but I still don't like it.

    I suspect that this runMe.jar is just a recent fashion. SCJD forum frequently goes through those waves.


    [ June 09, 2005: Message edited by: John Smith ]
     
    Darya Akbari
    Ranch Hand
    Posts: 1855
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Hi John,

    here is the additional requirement that force us to use the single jar approach (at least in my B&S version 2.1.3 assignment):

    The executable JAR containing the programs. This must be called runme.jar


    Since runme.jar contains all *.class files in their package structure I can't share your concerns about security or server update .

    Concerning security one should cope that with the access modifiers in his classes.

    Concerning the server update, I can do my software updates on the server side and leave the client side completely untouched. So there is no need to send all clients a new runme.jar file and as long as there is no change on the client's side software the client can stay with the original version of runme.jar.

    Regards,
    Darya
     
    John Smith
    Ranch Hand
    Posts: 2937
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    --------------------------------------------------------------------------------
    The executable JAR containing the programs. This must be called runme.jar
    --------------------------------------------------------------------------------


    Ah, that's new to me, OK. Disregard my rhetorics about runMe.jar.
     
    Christy Keane
    Ranch Hand
    Posts: 32
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Folks,

    thanks for all the replies - I appreciate it.

    it's always nice to be able to bounce your ideas / assumptions off other developers.

    Christy.
     
    • Post Reply
    • Bookmark Topic Watch Topic
    • New Topic