David Fishman

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

Recent posts by David Fishman

To all who are interested, I actually emailed Sun regarding this and they replied that it is acceptable for the Data class to have default access.
Hi all,

In the interest of hiding the data access details from the GUI client I have created an adapter interface and class as already discussed in many threads. In addition, I am thinking of changing the access to the Data class from public to package (default), so that the only methods accessible to the GUI client would be the adapter ones.
I have actually seen this suggested in previous threads, with some warnings that this may not be acceptable (though I can not see any "musts" being violated by this), or that Sun's automated checking actually expects the Data class to have public access and would fail the submission otherwise.
Has anyone implemented the above and passed, or knows of other people's experience ?

Thanks
Hi all,

I have done some searcing on the reasons for wrapping the database strings (which the data layer has to use anyway according to Sun's DB interface) in a Contractor (or Record) class. Here is what I found so far, but I still can't justify using such classes for my design, considering I would really like to keep things as simple as possible.

Caching : which I consider out of scope
Sorting (providing comparators etc) : the word sort is never mentioned in Sun's instructions
Gui development (tableModel) : this one actually came close to a convincing argument, but then it seems to me that not much more is usually done here other than "conversion" of strings in the wrapper class to strings in the gui display
Future extendability : yes this makes sense as well, but considering the above it seems that dealing with strings now and adding the wrappers later would not be a huge task if the coding is kept relatively "clean" (which it should be for the General Considerations marks among other things)

Now I did introduce a separate MetaData class, but to me the main idea there is to separate functionality rather than form. On the other hand would it look "weird" to have a MetaData but not a Contractor class ?
Also it looks like many have introduced those wrapper classes - am I missing something here ?
I've been hanging around this forum for a few days now and would just like to express many thanks to all the dedicated people sharing their thoughts and experiences !
Back to the topic at hand - from what I've read so far about the "spirit" and intentions of the SCJD, I would tend to think that implementing a cache is more than little out of scope. To be sure there are performance and maybe even integrity benefits, but as far as I can see this is not telling the markers much in terms of the candidate's object-oriented abilities using J2SE !
I know that caching can be a tricky business, and in fact I applaude those who actually tackled it, but to be honest it looks more like a "technical manipulation" than central design choice for this type of assignment.
I can see that discussion on this book is alive and well . . .
Many things have already been written and discussed in this and other posts so I will shorten my comments as much as I can.
I passed my SCJP this past August and continued to the SCJD without any other Java knowledge or experience. I must admit that I was also quite frustrated with the book's lack of depth and breadth on the technical side of things. But over time I realized that I have quickly forgotten my own experience as a developer in the mainframe world - "technical handholding" no longer applies in the transition from the programmer to the developer level. Technical competence and flexibility is assumed as a given and the focus shifts to design/analysis/usability/user-friendliness/maintainability etc etc. This is exactly what Max's book does. There is no question that improvements can always be made, however I would say that this book is definately a must (but also not the only) source for my SCJD preparation.
Hi all,

First I have to extend many thanks to all the contributors to this excellent site - notice that my number of posts is not high at all, this is because this site has such a large amount of quality information. With a little creative and persistant searching I found many of the answers to my study questions already posted and replied to !

My only study text was Mughal and Rasmussen's "Programmer's Guide to Java Certification" 2nd ed. As was noted by many others, they assume some programming background and in general the text and the exercises were not easy however I found this to be well worth it !

As far as mock exams are concerned, I did what seem to be the "standards" when looking at many posts - Marcus Green, Bill Brogden, Dan Chisholm. Yes it's true Dan's tests are harder than the exam but if you do what he suggests and treat them as learning tools, you will find his explanations and in fact the whole experience very valuable. I usually scored in the high 70's or low 80's on Dan's tests compared to the real 93%.
I also did Valentin Crettaz's exam - this might not be for everyone since his questions are much harder than the real thing. If you are not easily discouraged by the number of wrong answers you will get, his explanation are actually the "deepest" I found and his links to the JLS and the API hit their mark every time !
My final 3 mock exams were from the CD that came with Mughal's text - I found the two Whizlabs practice exams to be quite close to the real exam, and Mughal's exam was a bit harder (I got in the high 80's on it).

Thanks again to all who have contributed to this site - you were a very important resource in arriving at my exam result !
19 years ago
Very insightful and clear !
Thanks very much for this sever !
19 years ago
The same reply is also posted in a related thread from Jan 26, 2004 titled �Is this the right forum ?�
Section 5.3 in the JLS indicates


...Method invocation conversions specifically do not include the implicit narrowing of integer constants which is part of assignment conversion. The designers of the Java programming language felt that including these implicit narrowing conversions would add additional complexity to the overloaded method matching resolution process...


More details can be found in the JLS
19 years ago
This is a reply to a thread from a few months back, however I thought I would share something I found recently in the JLS regarding not allowing implicit narrowing conversions for parameter passing. Basically the prior replies were on the right track, and here is what section 5.3 of the JLS indicates :


...Method invocation conversions specifically do not include the implicit narrowing of integer constants which is part of assignment conversion. The designers of the Java programming language felt that including these implicit narrowing conversions would add additional complexity to the overloaded method matching resolution process...


More details can be found in the JLS.
I will also post the same reply in a related thread I started Jan 1, 2004 titled �implicit narrowing conversions� just for completeness.
19 years ago
Hi all,
Sorry for coming into the discussion at a late stage. While I agree with most of the concepts given here, my opinion is that the main issue I have had to deal in my five years experience as a programmer is expectations of quality, and related resourcing.
For example - if quality expectations were high, then usually a project (especially large projects) would be staffed with business users who concentrated on business requirements, analysts who translated business requirements into specifications, and programmers who concentrated on programming. Under those circumstances I found Matt Cao's 80/20 split to be reversed (80% technical) since there is a great deal for the programmer to consider in terms of proper technical design, efficiency, maintainability, correctness etc. etc.
If quality expectations were lower, usually the analysts or programmers would disappear and those job functions merged, and then the 80/20 split would lean towards the business as opposed to technical knowledge.
Now very unfortunately, my opinion is that even though I have only five years programming experience, I have already managed to observe a general declient in terms of expected quality, with a tendency to reduce staffing and turn away from customization and towards more "turnkey" solutions. In general I think that, as long as quality expectations are high enough, we are still a long way away from accountants or business users changing a few lines of code here and there to get the functionality they need.
Is programming a dying profession ? Depends on how quality-aware the future is !
Thanks, David Fishman
20 years ago
Thanks for your reply, David. I now realize that I took the wording of the question too literally - the intention of the question was to recognize guaranteed behavious under normal operation of the JVM. I was thinking along the lines of : what if there is some event in the JVM that halts execution of all threads period ? how then can we really guarrantee the execution of thread A ? etc.
Hi all,
Please help in understanding the following. Thanks in advance !
One of the questions in the threads chapter in Mughal and Rasmussen's "Programmer's Guide to Java Certification" is this :
Given the following program, which statements are guaranteed to be true ?

The question asked for two correct answers
(a) The letter A is always printed
(b) The letter B is always printed
(c) The letter A is never printed after End
(d) The letter B is never printed after End
(e) The program might print B,End and A, in that order
Their answers were (a) and (e). The explanation they gave was :


Because the exact behaviour of the scheduler is undefined, the text A,B and End can be printed in any order. The thread printing B is a daemon thread, which means that the program may terminate before the thread manages to print the letter


Here is my confusion - they say that a daemon thread "...is stopped if there are no more user threads running...". Therefore, relating this to their explanation above, the thread printing B might not get to execute if both the main thread and the thread printing A terminate. And, if this could happen, what makes (a) one of the correct answers - how can we
gurantee that the thread printing A will get to execute and print A before it is terminated ?
I can understand that there might be a better chance for A to be printed out of a non-daemon thread, but it seems to me that this is not what the question asked for. Am I missing something ?
Thanks to all who replied !
20 years ago
Hi all,
Awhile back, I posted the questions below regarding implicit narrowing conversions but unfortunately haven't received any replies. Would asking these questions be more appropriate in the intermediate forum ? The questions were more why's than how to's but I seem to recall seeing similar discussions on other topics.
Thanks !


My Java text mentions the following as conditions that must hold for implicit narrowing conversions on assignment

  • the source is a constant expression of either byte,short,char or int
  • the destination is either byte,short or char
  • the value of the source is determined to be in the range of the destination at compile time


  • Then it goes on to say that no implicit narrowing conversions whatsoever are allowed on passing to method parameters.
    My first question is - why only allow types narrower than long ? Why not allow (for example) a constant double value that is in range ?
    My second question is - why not allow any narrowing at all for parameter passing ? My understanding is that parameters are really created only when methods are called at runtime, but if the rules above hold wouldn't it make sense to be consistent with the treatment of assignments as is the case in other operations ?

    20 years ago
    Thanks all - much clearer now.
    20 years ago