This week's giveaway is in the Beginning Java forum.
We're giving away four copies of Bad Programming Practices 101 (e-book) and have Karl Beecher on-line!
See this thread for details.
Win a copy of Bad Programming Practices 101 (e-book) this week in the Beginning Java forum!

Michael Angstadt

Ranch Hand
+ Follow
since Jun 17, 2009
Michael likes ...
Eclipse IDE Java PHP
6 years professional Java experience

Sun Certified Java Programmer

Sun Certified Web Component Developer

Wikipedia narrator
Philadelphia, PA
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 Michael Angstadt

Hi Mr. Rothwell,

Does the book cover how to develop a specific type of application, or is it broader in scope?  For example, does it focus on Linux kernel development, client-side GUI development, CLI programs, a mix of everything?  The table of contents seems to suggest that it doesn't focus on a specific type of application development.

Thank you!!
1 year ago
Hi Rick,

Is there anything SVN does better than Git? ;)

Thanks for writing the book!

Thank you,
Thanks for your responses.

Wow, I didn't know that so much of the JDK code base has duplicate code! Was that OpenJDK or some other implementation?

I agree with S G Ganesh about identical class names. In theory, you should keep your class names as short and concise as possible. After all, their package names will differentiate them from other classes in other packages that have the same name. But in practice, it can be annoying if you are using two identically named classes from different packages inside of the same class. Then, you're forced to identify at least one of the classes using its fully-qualified name, which is super annoying.

What is the most common design smell that you've seen in Java? What is the mistake that people make the most, in your experience?

Thank you.
What's the most common Java security vulnerability you've seen which could be corrected with better programming practices?
3 years ago
Hi Rogers,

During the time you've spent researching and writing your book, have any ideas on how Java can be improved upon jumped out at you? Like any language or API improvements/additions? Also, do you think Scala will replace Java as the JVM's main language in the future, as some people are predicting?

4 years ago
Padmarag thanks, that answered my question.
6 years ago
With JAX-RS, you have to download a separate library in order to use it. Sun's implementation is called Jersey and it does NOT come packaged with the JDK. Does the same apply to JAX-WS? Do you have to download a separate library to create a SOAP web service? Thanks.
6 years ago
This is sort of a stupid question, but is JAX-WS an actual implementation or is it just an API that vendors can create implementations for? I ask this because I know that JAX-RS (Java's API for RESTful web services) is just an API...the JDK doesn't ship with an actual implementation of JAX-RS. Thanks.
6 years ago
I thought I would share my thoughts, since I was having the same problem (even though this thread is very old).

I did what Ramamoorthy Govindaraj suggested (except my input/output streams used files instead of Strings because my XML document was very large and storing the entire document in memory would have been inefficient):

But that still didn't work. When I opened the file in a text editor (Notepad++), I saw a question mark character at the very beginning of the file. After I deleted that character, I could parse the file successfully.

Working with encodings is annoying because text files are supposed to be simple.
Yes, just like servlets, a single instance of the service implementation bean is used to handle all requests. So it just boils down to whether or not your DAO is thread safe. If it is thread-safe, then storing the DAO in a class-level variable would be fine. But if it is not thread-safe, then you could still use a class-level variable, but you would have to make sure to synchronize on it so that only one thread can access the DAO at a time. You could also just create a new instance of the DAO in each of the web methods.
7 years ago
Does the web service use RPC style? If so, using Document style instead might help. Document style web services add an XML schema to the WSDL, which specifically defines how the SOAP body should look. So if the request's SOAP body contains a string where there should be an integer, I think that this might cause an error to be thrown.
7 years ago

Bear Bibeault wrote:

Michael Angstadt wrote:[For example, when you add an entry to a HashMap, it has to do things like create a hash of the key, put the value in the proper bucket, etc.

Do you really think any of that is more than noise? Really? Do you think that the infinitesimal time that might (might) be saved is worth creating crappy unreadable code?

No, it's just annoying is all.
7 years ago

Bear Bibeault wrote:Rather than an arrays (using unreadable indexes [0] and [1]), I'd use a Map.

Yes, I think that using a Map<String, String> instead of a List<String[]> would definitely make the code much more readable and maintainable. But doesn't a Map add unnecessary overhead in this particular situation? For example, when you add an entry to a HashMap, it has to do things like create a hash of the key, put the value in the proper bucket, etc. In the situation above, we don't need any of that. All we need is a way to store is a list of String pairs that we can iterate through. We never have to retrieve individual values by calling Map.get(), making all the hashing that HashMap does a waste.
7 years ago

Paul Clapham wrote:I don't consider showing request parameters in the URL to be a problem, but Farakh does.

I can think of one reason why using GET can be a security risk: A login form that uses GET would put the username and password in the URL. Even if the connection is secure (https), this makes the password visible to anyone who is standing over the user's shoulder (does https encrypt the URL too? If not, then the information is visible to packet sniffers too). Also, because the browser's history saves every URL the user visits, the user's login information will be saved there, allowing anyone who has access to that computer to get this information.
7 years ago