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

[Javini Javono]

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]

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]

Hi Javini,
You might be interested in the discussion Topic: NX:Contractors: Structure of package:

https://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]

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]

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]

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]

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 https://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]

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]

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]

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]

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