Jay Bromley

Ranch Hand
+ Follow
since Aug 09, 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 Jay Bromley

I agree with you, as mentioned above, I think all GUIs presented by a window manager should be the same. This, however, presents a problem for me. To have my Java app present a consistent look and feel I have to use the com.sun.java.swing.plaf.gtk.GTKLookAndFeel class. On my system, UIManager.getSystemLookAndFeelClassName() returns javax.swing.plaf.Metal, which is not what most apps on my system look like, hence the need for the above mentioned class. Is this class part of the normal JDK? I haven't downloaded it specifically, so I have to assume it is.

Am I thinking too much about this for the SCJD? In the real world what happens when you want the app to look native on all platforms? Apparently some platforms (mine - Linux, no Gnome or KDE) can't tell Java what their native look is, so simple querying may not work.

Thanks and regards,
Jay
Hello there,

According to How to Write Doc Comments for the Javadoc Tool:

Guidelines - Which Exceptions to Document
Document the following exceptions with the @throws tag:

* All checked exceptions.
(These must be declared in the throws clause.)
* Those unchecked exceptions that the caller might reasonably want to catch.
(It is considered poor programming practice to include unchecked exceptions in the throws clause.)
Documenting these in the @throws tag is up to the judgment of the API designer, as described below.



I know one of the code checkers I've used also complains about @throw tags whose exceptions don't appear in a throw clause. I turned that feature off.

Regards,
Jay
Hello all,

I was wondering what all of your takes on window decorations (min/max buttons, title bars, etc.) is. That is, should the app use Swing window decorations or native window decorations? I personally think window decorations are a window manager's job, as it guarantees uniformity of appearance, however, I'm wondering if Sun wants to see Swing decorations.

I noticed that Max's app uses native (wm-supplied) decorations and so this got me wondering.

Thanks and regards,
Jay
Hello there,

The instructions do read "all classes and interfaces" so I'm taking it at face value and documenting everything. It's a little bit more writing, but I tend to write most of the comments first, so no big deal. I do, by the way, have private inner classes (ActionListeners.)

javadoc has the -public, -protected, -package and -private switches to determine what javadoc generates documentation for. Per the previous comment, I'm thinking I have to use -private.

Regards,
Jay
[ October 15, 2004: Message edited by: Jay Bromley ]
Derek,
Glad to have been of help. I'm not familiar with UltraEdit but you might look for something that mentions soft/hard line breaks. Sometimes this is tied up with auto-wrapping as well: soft linebreaks facilitate auto-wrapping since a newline doesn't have to be moved around when you change a line, breaking lines becomes purely a display trick. Good luck in finding the appropriate settings.
Regards,
jb
Hello,
Something that I've found to be fairly useful for getting ideas about how to do javadoc is the source for Java itself (or more accurately J2SE). Not only does it give you an idea of what to write, but it also provides some tips on formatting. My javadoc looked like a mess until I started doing some of the things I saw in the Java source. One last benefit (maybe) is that if you have a doubt and want to document it in choices.txt citing the Java source could be a good supporting argument for doing what you did.
Regards,
jb
Sam,
Not only is MappedByteBuffer's implementation OS-dependent, but it seems that Sun has recently banned the use of NIO for the assignments that it is distributing (there was a thread on this not more than a few days ago) so this would make the use of java.nio.MappedByteBuffer illegal.
Regards,
jb
Hey Derek,
I'll take a whack at it. To me it looks like you don't have newlines at the end of your lines of code so javadoc sees your comments as one long string of characters on a single line. I believe javadoc removes asterisks when they are the first non-whitespace character on a line, so not having newlines could be the source of this problem.
This could be something related to your editor. Some editors (like jEdit, for example) do soft linebreaks or automatic wrapping, so you type until the end of the line and at some column less than 80 your editor automatically wraps, then you press tab to align the * and keep typing on the next line without inserting a newline. Soft linebreaks generally don't insert a newline when you save them so you get the one long line effect mentioned above.
Hope this helps,
Regards,
jb
Hello all,
I've received a response back from Sun saying the same:
Monica.Green@Sun.COM wrote:


We recently changed the assignment rules to explicitly forbid the use of
NIO and the other APIs you saw mentioned on JavaRanch. However, this change
is not retroactive. If your assignment HTML document does not explicitly
forbid the use of NIO, you are free to use it.


