Gaurav Sagar wrote:
Ziyang Zhang wrote:
Tom Reilly wrote:I assume you are referring to the Windows OS. User Parameter is used for the current user only. System Parameter is used for all users, which means it works for those applications that are run as system services. I always use System Parameter and never have to worry about the things you are worrying about.
Thanks a lot!!! Do you have any idea why java -version works all the time no matter if I install jdk or not?
java -version works because that is an executable always present in the jre (Java Run time Environment) which is shipped to you when you buy your windows OS. When you install the JDK then JRE is also installed(if you don't have a JRE or your JRE previously installed is of an older version).
So, to check the proper installation of your JDK i.e. after you have set the path, then simply enter the javac -version onto your command prompt. This would tell you the version of javac installed onto your system. It's far better to use then getting confused by the java -version(Highly Recommended).
Tom Reilly wrote:I assume you are referring to the Windows OS. User Parameter is used for the current user only. System Parameter is used for all users, which means it works for those applications that are run as system services. I always use System Parameter and never have to worry about the things you are worrying about.
marc weber wrote:
Ziyang Zhang wrote:...I found if I set JAVA_HOME as “User Parameter” and set path as “System Parameter” (I use JAVA_HOME when setting path). This will not work, which means % JAVA_HOME % in path could not be interpreted. WHY? If I set both JAVA_HOME and path as “System Parameter”, it works...
As Tom pointed out, a system parameter is always available, regardless of what user account is logged in. In contrast, a user parameter is only available if that particular account is being used.
With that in mind, if PATH is updated as a sytem parameter (available to all accounts) but it includes JAVA_HOME, which is defined as a user parameter (only available to one account)... Do you see the problem?
Tim Holloway wrote:Well, first of all, there are a lot of reasons why writing your own login system is a bad idea no matter how many times people use login pages for sample code in J2EE books.
However, the reason for your confusion is that the "*.xhtml"s are resource filenames and the "*.jsf"s are URL references. Navigation rules are URL-based, not resource-based, so you have to use the URL, not the resource that the URL pulls in.
Finally, the "jsessionid" is generated by the web application server. It's used to bind a server session to a web user when it's uncertain that a cookie can carry the session ID. Without a session ID, you can't have a continuous web conversation, since unlike client/server, there's no long-term connection in place between page requests.
You should ignore the jsessionid. It will be removed by the J2EE URL parsers and it will be added by the container if needed, but there's nothing there that applications can or should be messing around with.
Jesper Young wrote:There are some important things to note with the solutions given above:
Garrett's solution, with Arrays.asList() is efficient because it doesn't need to copy the content of the array. This method returns a List that is a "view" onto the array - a wrapper that makes the array look like a list. When you change an element in the list, the element in the original array is also changed. Note that the list is fixed size - if you try to add elements to the list, you'll get an exception.
Ernest's solution: new ArrayList(Arrays.asList(myArray)); copies the content of the array to a new ArrayList. The copy is ofcourse independent of the array, and you can add, remove etc. elements as you like.
Janarthan's solution, with Collections.addAll(myList, myStringArray); is essentially the same as Ernest's solution.
If you only need read access to the array as if it is a List and you don't want to add or remove elements from the list, then use Garrett's solution. Otherwise use Ernest's or Janarthan's solution.
Janarthan S Sathiamurthy wrote:import java.util.Collections;
List myList = new ArrayList();
String[] myStringArray = new String[] {"Java", "is", "Cool"};
Collections.addAll(myList, myStringArray);
After this code, 'myList' should contain all the elements from the array.
Best regards,
Janarthan S