Alex Sbityakov

Ranch Hand
+ Follow
since Jul 23, 2001
Merit badge: grant badges
For More
Cows and Likes
Total received
In last 30 days
Total given
Total received
Received in last 30 days
Total given
Given in last 30 days
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Alex Sbityakov

Score: 151
The maximum possible # of points is 155; the minimum to pass is 124. General Considerations(maximum = 58): 56 Documentation(maximum = 20): 20 GUI(maximum = 24): 24 Server(maximum = 53): 51
I thought that the certification was a wonderful learning experience. Advice for beginning programmers: until you know design patterns, don't attempt this certification. Everyone can hack out a solution - the goal is to create an elegant design.
I had a running application in three days - but
I had a lot of free time since I just finished school. I spent the next week refactoring and writing documentation.
Overall, the advice is to stick to the requirements and keep things simple. I would recommend two books: Applying UML and Patterns,
Design Patterns Explained. I believe that everyone should read these books before they embark on developing an application.
Thanks to Mark and Peter.
All the best,
21 years ago
But if you look at the flight number in the file, the airline is part of the string - the first two letters.
If you decided to lock on record number, did you keep a hashtable with key: flight number and value: record number somewhere in your code?
My feeling is that people seem to be locking on record number. Has anyone done it on the flight number, instead? Since, it is the PK, it will always be unique even in the unlikely case of merging databases.
I think locking on flight number is superior because you do not need to keep any map of flight no (returned by the gui) to rec. no. The idea is that you don't want to find the corresponding record no of the given flight number in the booking method.
Just curious, what do people think?
On the client-side I issue the following call to get a reference for the RemoteConnectionFactory which returns instances of DataInterface.
This is the line that generates the exception.
RemoteConnectionFactory rcf = (RemoteConnectionFactory)Naming.lookup("rmi://localhost:1099/ConnectionFactory");

Has anyone else encountered this before?

Exception in thread "main" java.lang.ClassCastException: suncertify.server.RemoteConnectionFact
Fellow Ranchers,
I have a question about the relationship between the View and the Model. According to the MVC pattern the Model should notify the View of state changes. Some posters have proposed using the fireXXX... methods to take care of that, notifying JTables in the View from the TableModel in the Model. My concern is doesn't this create a strong coupling between the classes?
Is it better to use the plain old Observer pattern and just shuttle text-based data from the Model to the View.
Incidentally, some people (who have passed the assignment) did not have the Model notify the View, but used the Controller for that purpose. This sounds strange to me,

Cheers and TIA,
private methods do not particiate in inheritance, because the are invisible to the subclasses. This is precisely why, the program says that it can't find method write() in class Process - it is simply invisible to everything outside the class.
I believe that private and static methods are statically binded.
So, like fields they are invoked based on the type of the object.
char c = '\u30A0'
targetObject must be Runnable
for the exception question, you're best to work through it and/or run the code yourself,
Here's the rundown of what happens:
1. Tux is initialized inside main
2. method piggy is called
3. piggy modifies the parameter sname (not class member)
4. piggy calls start(), which begins the execution of run()
Now we have a race condition. Basically we don't know which will execute first: the print statement or the loop inside run(). That's why the answer is 4

Constructor is provided by the compiler only if the class does not define any constructor

Yes, a default no argument constructor is provided in this case.

it calls the default 'no-args' constructor of the super class.

This is trickier. Basically, if the first line of the constructor is not a this(..) or super(..), then a super() call is inserted implicitly.

However constructor does not initialize instance members and class ( static ) members of the class. This initialization is done by 'new' statement at the time of creation of object.

Well, first, to get the semantics right, the constructor doesn't really do anything. This is what happens in the larger scheme of things. A class is loaded, its static initializers are called, the constructor is called, instance initializers are executed, the rest of the constructor is run. If a superclass comes into the picture, things get even trickier. The point to remember is the superclass is initialized before the class (that means its static, instance initializers and constructor are called before their subclass counterparts).
I think C is correct, since clicking a button (among other 3 things) does generate an ActionEvent.
InputStreamReader and OutputStreamWriter allow you to use different character encodings (i.e. InputStreamReader(in,"UTF8"))
FileWriter, FileReader use default encodings. These classes actually automatically create instances of ISR and OSW with default encodings.
I just ran through the Boone exam. My opinion is that if anything in the exam surprises you (besides, of course, the errors) you should hit the books. I would recommend the Majji mock, since it contains a much trickier questions.
I don't understand your logic, Manfred. It is true that static variables are initialized when the class is loaded and before it is instantiated. But this has no bearing on whether they are accessible from static methods. Non-static members are not accessible in static methods, apart from the example above.
Static methods can access non-static members using class type references. That's why wrap.arguments = args; works, while arguments = args would not.