Posts by bguild

the instance of the builder is passed to Builder.build(this) method

That sounds like you are passing an instance of Builder to a static method of Builder, which seems very unlikely.

I can think of two answers to your question. My favorite is that objects that never change are easier to use and safer than objects that change. If your program ever has problems, finding those problems will always be made harder by each object that may be changing over its lifetime, especially if multiple threads are involved. Even better than an object that never changes is an object that cannot change because it has methods that could cause it to change if called.

Another answer to your question is that even when an object is allowed to change over time, there are often constraints about what states are legal. You'll probably run into this in practice, but realistic examples are difficult to construct artificially. An unrealistic example would be a class ShapePosition that contains a Point and a Shape, and requires that the Point always be inside the Shape. It would be impossible to construct a ShapePosition by using a no-arguments constructor followed by setPoint, and setShape without causing the ShapePosition to exist briefly in an illegal state, and that means you won't be able to enforce that every ShapePosition must always be legal. Using a builder, you can completely avoid that issue by allowing the builder to be in states that wouldn't be legal for the final …

The "proper" way to do it is probably to subclass JTable and override the method that implements the UI for the table header.

I don't see anything at all improper about taking the JTableHeader and making use of it for specialized purposes. JTable goes to the trouble of giving us a getTableHeader method, and we have all the listeners we need to draw extra widgets around the JTableHeader that move as the columns move. The whole system seems designed to make this sort of thing possible.

On the other hand, subclassing is dangerous and error prone. I don't claim to have any special knowledge about what is proper, but using subclassing is asking for trouble.

I haven't benefited as it relates to a learning experience.

If there is any part of it that you don't understand, I'm sure we will be glad to explain it to you.

Not sure what rules you are referring to... "A display area for a short text string or an image, or both. A label does not react to input events."

I'm refering to the fact that a HeadingsLabel is a JLabel and therefore everything in the documentation for JLabel should apply to HeadingsLabel. Even that rule you quoted is being bent, or at least not being followed in the spirit in which it was intended, since a HeadingsLabel is incapable of ever displaying an image. More importantly, HeadingsLabel has methods that are clearly broken such as getText, setText, getIcon, setIcon, and many other methods.

Of course, this is only a technicality. Your solution works very nicely.

feel free to criticise!

I find the way HeadingsLabel extends JLabel to be a bit strange. HeadingsLabel doesn't conform to the rules described in the documentation for JLabel, and therefore isn't a proper JLabel. It looks like a JPanel could have served the same purpose with less potential confusion.

There is a big difference between a field and a local variable. You must not treat them lightly. When you say JButton team1 on line 28 you are creating a local variable called team1 and every time you use the name team1 in the method after that you are using the local variable, not the field of the same name. The type JButton is not something you can sprinkle into your source code at will without consequences.

In other words, when you say if(source == team1) on like 46, it is not the same team1 as the one you used in the constructor. This team1 is still null, so source == team1 is never going to happen.

I recommend that you avoid java.awt.GridBagLayout. It is troublesome and overly complicated, so people rarely use it in practice which makes it hard to find good advice about its use.

In this case especially you should avoid layout managers because your layout needs are very specialized and specific. No existing layout manager is going to give you what you need, so you either need to write your own or else use null for your layout manager and position your labels directly. Since you know exactly where you want your labels, that should be much easier than struggling with a layout manager.

As for encryption, Truecrypt offers a hidden, undetectable encrypted container in a container. But as I said, if your laptop is suspicious (or you are) your laptop can be confiscated without reasonable cause.

It's even worse than mere unreasonable cause; it's more like malice toward innocent people. Innocent people are the only people who wouldn't take steps to protect themselves. Naturally many innocent people would use caution, but people who are truly carrying illicit information would always take every step to protect themselves, including steganography to make their encrypted files look like ordinary files. Innocent people will sometimes have encrypted files, and since you cannot trust any password offered to truly decrypt the file, the encrypted file will always be suspicious. Then there is the random junk in the unused portion of the disk; there might be an encrypted file in there somewhere, and not even waterboarding will get an innocent person to give up the password for the unused portion of the disk. Only a true espionage agent would make the effort to clean up the unused portion of the disk.

In other words, if a laptop looks suspicious it must be innocent, and if you confiscate it you are persecuting the innocent while letting the guilty pass freely.

