D. Ogranos

You really want to clean up that code (especially that looooong line). Oh and use code tags here, they make reading code a lot easier.

Also, what is JSONObject? One of your own classes, or a part of some framework? Apparently that class is supposed to create the JSON, but without knowing more how it works, its impossible to tell why it creates the output you see.

Thanks for the answer. I'm not trying to avoid dependencies like the plague, but here I was hoping for a more accessible solution ;)

Hmm, any good reason why not? I understand that things might change between versions, but its not like you change server versions every other day in a production system.

The only reason I was looking at this class was because I thought it was available in the context of a basic Java 7 / Tomcat 7 installation, without having to add any more .jar dependencies.

I've been looking at alternatives for the sun.misc.BASE64Encoder/Decoder (Java 7 / Tomcat 7). Specifically, built-in classes (so no external libs are required). I found the class javax.xml.bind.DatatypeConverter which offers Base64 encoding/decoding methods.

But I also remembered having seen a Base64 class in the tomcat API, and on searching indeed found it: org.apache.tomcat.util.codec.binary.Base64 (see http://tomcat.apache.org/tomcat-7.0-doc/api/).

However, where is this class? I mean, which jar contains it? I looked into tomcat-api.jar, tomcat-util.jar, tomcat-coyote.jar and several more, but could not find it. catalina.jar contains another Base64 class (org.apache.catalina.util.Base64), which is something else. Maybe I'm blind but I don't see it anywhere.

Does anyone know where the class is hidden?

First obvious question: Are you sure this .jsp is executed when you submit your login form (you have a System.out.println to print the password, does it appear in the server log)? If the .jsp is indeed executed, then go on step by step, add some more System.out.println to see how the code flows (one for success case, one for failed login case). If the code is called correctly, then your frame page parts may not be accessible, so check that out.

That said, you have a SERIOUS mess here. JSPs should not contain Java code (especially not database operations), it should be in its own Java class (probably a servlet controller). Then you introduce security problems by making a direct query to the database (look up PreparedStatement).

Honestly, I would completely scrap this and rewrite it cleanly, using a servlet controller for the login process, and JSPs only for the view.

I don't know so much about professional, but there are a few guidelines to follow to produce "good" code:
- don't go for "clever" code, instead go for easily readable, understandable code (-> maintainable!)
- refactor often: if a method/class grows in length, see if you can extract parts as methods, or if you can split classes
- follow the "one method/class, one purpose": a method/class should do one thing, not try to do everything

Google for "clean code" as one starting point for more ideas.

Also google for PMD and Checkstyle, these are tools for static code analysis. They can help you to evaluate and improve your code.

In my test project, I have two resource bundles: messages.properties (german) and messages_en.properties. The german version is intended to be the default.

I can access them in my controller like this:
ResourceBundle bundle = ResourceBundle.getBundle("messages"); System.out.println(bundle.getString("test"));

Both when called from IE and from Firefox, this results in the same message (german). The request Locale is the same ("de_DE" when printed as request.getLocale().toString()), but I suppose that doesn't matter here since getBundle(name) uses the default (server) locale, right?

Then, in my JSP then I use the following:
<fmt:bundle basename="messages"> ... <fmt:message key="test"/> ... </fmt:bundle>

When called from IE, this displays the german message, but when called from Firefox, this displays the english message. The request locale is the same for both browsers ("de_DE"). Why does the <fmt:bundle> tag get the wrong message bundle?

If I explicitely set the locale in the JSP with
<fmt:setLocale value="${pageContext.request.locale}"/>

then I get the correct message in Firefox too, but I don't understand why I need to do this (and if its the correct thing to do). I would have thought that the <fmt:bundle> tag uses something like getResourceBundle(name, locale) with the request locale, but apparently that's not what happens..

Another pretty common pitfall is mixing up primitive types and their respective wrapper classes, for example int vs. Integer, Java 1.5+ makes it easy to forget about the difference with autoboxing

Another solution (suggested by Joshua Block in the book "Effective Java"):
public enum SingletonExample { INSTANCE; // methods go here }

When writing text files, better use a Writer (FileWriter) instead of FileOutputStream. And write each element of the list in a for loop, then you can simply add a newline in each iteration.

Jayakrishnan.C Chandramohan wrote:Hi all,


can i declare a class as a private???
like
private class A
{
public static void main(Strings[] g)
{
System.out.println("jk");
}
}

You cannot declare top level classes as private . Inner classes however can be private.

Why do you want to make your class private? If you want the class to be only visible within a package, then you can use package visibility: Just declare the class without an access modifier.

I realize this is an old thread, but when searching I found a similar question which also had not been answered, and since I just learned about this I thought I might reply so people can find an answer when they search for this

JAVA_TOOL_OPTIONS is an environment variable you can set to pass arguments to the Java Virtual Machine (and apparently also javac). If the variable is set, its content is printed out as mentioned by the OP. So this is no error, just debugging info. It can be used for command line options (like -enableassertions) and also to set system properties (like -Dmyvar=myvalue), which you can then query through System.getProperty().

Its use is for when you have no command line available when starting the JVM, or also starting from scripts.

From a quick test, this works for Java 1.5 and up.

Link to Oracle Doku: Environment Variables.

Vikki Fiawoo wrote:Could you please elaborate a little further on the this part of the code?

//Returns the string representation of a cbuf?? String readData = String.valueOf(cbuf, 0, numRead);

This is a BAD thing to do. You create a new String with the read chars here, and thats totally unneccessary. As others said above, go and check the API for the classes you use. In this case, StringBuffer: You will see that there is an append() method which allows you to directly append data from a char[] to the buffer.

Winston Gutkowski wrote:

D. Ogranos wrote:Third: be precise in the naming of your variables. The accept() method receives a File as parameter, so why do you call that parameter "pathname"?

Actually, that's what it's called in the FileFilter class - I suspect to indicate the fact that its primary use is for filtering pathnames.

Hmm, you're right...ok in this case, sorry vinayGuddu Pandey, I should've looked at that API first

First: please use code tags, it makes reading your code example a lot easier.

Second: your accept() method returns true if the file it is checking is a directory, so why do you expect it would do anything else? If you want to check if you have a file with the extension ".txt", then have the accept() method check for that (hint: look at the String method endsWith() )

Third: be precise in the naming of your variables. The accept() method receives a File as parameter, so why do you call that parameter "pathname"? To another reader looking at your code, a variable named "pathname" might suggest that a string is passed here.