So it looks good for those of us that have already done work using NIO.
Regards,
jb
Lance,
Good eye! For me that resolves the issue. My assignment says nothing about not using NIO. Still, it will be interesting to note what Sun says, though after reading this little bit (I don't know how I missed it before ) I don't see that Sun could say don't use NIO.
I'm breathing easier.
Thanks,
jb
Hello all,
On Thursday I sent an e-mail to Sun along the lines suggested by Mr. Marinkovich (but perhaps a little bit more verbose) and I have yet to hear anything. I know it's only been a day and they're busy, I'm just a little bit concerned, I used NIO and was quite pleased with my efforts until I saw this thread. Many thanks to Colin and George for starting this thread, conceivably it could save some of us who used NIO from disaster.
In any case, as soon as I hear back I'll post back here with the news.In the meantime, I'm just chilling and going on with the business of finishing this thing.
Regards,
jb
Aaargh!
I'm using NIO and I thought I was within a couple of weeks of submitting. Now, I'm not so sure. I have to agree with Morgan and say that it's crazy that they don't tell you about such restrictions in the assignment itself. My assignment (Bodgitt & Scarper 2.1.2) says :


Use of Standard Elements
Use of functionality provided by the core Java classes will be preferred to your own implementation of that functionality, unless there is a specific advantage to providing your own implementation.


and


Restrictions on RMI
To avoid unnecessary complexity in the marking environment certain restrictions are placed on solutions that use RMI. Specifically:
# You must not require the use of an HTTP server.
# You must not require the installation of a security manager.
# You must provide all classes pre-installed so that no dynamic class downloading occurs.
# You must use RMI over JRMP (do not use IIOP)


and


The user interface for this assignment must satisfy the following criteria:
* It must be composed exclusively with components from the Java Foundation Classes (Swing components).


but nothing at all about what I can use for I/O. I thought core Java packges meant packages java.*, so my reading was that java.nio is part of the core Java classes and so should be good. I thought that the other things mentioned (EJB, Servlets, JSP, etc.) are all part of the javax.* package hierarchy and so naturally are excluded by the first quote. The fact that the exception for JFC (javax.swing.*) was explicitly made seems to support the idea that anything in java.* is fair game.
So I guess it comes down to what takes precedence, the info on Sun's website or the assignment itself. I'm going to try to get some info from Sun about this. I'll report back.
Regards,
jb
Hello James,
Well, the API seems to indicate that locking is not mandatory, since the find method doesn't require a cookie. This is one of those things you've got to decide on and justify yourself.
There's a couple of issues to take into account. First, given that you don't know beforehand what records will be returned for any given search, what are you going to lock? You'd have to lock the whole database down (which I believe some here have done), and for me, the problem with this is it will reduce concurrency -- no one else can get anything done until the find completes.
Note that you also have the possiblity of doing some type of synchronization that doesn't use the lock method. For example, you could use a read/write lock and read lock the database during the find. This way, other threads could read during your find, but not write until the find is complete. I like this much better than locking the whole database because it doesn't have to bring all of the other threads to a stop. This is what I'm aiming for.
A last possibility is minimal synchronization. This is what I'm doing right now, but I've got a good feeling that I'm going to change it for what I mentioned in the last paragraph. My code is something like:

The above seems to work fine, and I've been sure to document the snapshot behavior in my choices.txt.
Regards,
jb
Hello,
Emacs with JDEE and Emacs Code Browser is fairly good and runs reasonably quick even on older machines. Decent for handling projects, yet it doesn't hide the details that a developer should know about.
I'm not Max, but regarding your other questions, I think syntax highlighting is a good thing. It increases the readability of code and what with cheap color printers, most IDEs will let you print out code with syntax highlighting. This leaves no reason to look at monochrome code.
A debugger might be helpful, but if you use something like JUnit to unit test everything, you shouldn't have to use it much. For the SCJD project, my experience is that the must critical place that it might be used is to debug locking code, BUT, using a debugger on multithread code can be difficult since it inherently changes how your code works. (E.g. code might deadlock in real life, but work when trying to step through things in a debugger.)
Regards,
jb
Eugene,
I agree with Mark. Since I'm new to Java, for me this project is a great learning experience in addition to a cert. An ASCII help file is the easiest way out, but you have to ask yourself, "Would I be happy with an app that only provided offline plaintext help?" My answer was "probably not."
This lead me to using DocBook to create documentation and developing a simple HTML viewer to look at it. On the way, I learned about some good ways to handle documentation for Java apps (JavaHelp + DocBook), which for me is the most valuable part of all this. No, I supposedly won't get more points than someone who does a simple ASCII text file, I would think it makes a better impression on the grader. On the other hand, Mr. Krebs provided a text user guide and scored very well.
In summary, if you've already got a good way of doing help or its not important for you, go with plain text. If you're taking this as a learning project, do some investigation on creating help.
Regards,
jb