John Cozens

+ Follow
since Jul 15, 2004
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 John Cozens

Thanks to everyone on the SCJD site. I learnt a huge amount from the discussions between Andrew M and his fellow gunslingers. And from everyone that posts to the site, so thank you all. IMHO, it's the quality of discussion that makes this certification, not just hunting for that elusive "right" answer. Big thank you also to Bert Bates and Kathy Sierra, your cert book is just exceptional.

Breakdown was:
General 97/100
Docs 70/70
OOD 30/30
GUI 28/40
Locking 80/80
DB 40/40
Server 40/40

Which was interesting, as I've been a Swing GUI lead for the last 7 years! My guess is that the lost points may be because my design was more than just a standard "tick the boxes" one, but I felt it offered a much nicer user experience than some that had been posted and appeared in text books. Ah well, not to worry.

I actually got the result a few months back, but haven't had a chance to post before now as was in the midst of moving city and starting a Masters degree in HCI, so please feel free to get in touch, but I may not be able to remember every last detail
11 years ago
Thanks Michael, understood. My problem here is that we're using a third party Look & Feel API which overrides the default UIxxx classes, and these all appear to have been marked final (and my company isn't happy to pay for a source code license). Not important enough to spend more time on right now, but I really appreciate your suggestion.

12 years ago
Thanks for your fast response, Michael.

That works well for JButton, and should be fine for JComboBox too. I can probably live without JCheckBox foreground changing's only the tick I need to change, not any accompanying text label.

12 years ago
Hi, I am trying to change the font color of the text within a disabled JButton, JCheckBox and non-editable JCheckBox.

For subclasses of JTextComponent (which none of these are), I appreciate that I could use:

I don't want to use, for example:

because this will change the disabled foreground of ALL disabled JComboBoxes within my app, which is undesirable - I want to be able to change the font color for selected comboboxes only.

I would also prefer not to have to play with UI Delegates, mainly because the 3rd party UI API I'm using has declared these final and I'm not in a position to amend the source code.

There are several previous postings about this issue on JavaRanch, and indeed in the Java Bug Parade, but none of them has offered a solution which works for my specific scenario.

Thanks in advance for your help and ideas.
12 years ago
I am reading large volumes of data from a file into a charting application. As the source file can be tens of MB and data for a single chart display can be several hundred KB, it makes sense to me to use a MappedByteBuffer (MBB). No problem so far.

The data from this MBB then needs to be parsed and converted into chart-friendly format. Again, no problem.

However, my chart display is intended to update in real-time as new data arrives (i.e. as new data is added to the end of the original data file from an extrenal source). So what I'd really like is to be notified whenever the MBB changes, so that I can then interrogate the change to decide whether or not to update the chart currently visible on-screen. Given that most of my work is Swing-related, I was looking for something along the lines of a MBB.addChangeListener() method or similar, but no such thing exists. I'd prefer not to have to set up a dedicated thread to monitor the MBB constantly if a cleaner solution already exists somewhere within the API. I've also looked at "listeners" in RandomAccessFile and FileChannel, both of which I use to back the MBB, but so far to no avail.

Does anyone have any smart ideas?

Thanks for your help.
12 years ago
Hi Mike,

'Of type Singleton' ?

So a subclass of Singleton?
How can you have a subclass if the default constructor is private?

No, I agree with you, my fault for not explaining clearly. What I meant was that if you had some code like this...

...then if you ran MyMainClass, your Singleton class would be loaded immediately, before even the first line of main() was run, regardless of whether MyMainClass ever actually called Singleton.getInstance(). Therefore, if you used the second version of Singleton from my last post...

...Singleton.instance would exist as an Object as soon as your app ran, given that it's a class (static) variable within Singleton. Using the other method, this doesn't happen. Singleton.instance remains null until another class calls getInstance() for the first time. At least, this is what my debugger is telling me. So if you did have a million classes that used the above form of Singleton, I'd expect that you'd have constructed a million Objects on start-up, regardless of whether you ever called getInstance() on any of them during the course of the app. They'd just sit there, presumably consuming space on the heap.
Pedro, while experimenting last night I did end up with something not too different from your suggestion, so thanks for that. I have Joshua Bloch's book, so I'll definitely take a look at Item 21 on typesafe enums.

Mike, OK but what if you have a variable within some other class of type Singleton (which you don't plan to instantiate by using Singleton.getInstance() for the next few days). Given that the static variable "instance" in Singleton is, well, static, won't it get initialised during class-loading? So if you use this form:

...that's fine, 'instance' will remain null until another class calls getInstance() on it. But if you use this form instead:

...then 'instance' will actually become an object of type Singleton as a result of class-loading, regardless of whether another class ever calls getInstance() on it or not? I'm not sure we're actually disagreeing on this, I'm just trying to be totally clear in my own mind.

Eben, thanks, I hadn't seen that approach before. I'd pondered using double-checked locking, although opinion seems to vary widely on whether that's totally safe. I'll go away and experiment with the different alternatives.
Sorry Pedro, I meant a setXXX() method, not getXXX(), for example using something like x.setState(outerVariableValue) as a mechanism for getting info about one of Outer's member variables to your Singleton instance.
Guys, thanks for your quick replies.

OK Pedro, that's a neat trick. So effectively you're using Inner to act as a "Singleton wrapper"? Which means that Inner can get access to Outer's members, although Singleton itself still can't (unless you use x to get values from Outer then mail them across to Singleton using a getXXX() method?). Hmm, so are there still a couple of issues:
i) for every Singleton I now have to create 2 classes - 1 original stand-alone (Singleton) and a "wrapper" (Inner) buried within the ultimate parent (Outer)? That doesn't seem ideal but, agreed, it does work;
ii) to keep as much encapsulation as possible, let's say I want to put lots of state-based methods in Singleton, which in turn need to set/un-set GUI components within Outer. As Singleton is outside the scope of Outer, it still doesn't have access to Outer's members. In this case, would you need to add all of the relevant GUI-changing methods to Inner instead? If that's so, have you then defeated the point of having a Singleton in the first place? Although your Singleton is a genuine Singleton, Inner is not.

So thanks for the solution, it's really interesting. Any further thoughts on these secondary issues would definitely be welcome

Thanks Mike. I reckon you and Pedro are both right - these are merely different solutions to achieving a Singleton. Yours is definitely more appropriate when you want to instantiate your Singleton up-front (say during initialisation while the user's looking at a dazzling splash screen ), while Pedro's is more appropriate when you want to use "lazy instantiation"...that means you want your Singleton built on a "Just in Time" basis, the first time that getInstance() is called, and not a moment sooner. That can be useful if say you've got 10 million potential Singleton Objects, of which you'll probably only ever need 50 during a typical program run, but you don't know which ones you'll need in advance.


Hi folks,

I'm using the State design pattern to handle state changes within my client-side UI. Most of the design pattern text books (including GoF) suggest that it makes sense:
a) to make each State an inner class (so that it can access variables within the parent "Context" class)
b) optionally, also to make each State class a Singleton

OK, I agree with them. But here's the problem...

A Singleton generally makes use of a static instance of itself, accessed via a static getInstance() method. BUT static declarations aren't allowed within an inner class. The immediately obvious solutions are:
1) don't use a Singleton for each State (but that loses some efficiency/encapsulation benefits that I'd like to retain)
2) make each State a stand-alone class (but then I've lost the benefits of access to the parent "Context" class)
3) make each State a static nested class (no obvious major benefit over option 2)

Anyone got any ideas? Am I missing an obvious solution?

Thanks in advance