Ganni Kal

The same program is reading the characters properly, when I execute it in a different Linux server but with same Locale (LANG=C) settings.
But here the file encoding type was UTF-8 Unicode English text, with very long lines, with CRLF line terminators

While comparing the two server (Red Hat Enterprise Linux AS release 4) settings, the patch update version is different from each other.
One of the server has the patch version as Nahant Update 5 and the other has Nahant Update 7.

Will this difference cause this problem?

JTextArea is a suitable component for your requirement.

Refer the following link to know more about this.

http://java.sun.com/docs/books/tutorial/uiswing/components/textarea.html


-Ganni

Hi

I tried to read the same file by using the charset name ISO-8859-1 as an argument inside InputStreamReader constructor.
Now the non-printable characters are read and printed as they are.

LineNumberReader lnr = new LineNumberReader(new InputStreamReader(in, Class.forName("ISO-8859-1")));

I understand that the input file was with the ISO-8859 charset encoding, but the Java is trying to read the file using its default encoding format ANSI.
I use the Wepsphere's JVM for compiling and running the program.

Will Websphere affect the JVM's default encoding format?
How to change the JVM's default file encoding format?


Regards
Ganni

Rob Prime wrote:

Ganni Kal wrote:(observe that the character Ï is not read properly.)

Are you sure? Are you sure it's simply not printed properly?

Most terminals, including Windows' CMD.EXE, simply cannot handle anything outside plain old ASCII. Try using JOptionPane.showMessage to show the message (if you have an Xorg session running that is).

Actually I use Swing based UI. The actual application code is storing the characters into database, and that data is read from DB, and displayed in a JTextField.
For debugging purpose only, I tried printing the characters in console.

The characters are not read properly both in console and Swing.


Thanks
Ganni

I executed the following code to list all the charsets supported by the JVM in both the RH servers.
There is no difference in the output.

Map charSetMap = Charset.availableCharsets();
Iterator itr1 = charSetMap.keySet().iterator();
while (itr1.hasNext()) {
Object key = itr1.next();
System.out.println(key + " - " + charSetMap.get(key));
}




Regards
Ganni

Thanks for your suggestion.

I do not want to specify the encoding name inside the InputStreamReader constructor because, characters like Ï are exceptional case. Even I do not know how it was entered into the file (I have not created the file). Also I can not handle all other characters like this that comes from different encoding format.

I just want the read operation to be happened by the default encoding that was set in the OS or JVM.
This is working good in a different Linux server (with the same java code). Mainly I want to understand how the file with same characters are read properly in one Linux server but not in other, where both servers are having the same locale settings.

I know this may be a question related to Linux OS/JVM. But nowhere I can find the answer including the LinuxQuestions forum.

Any more ideas?

Thanks
Ganni

Hi

I have a file that contains the text TEST NAÏVE SUBJECT I wrote a java program to read this file in RedHat Linux.
The java code that reads the file is similar to the below

File inputFile = new File(fileName.toString());
FileInputStream in = new FileInputStream(inputFile);
LineNumberReader lnr = new LineNumberReader(new InputStreamReader(in));
String streamInput = null;
while ((streamInput = lnr.readLine()) != null) {
System.out.println(streamInput);
}

The out put of the program is

TEST NA?VE SUBJECT
(observe that the character Ï is not read properly.)

I can able to guess that the java program is reading the input file in a different encoding than the file was actually encoded. If so what is the solution to overcome this problem?

Here I list the details that I observed on the Linux server:

The env variable LANG=C
While executing file command for that input file, it displays

ISO-8859 text, with CRLF line terminators


The same program is reading the characters properly, when I execute it in a different Linux server but with same Locale (LANG=C) settings.
But here the file encoding type was UTF-8 Unicode English text, with very long lines, with CRLF line terminators

Thank you!

Regards
Ganni

Hi

I have two Linux servers (Red Hat) both are having the LANG=C.
But reading of characters that is not supported by UTF-8, are handled differently by the servers.

What are the environment variables other than LANG, that affects the encoding format in Linux?

Thanks for looking into this.

Ganni

Hi

This question is about Apache HttpCleint.
Is there any way to set a custom value to the no.of retries to be made by the HTTPClient if of any transport exception occurs?

Thanks

Ganesan

Hi

Assume that the a comma separated text file (namely user.txt) contains data as below:

""AB"",CD","1407"


I converted the text file into a csv file (just by changing the file extension to .csv named as user.csv). and while opening the csv file through MS Excel application the data
is displayed in three columns as below:

col1 col2 col3
----- ------ -------
AB"" CD" 1407


Is there any java API / or program, to parse the text file (user.txt) and extract the data as same as excel?


Thanks
Ganni

Sun recommands not to reuse the GridBagConstraints object as this can very easily lead to introduce subtle bugs if we forget to reset the fields for each new instance.

To overcome the problem of missing to reset any of the fields of GridBagConstraints, I have written a method as below

private GridBagConstraints gbc =null;

private GridBagConstraints getGBC(int gridx, int gridy, int gridwidth,
int gridheight, double weightx, double weighty, int anchor,
int fill, Insets insets, int ipadx, int ipady) {
if (gbc == null) {
gbc = new GridBagConstraints(gridx, gridy, gridwidth, gridheight,
weightx, weighty, anchor, fill, insets, ipadx, ipady);
} else {
gbc.gridx = gridx;
gbc.gridy = gridy;
gbc.gridwidth = gridwidth;
gbc.gridheight = gridheight;
gbc.weightx = weightx;
gbc.weighty = weighty;
gbc.anchor = anchor;
gbc.fill = fill;
gbc.insets = insets;
gbc.ipadx = ipadx;
gbc.ipady = ipady;
}
return gbc;
}

Whether this code is good for reuse the GridBagConstraints objects and to overcome the problem of missing to reset any of the fields.
I plan to use this code as part of Framework API in my project.
Please provide me the drawback of the above code if any.

Regards
Ganni

Thank you for your timely reply !

Regards
Ganesan

Hi

There is a big difference in the size memory allocated by the following two statements

Statement 1:

Object[] obj1 = new Object[0]; // takes memory, say 250 bytes

Statement 2:

Object[] obj2 = new Object[100000]; // takes memory around 10000 bytes

My question is, even though the memory will be allocated only after we create the objects and add to the array, why the second statements is occupying around 10000 bytes in memory?

Your help will be appreciated!!!

Thanks
Ganni

Hi

I want to show a JTable with the following behavior,

The JTable's Column Headers should be focusable.
When the "TAB" key is pressed the focus should go to the first Table column header.
When continue to press the "TAB" key, the focus should go to the next column headers.

Does anybody have an idea of how to implement this?

Thank you.

Dear Jaikiran

Thank you for your neat and useful answer.

Ragards
Ganni