That's why I said "at the risk of having your computer confiscated". You can always claim you don't know the password (and there are legitimate reasons why you might not), but customs can then refuse to return your computer.

You can do even better than pretending to not know the password. You can give a password that seems to decrypt your private data without really decrypting your private data. Knowing that, it makes the whole idea of asking people to give up passwords seem futile. Confiscating computers from people is also futile, since anything that is seriously encrypted is completely impossible to decrypt without the password. The most you can hope to accomplish is to deprive the terrorists of the use of one device.

By your reasoning, they shouldn't bother looking for weapons either because a really clever person would find a way to get one on board.

That might be true, but I can't claim credit for reasoning it out. I personally can't think of a 100% guaranteed plan to get a weapon onto a plane without being detected by a search. I mean, you can make encryption 100% secure at virtually no cost, but what could you do theoretically with unlimited resources to get a weapon on board a plane? A completely lifelike false limb? Whatever the technique, it would be very difficult, unlike encryption which is very easy and requires no cleverness.

I think the idea that you can be forced to reveal private data at the risk of having your computer confiscated is a subject worth discussing.

The idea that you can be forced to reveal private data is just a mistake. It's a fact that you cannot be forced to reveal private data. The Allies managed to break the Enigma machine during World War II, but it was a matter of luck and Nazi overconfidence. They made an encryption that was hard to break and assumed that no one would ever put in enough effort to break it. They could have made it a hundred times harder to break or more without a serious increase in cost, but they thought it was unnecessary and the Allied mathematicians found some shortcuts, and so the encryption was broken.

There was nothing inevitable about breaking the Enigma encryption. It was just a Nazi mistake, and we've learned from that mistake and have no need to repeat it. Everyone knows that serious encryption cannot be broken now, including border guards, intelligence agencies, and people looking for child pornography. Even demanding that you reveal your key is useless. I find it hard to believe that they would even try when they know before they start that they'll never find anything anyone seriously wants to hide. It's just a waste of resources.

I see you have the word "Subjects" there. I recommend that you center that word above the "Totals" and "Subject Name" columns, and also add a "Group Letters" heading on the right side. I expect you have tried to do this and encountered some difficulty, but since I don't know anything about that specific difficulty I can't be very specific in my advice.

I suggest that you use javax.swing.JLabel to draw your headings. You can use the javax.swing.table.TableColumnModel to give you the information that you need to put the labels in the right places, and you can write a javax.swing.event.TableColumnModelListener to allow you to update the positions of the labels when the positions of the columns change.

It retrospect it is obvious that you would want to be able to select rows and you would want to keep the rows lined up when scrolling vertically, so I take back my suggestion of using two JTables. That option was too easy. Instead I suggest that you use one JTable which has all of the columns of your lower row of columns: Totals, Subject name, A, B, C, etc. Then you can use getTableHeader to get the component that draws the column headings. You can put the header into a custom JPanel of your own design that will draw your upper level of column headings. Then you can give that custom header to the JScrollPane using setColumnHeaderView.

I haven't actually tested this idea, but it seems likely to work.

javax.swing.JTable is a class with many features and complexities, but I am sure that it can't do what you are asking for directly. I recommend that you use ordinary javax.swing.JLabels for your top column headings and then use two JTables, one for "Subjects" and one for "Group Letters". That won't give you all of the features of real JTable columns, but it should be much simpler than trying to make them full-featured. If you want your top columns to be resizable then you can use a javax.swing.JSplitPane.

At least with physical media you know who has access to it. You can't really know what goes on in the internet. Hotmail might be secretly working against you. Even if they can't decrypt your messages, a collaboration of internet servers could track down everyone who accesses your encrypted files and build a list of suspects.

Because modern encryption is so invincible, it must naturally highlight the weak points in other parts of the system. The only chance for anyone to read on your messages is before they are encrypted and after they are decrypted, which means you need to avoid being spied upon, but you can only do that if you are anonymous, and you can only remain anonymous if (A) no one suspects your messages or any of your allies, or (B) no one can trace the path of messages to and from your allies.

The best way to obfuscate the path of a secret message is to have it travel through multiple media. A radio signal can be traced to its source easily, but only while the signal is being broadcast. A wire can be traced at any time, but it takes time proportional to the length of the wire. If the wire leads to a radio receiver, and by the time the wire is traced the signal has stopped, then the source of the message is impossible to trace any further. So if you want to be very safe, you want to send your encrypted messages …

