Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 233649

Summary:	[compiler] batch compiler ringing the bell
Product:	[Eclipse Project] JDT	Reporter:	Philipe Mulet <philippe_mulet>
Component:	Core	Assignee:	JDT-Core-Inbox <jdt-core-inbox>
Status:	CLOSED WONTFIX	QA Contact:
Severity:	normal
Priority:	P3
Version:	3.4
Target Milestone:	---
Hardware:	PC
OS:	Windows XP
Whiteboard:	stalebug

Description Philipe Mulet

2008-05-23 08:03:09 EDT

3.4RC1

1. Take rt.jar from 1.6 jre/lib
2. Rename it into rt.java
3. Try to compile it with ECJ (command line)

It will soon detect over 100 syntax errors, but when trying to write error text to the console, it will issue BELL characters which drive the machine crazy.

Maybe we could filter the error text to prevent such painful experience (like replace some offending chars with the square char).

Comment 1 Maxime Daniel

2008-05-23 09:13:47 EDT

ecj does not issue BELL characters, it passes through whatever character it finds in the file given in input at places that are seen as containing errors. Some of these characters are 'nicely' transformed into a beep or a strange glyph, others may send commands to the hosting shell (resulting, for example, into the shell changing its page code or even other parts of its protocol). In other words, passing random characters to the shell has side effects, including the machine beeping desperately. Note though that listing a binary file into a shell is due to cause similar grief, which means that we do not misbehave, but run into a limitation of shells (limitation that has workarounds, starting with redirecting the stderr to a file when dubious contents are expected, or using appropriate filters on decently gifted OSes).

I would hence suggest that this be considered as an enhancement rather than a bug.

Furthermore, I see some need for further investigations before deciding a design. As a point of concern, ecj will want to report errors involving strings literals that contain non ASCII chars. Projecting all non-ASCII chars to an innocuous glyph is thus not an option for I18N reasons, we would have to be more clever than that. It may also appear that characters that are innocuous for a specific combination of OS and locale, and should be preserved for accuracy reasons, are detrimental to others; if this happened to be true, we'd have to inject some I18N sensitivity in the picture, or else go for a specific option?

Comment 2 Philipe Mulet

2008-05-23 10:01:23 EDT

These are valid concerns. Can you please try other compilers to see if we really need to be worried or not ?

Comment 3 Philipe Mulet

2008-05-23 10:02:06 EDT

(and of course, the compiler doesn't beep itself, just side effect of echoing error text to console - I thought that was implicit <g>).

Comment 4 Eclipse Genie

2020-03-02 08:41:24 EST

This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. As such, we're closing this bug.

If you have further information on the current state of the bug, please add it and reopen this bug. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.

--
The automated Eclipse Genie.