If there's a way to insert a connection pool into the existing code, that would be great. (Does it accept a DataSource for example?) But it may be that's not really possible. In that case, the simplest thing is probably to use a java.util.concurrent.Semaphore, and wrap all calls to the DB with acquire() and release():
For every ThirdPartyClass method you need to access, write a new method inthis DbProtector class that puts an acquire() in front, and a release() inside a finally. That way, calls to ThirdPartyClass will block if there are more than MAX_DB_CONNECTIONS calls still active. Then, all other classes should use DbProtector, not ThirdPartyClass.
Here for simplicity I'm assuming that all methods are static. You can adapt this as necessary, depending what instance methods there are, and how they're instantiated. You might consider having DbProtector extend ThirdParty class, overriding each instance method with a version that uses the semaphore. [ May 27, 2008: Message edited by: Jim Yingst ]
I think it could possibly cause this exception - for example, if the full header never got written in the first place, because some of it was still in a buffer somewhere when the program terminated.
I bicycled on snow quite a bit last winter - the trick is to only do it when the conditions are right, and on paths that are suited to it. It can actually be pretty fun if you're on fresh powder and away from cars. I almost always used sidewalks, not roads, as the latter would quickly have their snow pounded into slush, which is no fun at all to ride on. Ice can be a problem too, but it's not too difficult as long as you're careful and keep the speed down on turns. And as long as drivers in the area know how to drive in snow, and/or you're on a sidewalk well away from the cars. At least in Boulder, Colorado this was a perfectly viable way to get around town on most days. It's possible that it wouldn't work as well in other locations.
One problem I see here is that no one uses PST or EST in May. It should be PDT or EDT - Pacific Daylight Time or Eastern Daylight Time. Whoever managed to put a PST on the original time there is probably mistaken, and should be ignored. (Or flogged.) This also appies to whoever is telling you that you "need" the output to be in EST. Not in May you don't. I would probably remove the final five characters from the String before parsing it, to avoid confusing Java's TimeZone class with a nonsense time zone indicator.
Also, three-letter time zones are not recommended for looking up TimeZone values. (Read the API for that class.) Unfortunately, Sun doesn't do a good job of documenting what your alternatives are. I recommend:
As for "I need the first format with the second time", I'm not sure what you mean. Can you show exactly what you think the output should look like?
I recommend you not use TimeZone.setDefault(), since you need two different time zones here (besides IST where you are presumably located). Instead call setTimeZone() on two different DateFormat objects - one for Pacific time, and one for Eastern. Use parse() with one, and format() with the other.
Yes, but the thing it, it is possible that people used put(Object, Object). Illogical as that may be, it's perfectly legal. It would have been better if Properties did not extend Hashtable in the first place - it should have contained one instead. But it's one of those bad design decisions that Sun made long ago, and now we're stuck with it. And Sun does take their backward compatibility very seriously, even here.
[EFH]: In computer science, you have to define your terms very carefully. The Java Language Specification defines "inherited" carefully this doesn't count as inheritance.
I believe if you look at the JLS definition, static methods are inherited. From JLS 6.4.3: "The members of a class type (�8.2) are classes (�8.5, �9.5), interfaces (�8.5, �9.5), fields (�8.3, �9.3, �10.7), and methods (�8.4, �9.4). Members are either declared in the type, or inherited because they are accessible members of a superclass or superinterface which are neither private nor hidden nor overridden (�8.4.8)." The italics on inherited indicate this is the JLS definition of the term. There's nothing here about a method or field being static - any accessible member of a superclass or superinterface is inherited as long as it's not private, hidden, or overridden. Static methods certainly qualify.
Of course this particular definition has no effect on the rest of this discussion, which has been addressed well enough by others already.
Yes, we agree for the most part (which is true also for most other posters here). I only disagreed with the "ever" part of your statement, but that's a minor point really.
Well, a Map can be sorted - see the SortedMap and NavigableMap interfaces, commonly implemented by TreeMap. Here the sorting as done as you put entries into the map, not afterwards. Also, the sorting is done based on the keys to the map, not the values. From Somesh's description it's not clear whether we're talking about keys or values, or if we're even really talking about a Map at all. Somesh, can you show some code that shows how these objects are stored or retrieved from the Map? Does the map have keys and values? Which are TroubleReportInfo - keys or values?
Also, I don't think it will make any sense to compare all dates to today's date. You will probably want to compare them to the dates of other TroubleReportInfo objects. Assuming sorting makes sense at all, which is not really clear yet.
Please don't post the same question in multiple forums - it wastes people's time if they respond without realizing the question has already been answered (or is being answered) elsewhere. Follow up here instead. Thank you.
[Pat]: You really should not be calling System.exit(); ever. You should have a highest level program trap all possible errors, handle them, and return out of the top.
[Campbell]: When I said "disagree" I didn't know Pat Farrell was posting. It was not him I was disagreeing with.
Well in that case, I'm going to disagree with Pat, at least a little. Assertions are often testing such fundamental assumptions that if they're wrong, you're often best off making it really obvious to the user that the program is broken. Fail immediately and loudly. If there are multiple threads going on, as Chris said, then it's quite possible that the AssertionError will terminate one thread (perhaps the GUI event response thread, for example) while leaving other threads running. This in turn may confuse the user and lead to additional errors, and may obscure the true cause of the problems. So I would argue that in such a case, System.exit(1) may be a valid way to handle the error. This is particularly true for rapid application development, where you don't care if the program fails in an ugly manner, as long as it's quick and easy to diagnose the problem. Other contexts may well require more robust handling, where System.exit() is not appropriate at all.
[Ilja]: So, why should I disable assertions in production again?
It's possible to have some checks which are (a) performance bottlenecks, and (b) unnecessary in theory, but you might want to test them anyway. In this situation you might want to include these extra checks during testing, but not in production. I've never actually encountered this situation in the wild, myself, so I expect it's pretty rare in general. I would agree at least that the vast majority of the time, we'd want to run the same code in production as in test, including code that's just for diagnosing errors that "shouldn't" happen anyway. Which in turn would suggest that (a) most such tests probably shouldn't be in assertions which can be disabled, but in code that runs always, and (b) assertions should probably be enabled by default, not disabled, for those rare cases where they might be useful. But it's unlikely Sun will change this default behavior at this point, so probably it's in our own best interest to enable assertions ourselves in most cases where they're used at all.
Unfortunately this is often not enough information. Sometimes the message is null - most notably, for a NullPointerException. In such cases, the class name of the exception is very informative. And that is often not part of the message itself. So
would be more informative, because for most Throwables, toString() simply takes the class name and concatenates the message. (Note that calling toString() directly is unnecessary here, as println() will implicitly invoke it for you. But it can't hurt either.) However even toString() is often not good enough, as the stack trace also has important info. There may also be nested exceptions that you need to know about. Fortunately,
prints all this information for you. In general that's a much more useful way to get info from exceptions.
Ordinarily the implementing class shouldn't matter. For some reason though, Nagmeh doesn't want to use ArrayList, so I guess that's why Campbell mentioned the fact that Arrays.asList() returns an instance of a class called ArrayList, even though it's not a java.util.ArrayList. We don't know why Nagmeh doesn't want to use an ArrayList, so we don't know if this matters. Perhaps it's for a school assignment, and the instructor doesn't want them to use too many standard libraries to make their lives easier. (That's my guess.) Let's get Nagmeh to explain the requirements a little more, rather than saturating him/her in explanations of things that may well be outside of the intended problem space.
Nagmeh, if you print the names "randomly", are you supposed to make sure that each name occurs exactly once? Or can the names repeat? And are you allowed to use other classes and methods like Arrays.asList() or Collections.sort()?
[Peter]: Polo seems to be the 'posh' sport in the UK. Ruby is starting to appeal to a wider audience. Previously ruby supporters were from English public (well private) schools, and tended to be more upper class.
Yeah, but since the arrival of Rails it's been mushrooming in popularity, and everyone seems to be joining the bandwagon.
For what you describe, couldn't you just use a RandomAccessFile opened in read-only mode ("r"")? You can use read() or readFully() to populate a byte[] buffer. Yes, every time you do this, you could get an exception - but that's also true for the solution you were describing, every time you exhaust one buffer and call next() or get() to retrieve more data. The point is, the exception may occur during the read() or noxt() or get(), but once that method returns successfully, you can examine the byte[] array with no chance of either (a) a further IOException while you examine the byte[], or (b) you modifying the file in any way.
The time has come for JavaRanch to bring in some new blood to help out with moderating groups and generally keeping the place running. Behind the scenes, we've been taking note of some posters who have already demonstrated great willingness to help out by offering many informative, friendly and downright useful responses to other posters who needed help. We've asked these amazingly helpful people if they'd be willing to take on positions as bartenders here at the ranch, and they've accepted. So without further delay, it's time to introduce the new bartenders you'll be seeing here at JavaRanch. Everyone please welcome:
Campbell Ritchie
and
Rob Prime
Both of these have been a big asset to the forums they've participated in, and we're looking forward to their continued contributions. Thank you, both of you! I will shortly be installing these folks as bartenders in their new places of power, so check out the main forums page to see who's going where.
Once again, thanks to both of you for your contributions, and welcome to bartenderdom!
EFH's statements here match my own opinions. Including the idea that golf can be enjoyable to play, true. I overstated my position in this respect. But why anyone would ever watch it on television is a mystery to me. Still, some people do, so I guess there's something there that appeals to some people.
It may be a question as to where you draw the line at what's "posh". Seems like most places I've lived in the US, you could find some tennis courts somewhere that were free and open to the public. You might sometimes have to wait for an open court, or the condition of the courts might not be as nice as for private/paid courts. I think tennis is still fairly easily accessible to the middle classes in the US, and still possible for the poor. Its popularity may skew towards the rich, but it's not exclusive to them by any means.
Then again, I haven't played tennis in quite some time, and it's possible that I have an exaggerated idea of how easy it is to find a place to play. Back in Arizona it was easy to find open courts in the summer, because most people didn't want to play for too long in the sun. Posh or not. [ May 13, 2008: Message edited by: Jim Yingst ]
As for tennis, it may be a bit more expensive to get into than many team sports like football (any variety) or basketball. That may limit its popularity a bit among the poor. But it's hardly exclusive to the "posh", at least in the US, and there are plenty of people who enjoy watching it.
Golf: I have no idea why it has any popularity at all, in the US or elsewhere.
Originally posted by Alan Wanwierd: Popular theory amongst the English is that Americans refuse to take any team sport seriously unless nobody else plays it (fear of competition?)!..
This may be a contributing factor limiting interest in the sport now, but I think the primary reasons are historical, as EFH noted, and the pacing issue. Plenty of Americans are hockey fans, even though they're used to getting clobbered by Canadian teams. Not always, of course, but often enough that it's not exactly something that the US can dominate. But we play and watch it nonetheless, because it's got plenty of action. It's a sport well-suited to American viewing tastes.
Bangar, do you have a stack trace at all? As Ilja said, the stack trace should work for a finally block, same as for other exceptions. Unless it's being caught by code that doesn't log the stack trace at all. Or unless it's an exception that does not have a good stack trace - this happens sometimes for some problems where the system is unable to keep track of all the things going on, like a StackOverflowError or OutOfMemoryException. Sometimes. But you should at least be able to discover the name of the exception, which will give a clue as to the nature of the problem.
Also, if an exception is thrown in a finally block, this may conceal another exception that was thrown before the finally block. This should not in any way prevent you from getting a log that shows where the second exception was thrown in the finally block. But if and when you find an exception that originated in a finally block, you should consider the possibility that there was another exception earlier, and you've now lost that info. For this reason it's often a good idea to avoid anything in a finally block that can cause an exception of its own - or to use an extra try/catch inside the finally (maybe refactored into a separate method) to ensure that the new exception gets logged but does not interfere with any previous exception
For example:
If an exception is thrown from in.close(), it could mask an earlier exception from the //read file section. Instead you might do this:
Even in write-only mode (pretending for a moment that this might be useful for anything), if you insert a new entry and the (hash % tableSize) is the same as for another entry (it falls in the same bucket), then the hash table needs to use equals() to test whether you've actually got the same key as the existing key (meaning you're replacing the previous value) or you've got a new, different key. So even a write-only table needs equals(), at least sometimes.
One reason to override hashCode() but not equals() might be to correct a defect in an existing class. Perhaps you have a class written by someone else, where they overrode equals() but forgot to override hashCode(). In some cases you might not be able to modify the source of that class, but can create a better class by extending it and providing a better hashCode(). So really, both methods are being overridden by someone, but you are only overriding one of them.
Another possibility is that you can create a legal but inefficient hashCode() method such as this:
This will always obey the contract of hashCode(), even if you don't override equals(). It will lead to very poor performance of any HashMap you put it in, but the HashMap should still work. Why would you ever want to do this? Well, the best reason I can think of is that you might need to test a HashMap or similar hashtable-like class, to make sure it works correctly even when hashcodes are identical. Or to test certain worst-case performance characteristics of the class. Or for teaching purposes, to show what would happen.
I don't think there is ever any reason to override hashCode() without equals() in a good, well-designed system in production (as opposed to testing).
String manipulation shouldn't have anything to do with the perm generation unless you use the intern() method. Which is definitely a possibility here, given the symptoms. But if intern() is not used, other string manipulation shouldn't affect this particular problem.
Jeppe: the overall memory usage isn't relevant here. The problem is that the MaxPermSize is too small for what you're using. Definitely try increasing that. But it's also possible that you've got some sort of memory leak that will expand to eventually overflow whatever size you have. If that's the case, increasing the MaxPermSize may delay the problem, but not prevent it. Still, it's very much worthwhile to try increasing the size as Akshay showed, to see what effect that has.
It's not that the metacharacter doesn't matter at all. But if the quantifier can be zero, then the pattern can match zero occurrences of the metacharacter. So there are at least some possible matches where the metacharacter does not occur at all.
Try using + instead of * - you will see that + means at least one occurrence of the preceding character. So it will not give you this behavior of "ignoring" that character. [ May 13, 2008: Message edited by: Jim Yingst ]
[John]: OK, so if I said, "Ask not what country can do for you, ask what you can do for country", would that phrase be meaningful in any context, or would it be just broken English?
Probably broken English. But I suppose it could possibly be a reference to the musical genre, country (as in country and western music). I could imagine a comment like that being made at the Country Music Awards, for example. But without such a context, I would probably just assume it's broken English. [ May 13, 2008: Message edited by: Jim Yingst ]
[John]: So, the way I understand it, the pronoun "your" must be injected when some specific items are referenced, such as "vegetables on your plate". Is that correct?
Unless they're someone else's vegetables. There's usually no need for parents to say "eat your brother's vegetables", but I suppose it could happen. We could also have "eat the vegetables" (certain specific vegetables, but with an indeterminate owner) or "eat some vegetables" (fairly vague) or various other combinations.
[John]: That means that "use your brain" can not take the form of "use brain", because it's always your brain that you are using, right? But then why do people say, "eat shit"? Don't they specifically mean "eat my shit" or "eat your shit"? I am still very confused.
Generally, in this context, any shit will do, regardless of original owner.
I can't really follow what you're trying to do here. Do you want a List<Byte[]> or a List<Byte>? Because your code shows a List<Byte[]> with a get() method that returns a Byte, which won't work. Which are you trying for? There's also a super(new Byte[]) call that makes no sense at all to me. Really, if you use your compiler before you show us code, it will help weed out these confusing side issues and let you focus more on meatier things.
Well, some places give you the item free, while others will simply honor the posted price - even if it's incorrect, from the store's perspective. On rare occasions the store will apologize and insist on the higher price. I can understand that if it's a mistake and they need to ensure they're not losing money, but I also have little patience for incorrectly priced items, so I tend to reject items if they come up higher than the posted price. I'll get the item from another store instead, one that either has their stuff priced correctly, or honors the posted price. It's pretty rare that this situation comes up though, in my experience (in the US).
Agreed, that's why I favor return over break. And with short methods, other concerns about readability (for return/break/continue) tend to go away too; it's a non-issue. [ May 09, 2008: Message edited by: Jim Yingst ]
I don't know what you're responding to here, but I do sometimes post Google links for others. Some people apparently do need reminders that the resource exists; I don't know why. Here at JavaRanch often the problem seems to be that people want an answer explained directly to them, rather than taking the time to go find the answer. Of course for those of us posting answers, it's much easier to post links to existing explanations. When I post Google links, I have also looked at the first few results, and determined that they are likely to be useful to the questioner. And I may have used search terms that the original questioner may not have thought of. Plus, often a question is very ague and/or general, so it's not worthwhile to spend much time on the answer until they focus their question better.
Jeanne: not mine, no. Just a link I saw posted on another forum, shortly before I saw the "evil" comment, so it was the first thing that sprung to mind.
In medieval Europe, cats were often believed to be associated with the devil. During the Black Death many were killed outright, since the disease was believed to be God's wrath against evil. Which is unfortunate, not just for the cats of course, but also for the fact that the cats would have reduced the rodent population which was actually responsible for spreading the plague. Oops. Cats were also often thought to be companions for witches. Let's just say they weren't called the Dark Ages for nothing.
![[Logo]](http://www.coderanch.com/mooseImages/moosefly.gif)