He was instructed to hide the USB stick somewhere safe, and 'accidentally' drop the hard disk if challenged.

That is so much more pitiful than an intelligence organization trying to force someone to give up a key. At least you can admire the perseverance of intelligence organizations. They know that the deck is stacked against them and they have no real hope of ever discovering important encrypted secrets, but they still struggle against the odds. They ask the terrorists to give up the key because it is the only hope of finding the secrets.

On the other hand we have people smuggling encrypted secrets, the people who have limitless resources and every imaginable advantage. It is mind-blowing that such people would resort to such crude tactics, especially wasting a perfectly good hard disk.

I have been told that when entering the US, customs officials can insist that you reveal the password for an engrypted file or partition.

And if you refuse...

you'd just be detained even longer and probably end up with a terrorism charge just to get you to cooperate.

That's an amazing exercise in futility. I would be very surprised if modern governments and especially intelligence organizations would be so unaware of obvious techniques for keeping secrets. I mean, if you really want to keep encrypted data safe then it can be safe to a degree second only to your own private thoughts.

If you are in a position to demand that someone give you the key to some encrypted data then you should either expect that the data is unimportant or else you are being given a key that will cause the decryption to only reveal an unimportant part of the encrypted data that was put there just for you to find in this situation.

Never underestimate the power of computer forensic tools.

Modern encryption can laugh at the power of computer forensic tools. Every bit you add to the length of your key doubles the time it would take to break your encryption. If you want to encrypt something that can't be decrypted by force within your lifetime, then you can have that. If you want to be sure the sun has died before your encryption can be broken, that's just a few …

The details are available here: http://docs.oracle.com/javase/7/docs/api/java/util/Formatter.html

Format specifiers look like this: %[argument_index$][flags][width][.precision]conversion

The number 6 is in the [width] position, which means that 6 is the minimum number of characters in the result. If the argument string has 6 characters or more, the argument string will be output as it is, no matter how long. If the argument string is less than 6 long, then spaces will be inserted on the left side to make the output 6 characters long. You can include - in the [flags] position if you want the spaces to be on the right side.

You can use java.util.Arrays.equals to check if the contents of two arrays are equal.

Like many methods, Object.equals is a little fuzzy in exactly what it does. The meaning of equals isn't exactly the same for each class. There are rules that all classes are supposed to follow, but they are quite loose.

Like most operators, == does exactly one very specific thing, so you always know precisely what you are getting when you use it. Clearly it is not always the same as Object.equals. For example, java.util.Collection.equals tests that two collections contain the same elements by testing each element by equals, while the == operator would tell you if two references pointed to the same collection object, which is a big distinction when you call methods that modify collections like add.

On line 31 you are creating a new array for the reference n. On line 32, you are testing if n is contained in closedSet. Since the n array never existed before that moment, there is no way it could be in closedSet. That will surely prevent your algorithm from performing as intended.

javax.swing.JTextField is usually an excellent way to allow the user to type small amounts of text, but it can't work on its own. It needs to be a component of something that is visible on the screen such as a JFrame or a JPanel inside a JFrame. You need to stop trying to add it to an object that has no add method and decide where you really want your JTextField to live.

You have forgotten to include the details of the error. Remember that error messages are not mere annoyances; they are someone's sincere attempt to help you, so you should read them, take them seriously, and share them with anyone else who wants to help you. So if your error includes a message, please share it.

It is hard to guess the cause of the problem based on only the small portion of the code you have included here. It is impossible to reproduce your problem, but you should be aware that it is very strange to add components in the paint method. Normally you setup all the components that you need once and they stay there until you have a reason to change them. Adding the same component repeatedly strongly suggests you are suffering from some misunderstanding.

The add documentation for AbstractCollection is actually rather shameful. When a class is designed to be extended the documentation should go far beyond merely explaining what each method does. A few preconditions and postconditions are fine documentation for a final method, but someone who is overriding a method also needs to know when and why that method will be called.

For example, the documentation for the paint method of java.awt.Component explains that it is called every time the component should be painted, which is critical information for creating custom AWT components. Providing that in the documentation is the sort of thoughtfulness that might allow someone to learn to use AWT without relying on tutorials.

