Bug 25848 - RedHat Linux LANG=en_US.UTF-8 causes some files *NOT* to be compiled
Summary: RedHat Linux LANG=en_US.UTF-8 causes some files *NOT* to be compiled
Status: CLOSED WORKSFORME
Alias: None
Product: JDT
Classification: Eclipse Project
Component: Core (show other bugs)
Version: 1.0   Edit
Hardware: PC Linux
: P3 critical (vote)
Target Milestone: 2.1 RC2   Edit
Assignee: Olivier Thomann CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2002-11-07 14:41 EST by Barry Searle CLA
Modified: 2006-11-06 11:28 EST (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Barry Searle CLA 2002-11-07 14:41:59 EST
Barry,

I tried to come up with a generic workspace that would reproduce the error,
but couldn't.  I guess that whatever is going on must be a real ride through
all the code.  If it comes down to a fix test then I can either run
something for IBM or it would be possible to get code out.  As GE we do have
a non-disclosure in place (or ready) with IBM around the project.


Let me outline what I found:

Platform:  Using WSAD 4.0.3 on Linux (RedHat 8.0)

Symptom: Some .java files not compiling in a directory.  Most of the files
compile, but two in particular are listed as being compiled, but not ever
actually compiled.  The build outcome is that the 1 file which references
these reports that the classes cannot be found.

Other oddities: When launched from a cron job it worked, but when built from
WSAD or using the same script as a logged in user, it fails to create the
two classes.

Workaround Found:  It appears that if I call "unset LANG" from the script
building this that the build functions properly.  It is very reproducable
that with LANG set it fails, with LANG unset it works.

It appears to work in RedHat 7.3 (which is my desktop) but causes this
problem on RedHat 8.0.  I believe it may somehow be related to the LANG
value.

On RedHat 7.3 - default LANG=en_US.iso885915
On RedHat 8.0 - default LANG=en_US.UTF-8

What really trips me up is that it only affects certain files.  I don't know
what's unique about these files (there's nothing we've specifically done to
make them language dependant).


Let me know if there's anything else you need info about.  In the mean time
it appears that things are working well for me again.

Thanks,
-- Wes
"Wright, Wesley (CAP, GEFA)" <Wesley.Wright@gecapital.com>
Comment 1 Philipe Mulet CLA 2002-11-08 09:29:29 EST
Sounds like a file encoding issue.
Does this also occur in WSAD 5.0 (based on Eclipse 2.0) ?
Comment 2 Philipe Mulet CLA 2002-12-09 16:52:54 EST
Is it ok to close?
Comment 3 Philipe Mulet CLA 2003-01-08 06:45:07 EST
Olivier, could you please try simple things in our latest to see if it works 
ok ?
Comment 4 Olivier Thomann CLA 2003-01-08 08:23:15 EST
Philippe, I don't have access to a Linux box. Do you have one in SNZ?
Comment 5 Olivier Thomann CLA 2003-01-08 08:46:17 EST
I would be great if you could try with WSAD 5.0 on your specific test cases. It
is fairly difficult to reproduce your problem especially if only two files don't
compile and they have nothing special.
Let us know if you can provide us steps to reproduce.
Thanks.
Comment 6 Wesley Wright CLA 2003-01-15 13:12:06 EST
I have tracked down some additional information.  As mentioned before, by
default RH 8.0 has LANG=en_US.UTF-8.  According to O'reilly's JAVA in a
Nutshell, 3rd edition p.234 under native2ascii, "javac can only process files
encoded in the eight-bit Latin-1 encoding, with any other characters encoded
using the \uxxx Unicode notation."

native2ascii fails on the files which were not compiling.  It appears that the
comments in this file contain some special characters.  When I switch the
language, it appears that WSAD is able to do some conversion which allows the
files to compile.
Comment 7 Olivier Thomann CLA 2003-01-15 13:17:06 EST
What could we do to fix the problem? Is it still a problem?
Can you provide these two files as a test case?

Thanks for your help.
Comment 8 Wesley Wright CLA 2003-01-15 14:08:54 EST
> What could we do to fix the problem? Is it still a problem?

It's still a problem.  Currently it's possible to change the file remove any
questionable characters.  It also seems possible to change the default LANG and
this may be helping convert the file somehow.


> Can you provide these two files as a test case?

Unfortunately they contain code I'm not allowed to send out the door.

See bug 29554 and you will see two of the special characters which sometimes
cause problems.  One of the files in question has the text "Gov<92>t Allotment"
in it which may be part of the problem; however it is difficult to reproduce
using that test file outside the full environment.
Comment 9 Olivier Thomann CLA 2003-01-22 10:53:31 EST
You seem to have a issue with character encoding. This support has been improved
in 2.1 stream since 1.0. Can you reproduce your problem with latest integration
build or 2.1M4 with the proper encoding set in Eclipse.
See bug 29863 to find out how to set a different encoding.
Comment 10 Philipe Mulet CLA 2003-01-29 11:55:55 EST
Any update ? 
Comment 11 Wesley Wright CLA 2003-01-29 13:05:01 EST
I just recently got WSAD 5.0 and an in the process of rebuilding our workspace
to work with the new release.  If I can reproduce in this environment, I will
update the bug.
Comment 12 Olivier Thomann CLA 2003-02-04 15:43:38 EST
Any result with WSAD 5.0?
Comment 13 Wesley Wright CLA 2003-02-04 16:11:52 EST
I've had limited time to work on this... so far I haven't had any trouble.  I
will update within the next week if I receive any problems.
Comment 14 Philipe Mulet CLA 2003-02-13 08:55:23 EST
Removing RC1 milestone.
Comment 15 Olivier Thomann CLA 2003-02-17 17:39:50 EST
Any news on this front with WSAD 5.0? If not, we might want to close this on as
WORKSFORME.
Comment 16 Philipe Mulet CLA 2003-02-24 08:52:20 EST
Closing, please reopen if this is still an issue with a 5.0 build.
Comment 17 Barry Searle CLA 2006-11-06 11:28:12 EST
seems to have been resolved