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

NX: Sun "Must": 2 Programs in runme.jar?

 
Javini Javono
Ranch Hand
Posts: 286
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,

This question attempts to understand one of Sun's "must"
conditions, for if they are not met, then one can be flunked.

Okay, the above is clear.

Okay, the above is clear (although I'm new to RMI, this question is
not related to RMI, even though I'm not sure how all the RMI pieces
will fit together).
Note how it says that all classes must be pre-installed; so, let's
assume for my question that two separate computers will be used,
this, we'd expect an installation on the server computer and an
installation on at least one client computer.
That is, so far I'm assuming that there are going to be two different
applications: one acting as a server, and one acting as a client,
and that they will exist in two separate Java executable JAR files.
Correct so far?

Okay, this is fine, and the above also starts to suggest that there
will be two executables (a client jar and a server jar), and that
both will take a mode flag (though it is totally unclear why the
server would need a mode flag, but this is not my question at this
time).

Okay, understood. Note that Sun uses the plural: "programs".

Okay, but if I have two programs, the client application and the
server application, why is there only one runme.jar file? Why
would there not be a runme.jar file and a serverRunMe.jar file?
The phrase, "" seems
illogical, since one executable JAR file contains one initial
class whose main method will run.
I guess my question is: does the one executable, runme.jar, really
contain two programs within it: the client application and the
server application?
Thanks,
Javini Javono
[ January 07, 2004: Message edited by: Javini Javono ]
 
Javini Javono
Ranch Hand
Posts: 286
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,
One possible answer to my question I thought of, though
it is not a very "real world" scenario, is that there
is only one program (not two).
When the program starts in "alone" mode, it uses no
network connections, obviously, and talks to its local
database.
When the program starts in "network" mode, it has to
1. (somehow, if possible, since I am new to RMI), register
itself as a server and act like a server standing by ready
to accept requests from any client; and
2. Show the user interface of a client to the user; the
user then specifies where the client will connect to:
2a. The client connects to "itself" on the same computer
throught RMI.
2b. The client connects to another "runme.jar" application
started in "network" mode running on a remote computer.
If this is what Sun is expecting (which is "unusual" in a
business environment since businesses usually don't want
databases tossed about randomly on client machines)
then their phrase in their must condition:
"The executable JAR containing the programs. This must be
called runme.jar" is not accurate. For it should read:
"The executable JAR containing the program. This must be
called runme.jar."
And, for further clarity, since it
is highly unusual for a business environment to disperse
business databases randomly among clients, they should add:
"when the program starts in 'network' mode, it creates a server
bound to the database on that computer, and asks the user
the appropriate questions to connect to ANY server (including
the server just created on this machine)."
Thanks,
Javini Javono
 
George Marinkovich
Ranch Hand
Posts: 619
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Javini,
You might be interested in the discussion Topic: NX:Contractors: Structure of package:

http://www.coderanch.com/t/184495/java-developer-SCJD/certification/NX-Contractors-Structure-package
I was misled by the language in my assignment instructions too. After reading your posts I think you have come to the correct conclusion: namely, there should be a single executable that can function in several different operating modes.
I agree that the instructions are sometimes sloppy: using the plural when they almost certainly mean the singular. I think the description of the command line invocation of the runme.jar executable should be the controlling legal authority (so to speak) in this matter. If two separate executables were really intended, the instructions about how to invoke the runme.jar would be utter nonsense.
I think the poorly worded instructions are part of the test -- they model the type of requirements specifications you're likely to see in the real world (actually they're probably better than anything you're likely to see in the real world ).
- George
P.S.
I think it's interesting that the instructions on this point seem to cause more problems for native English speakers. The best answer to this question came from Philippe Maquet, who I believe is a non-native English speaker. Maybe non-native English speakers were not misled as easily by the English syntactic minutiae and were forced to rely more heavily on common sense
[ December 19, 2003: Message edited by: George Marinkovich ]
 
Andrew Monkhouse
author and jackaroo
Marshal Commander
Pie
Posts: 12014
220
C++ Firefox Browser IntelliJ IDE Java Mac Oracle
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi George & Javini,
Originally posted by George Marinkovich:
I was misled by the language in my assignment instructions too. After reading your posts I think you have come to the correct conclusion: namely, there should be a single executable that can function in several different operating modes.