Similarly, the problem with InstrumentedHashSet is caused by a failure of documentation of add which should explain to anyone overriding add that it would be called for each element of any collection given to addAll. The addAll documentation might also mention that, but it isn't as critical since InstrumentedHashSet wouldn't have a problem if it only overrode addAll and only expected addAlls to be counted; those sorts of implementation details are only important to someone who is overriding add, so that's the documentation where it should be explained.

That sort of carelessness means that it is often wise to browse the source code for any class you intend to extend. It seems that you can never depend on documentation to give you all the important information, and java.util is an example of unusually complete documentation, unfortunately.

Actually, there is no problem with having only one return statement in the if part and one in the else part. The compiler is surely smart enough to recognize that one return or the other is inevitable. The problem comes from the fact that it is possible for myarray to have zero-length, and also for every element of myarray to be a zero-length array, meaning the loops get skipped without running even once.

Even if that can never happen, the compiler wouldn't even try to detect that because you would be better off making a decision about what the method should do in that case. The compiler is suggesting a return value, but you could also throw an exception

If you think that it is impossible for the method to run without encountering either of the return statements then you should throw an Error at the end of the method, because Errors are what get thrown when the most serious of unrecoverable problems happen, and things which aren't possible are also usually impossible to recover from.

It tries to parse the command/arguments itself and often gets it wrong.

It simply uses whitespace to separate the command from the arguments and the arguments from each other. There's nothing wrong with that since it's such a clear and simple rule so that anyone who has read the documentation will understand it. The real problem with exec is that all the rest of it is not properly documented, so we understand how it parses commands and arguments better than anything else that it does.

The exec method does not necessarily use your command the same way that your command prompt uses it. Practically everything that exec does is operating system dependent, so it's hard to make any promises about how it should be used, but you shouldn't assume that it is as sophisticated as your command prompt.

There is at least a vague concept of a command and the command's arguments that you seem to be ignoring, which might be the cause of your problem. You are giving exec the command and its arguments run together all in one word instead of putting spaces between dtexec and /f and the file name. Apparently your command prompt has no problem with that, but to the exec method that means the whole thing gets treated as a command with no arguments even though it looks like dtexec should be the command and /f and the file should be the arguments.

Even if you do separate the arguments there are no guarantees because this entire problem is operating system dependent. You might also want to try removing the quotes from around the filename because your command prompt might be removing the quotes before passing the file name to dtexec, and the exec method probably won't do that. On the other hand if the command prompt isn't removing the quotes and dtexec requires the quotes, then you need to have the quotes.

With luck, a little trial-and-error should quickly solve the problem.

You should check the documentation for the JdbcRowSetImpl constructor that you are calling. It is never safe to call any method or constructor without reading the documentation, so it is general good advice to always check the documentation. In this case a quick search found documentation for a com.sun.rowset.JdbcRowSetImpl that would throw a SQLException if you used the no-arguments constructor and then tried to use the JdbcRowSetImpl without first calling execute. I'm not sure that the documentation I found is for the version of the class that you are using, but it would explain your problem.

Your findAllEndings method is puzzling. Your isFound variable is never used. Your tries variable is used only on line 16 where its value is always 0, meaning that you are ignoring all but the first element of endswith. You increment tries on line 19 even though it is never used again. You assign w a value on line 26 even though it is never used again.

What is the purpose of your recursive call to findAllEndings if the return value is thrown away?

how do I covert a String "0101" to an int 5?

The conventional way is Integer.parseInt("0101", 2).

If you want to learn how to do it yourself, then just go from left-to-right with a accumulator that starts at 0. For each digit you multiply the accumulator by 2 and then add the current digit.

String.getBytes is useless for this purpose. It will merely create an encoded byte[] for your string so you won't be able to access its characters correctly unless you know the code and can decode it.

If you don't want "null" in your string then why do you initialize bin to null?

The performance of StringBuilder is sufficient for most common purposes. Arrays work quite well when you are mostly appending small strings to the end of a string, and that is a very natural way for strings to be constructed in most applications.

If you want to deal with long strings that support more general editing operations quickly, then you will probably be interested in ropes. You might also want to look a gap buffer which is a more specialized data structure.

You can go row-by-row down the rows, starting with all false, then for each row after that you go from right-to-left along the row filling the entries based on the previous row's entries. Until you find a false in the previous row, make each entry false, then where there is a false in the previous row make the entry true, and every entry after that is a copy of the previous row's entry.