Correct: 1 single executable jar file called "runme.jar" which contains all the classes for running in any mode.
Originally posted by George Marinkovich:
I agree that the instructions are sometimes sloppy: using the plural when they almost certainly mean the singular.

There are two ways I can see this:
  • each class could potentially be considered a program. Therefore you have many programs (classes) in your jar file.
  • I have seen many people write individual runnable applications, then write an additional "wrapper" application that calls the individual applications based on the command line entry. This can make it easy for testing, and easy for a future requirement to split the applications into multiple jar files. In this case the instructions would literally be true.


  • Originally posted by George Marinkovich:
    I think the poorly worded instructions are part of the test -- they model the type of requirements specifications you're likely to see in the real world (actually they're probably better than anything you're likely to see in the real world ).

    Very true - Sun have even agreed that in some cases their instructions are trying to simulate typical semi-clueless customers. (See this post for an example).
    Originally posted by George Marinkovich:
    I think it's interesting that the instructions on this point seem to cause more problems for native English speakers. The best answer to this question came from Philippe Maquet, who I believe is a non-native English speaker. Maybe non-native English speakers were not misled as easily by the English syntactic minutiae and were forced to rely more heavily on common sense

    So you are saying that us native English speakers don't have common sense then?
    Regards, Andrew
     
    Javini Javono
    Ranch Hand
    Posts: 286
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Hi,
    Thanks for your replies so far. I've been focusing my questions in this group so far
    concerning Sun's "must" conditions because the directions give this important
    notice:
    ""
    Here are more related "must" conditions to this topic thread:
    ""
    This is not overly confusing, though lacks some clarity perhaps? For instance, I would
    think that it could be worded with the same meaning like this: ""
    ""
    ""
    And this suggests that there are two programs, a database server and a gui client,
    and that each is to receive it's own documentation. Though, there is little doubt
    that I will only submit one runme.jar Java application
    One response suggested, if I read it correctly, that the mode flag which is either
    "alone" or "network" could be used to determine whether the server or the GUI
    client runs, but it seems to me that the mode flag is saying whether the
    client runs in "alone" or "network" mode.
    I think, although I might, of course, later change my mind that I will submit one
    program.
    My one program will probably work like this:
    * When started with the "alone" command, no server code is used, and a client
    user interface is created which connects to the local database; the client through
    the GUI must specify where the database is on the local machine and this information
    would be in a tabbed pane called "Connect to Local Database".
    * When started with the "server" command, the client GUI is presented. This
    mode does not have the "Connect to Local Database" pane, but has two new
    tabbed panes associated with it:
    ** "Connect to Network Database" which allows the client user to connect to any
    running server on any machine including this current machine (you can connect
    to this current machine assuming that someone has started this application in
    "server" mode and visited the "Server Administration" panel to start the server).
    ** "Server Administration" pane which allows the client (acting as a system administrator)
    to start the server on this machine in this current JVM.
    I don't particularly like the mixing of "client functions" with "system adminstration
    functions" within one program. For instance, I don't like the idea that someone who
    thinks he is a client exiting from the application and, perhaps, also shutting down
    the server (assuming someone started the server on that same machine); these
    are only ideas, as I have not yet got involved in the details of what would really
    happen. But, the following must condition:
    ""
    makes it pretty clear, (actually, I don't really think the writing is clear, it's quite bad
    really), that the client GUI must always be present, so I will present a GUI which allows
    "server administration" functions in one tabbed pane and "remote database connection"
    functions in one tabbed pane, as well as "client DB interactions" in one or more tabbed
    panes when the application is started with the "server" option.
    Thanks for your responses so far. I have focused on the "must" conditions in my posts
    here because Sun creates quite a to-do about it. I think that "must" conditions should
    be clearly and concisely written. For if they are not, then it is hardly fair to say that
    Sun will take my $250 and flunk me outright. Furthermore, if Sun really does want
    there to be ambiguity in the user specifications, then this is fine, but this ambiguity
    really does not belong in the "must conditions" sections of their directions. Instead,
    they should structure their document such that any sentence or paragraph is
    prefixed by "who is talking". The "talkers" are either
    * clear, unambiguous "must" conditions that Sun is presenting, or
    * potentially ambiguous conditions specified by the fictional company in the problem.
    Here is an example paragraph: Note that any "Customer" comments can never
    be "must" conditions, for it is assumed that "must" conditions must be ambiguous.
    Customer: The mode flag is to be either "server", indicating the server program
    will run, "alone", indicating standalone mode, or left out entirely, in which case the
    network client and gui will run. Sun: <some unambiguous, clearly stated "must"
    condition>".
    Thanks,
    Javini Javono
    [ January 07, 2004: Message edited by: Javini Javono ]
     
    Javini Javono
    Ranch Hand
    Posts: 286
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Hi,
    As I said above, thanks again for your posts and responses, for there is nothing
    worse than losing $250 over poorly worded, mandatory "must" conditions.
    Here are my closing comments on these "must" conditions for now.
    Sun might want to consider that from our perspective, there are really two
    customers: the fictional customer and Sun. Thus, perhaps there should
    be two sections to the requirements: one focusing on the remarks of the
    fictional customer (which may contain ambiguous, unclear instructions),
    and one section focusing on Sun's examiners and what they need to make
    their grading procedure efficient. The later section would, of course, strive
    to be unambiguous and clear.
    Again, I appreciate your comments very much. Now I don't feel that when
    my project is submitted it will be flunked outright due to "must" conditions
    which were unclear and ambiguous.
    Finally, concerning a somewhat unrelated item, the following Sun paragraph:
    ""
    almost makes it seem that it is best practice not to communicate with the customer.
    This can be misleading. The paragraph might want to close with better advice:
    "In the real world, you would not forge ahead making assumptions about what
    you think your customer wants and not speak to the customer until delivery
    time. But instead, communicate often with the customer, showing the customer
    mock-ups of the user interface, showing the customer preliminary versions
    of your application, and so on. This is done to allow the customer to
    1. Immediately see that the specifications are not what the customer wants, or
    2. Immediately see that the customer wants to change his mind and remove
    some specifications and add others.
    However, because this is an exam and Sun examiners don't have time for this
    process, you are to ignore this best practice for this particular exam."
    Thanks,
    Javini Javono
    [ January 07, 2004: Message edited by: Javini Javono ]
     
    George Marinkovich
    Ranch Hand
    Posts: 619
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Hi Andrew.
    Yes, as a native English speaker myself, and based upon extensive personal experience with the same, I can unequivocally state that indeed native English speakers have no common sense whatsoever.
    Just kidding. I merely meant to suggest that some of us (with myself as perhaps the premier exemplar since I actually separated my application into two executables before being seized by a fit of common sense) are parsing the language in the assignment instructions with a fine-toothed comb and that perhaps that is to our detriment. I now realize that I was behaving as a language lawyer to a certain extent and that by considering all the pieces of information scattered throughout the document regarding the number of executables issue, it's pretty clear (at least to me) that there is intended to be only one executable.
    Hi Javini,
    Could the instructions have been more clear on this point throughout the document? Does one wish that the author had produced a more consistent specification? Of course. But I will concede it is actually quite difficult to produce such a document since it requires writing the document from the reader's perspective. That is an exceedingly difficult task and in this regard it can be said that more documents fail than succeed. Maybe Sun will offer a clearer, more consistent, version of the assignment instructions for an extra $100.
    In my experience most requirements specifications contain a great number of inconsistencies. The difference here is that we can't really resolve them with the customer (i.e., Sun) easily. But in real life it's also not so easy to resolve them with the customer. Some can be resolved through common sense and for these there is probably no need to bother the customer. Others need to be resolved with the customer and for these I have this suggestion: instead of asking the customer what they meant, one should present the customer with several different interpretations (along with their consequences) and get the customer to commit to one of the interpretations. Isn't this doing the customer's work for them? Yes and that's one of the reasons they're paying us. The customer really is always right. It's our job is to make sure the customer continues to be right and influence the customer to be even more right in the future. This post http://www.coderanch.com/t/183774/java-developer-SCJD/certification/URLyBird-data-file-Reply-SUN is a model of what I'm talking about and if I ever had to communicate with Sun about the exam I would try to do so in a similar way.
    It's sounds to me like you understand the requirements now. I think your proposed design is reasonable. I can tell you what I did regarding having separate documentation for the server and client. I have a single userguide.html (the required name for me) that covers both client and server. Within this document I have separate installation and startup instructions for the server and client. The instructions for using the application cover the functions available from both the server and the client GUIs.
    - George
     
    Javini Javono
    Ranch Hand
    Posts: 286
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Hi,
    Here is what I wrote somewhere above:
    ----------------------------------
    ""
    makes it pretty clear, (actually, I don't really think the writing is clear, it's quite bad
    really), that the client GUI must always be present, so I will present a GUI which allows
    "server administration" functions in one tabbed pane and "remote database connection"
    functions in one tabbed pane, as well as "client DB interactions" in one or more tabbed
    panes when the application is started with the "server" option.
    ----------------------------------
    And, I was just now re-reading my post, and I realize that the directions in quotes
    just above should probably be interpreted thus:
    There is only one Java application running from runme.jar and
    one run-time input parameter where
    1. "server" starts the server sub-application with it's own unique user interface
    from that of the client; this is the application which creates the server which
    will wait for client requests and send back responses (though if RMI is used,
    some implementations might allow the server to remain dormant until
    services are requested).
    2. "alone" starts the client sub-application, with its own client user interface, and it will
    connect to a local database (and never to a networked database).
    3. no argument: another version of the client sub-application starts with its
    own client user interface, and it connects only to a networked server.
    For options 2 and 3 above, the client sub-application user interfaces may be identical
    or for the most part be identical, depending upon what I encounter during further
    design.
    Aside: keeping in mind that I know very little about RMI, note that the above
    specifications from Sun (assuming that I'm interpreting them correctly), should
    make life easier for those creating an RMI server (which I propose to do myself).
    For since there is no policy file, no HTTP server, and thus no classes being passed
    over the network, all one has to worry about is the CLASSPATH issue, which
    presumably, Sun already has set up, since they know exactly where all the classes
    always are (within runme.jar); though, this is not to say that how to set up the
    class path should not be documented. Again, keep in mind that I'm reading
    about RMI for the first time.
    Thanks again,
    Javini Javono
    [ January 08, 2004: Message edited by: Javini Javono ]
     
    George Marinkovich
    Ranch Hand
    Posts: 619
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Hi Javini,
    I agree completely with your last post. My application had a single executable (runme.jar) that contained a server and client GUI as you describe. The client GUI had two operating modes as you describe in 2 and 3: standalone and network. My design decision was to make 2 and 3 as nearly identical as possible (99% common code). The only real difference being how they access the database: directly, or via RMI.
    The assignment instruction's restrictions on RMI I think simplify things quite nicely.
    I believe the runme.jar is completely self-contained so I don't see the classpath issues. It's an executable jar file so all one needs to run it is access to a suitable JRE. If you go to a machine, open a command prompt, type "java -version" and get back an appropriate response, you're home free. According to my understanding the user enters something along the lines of:
    java -jar path_to_the_executable/runme.jar alone
    By the way, if you feel the need for a good SCJD book, you can't do better in my opinion than the Habibi, et al. book, "The Sun Certified Java Developer Exam with J2SE 1.4". There are some good ideas as well in Trottier's "Java 2 Developer", but good gracious does that book need an errata site (which I believe doesn't exist yet). I avoided the publisher, Que, in the past because I thought their books generally contained an unacceptable number of errors. I hoped that had changed but was sorry to see it hasn't. See the reviews for both books at http://www.javaranch.com/bunkhouse/bookSearch.jsp?category=Java%20Certification. Without Habibi's book, which among other things led me to javaranch, I would have had a much less pleasant experience with this project. I'm not aware of any other books that cover the SCJD in depth.
    - George
     
    joe black
    Ranch Hand
    Posts: 103
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    I have seen many people write individual runnable applications, then write an additional "wrapper" application that calls the individual applications based on the command line entry. This can make it easy for testing, and easy for a future requirement to split the applications into multiple jar files. In this case the instructions would literally be true.

    How do you do this?
     
    Javini Javono
    Ranch Hand
    Posts: 286
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Hi,
    As you undoubtedly know, when a Java application is started from the host
    operating system, the main class, perhaps having a name such as MyProgram, has its
    public static void main(String[] args)
    method invoked.
    So, you can do the same thing; that is, you can call another sub-application's
    main() method yourself:
    public class MyProgram {
    void someMethod() {
    ...
    SubApplicationOne.main(new String[] {});
    //et cetera
    }
    }
    Thanks,
    Javini Javono
     
    • Post Reply
    • Bookmark Topic Watch Topic
    • New Topic