Home » Language IDEs » Java Development Tools (JDT) » e3.5 & e4 - Is it about time Eclipse compiler fixed bugs that Sun hasn't?
| e3.5 & e4 - Is it about time Eclipse compiler fixed bugs that Sun hasn't? [message #252618] |
Thu, 10 April 2008 18:20  |
Eclipse User |
|
|
|
In bugs https://bugs.eclipse.org/bugs/show_bug.cgi?id=158870 and
https://bugs.eclipse.org/bugs/show_bug.cgi?id=99107, we have closed,
*not fixed*, compiler bugs that correspond to bugs that Sun has had "In
progress" since 2005.
These, in particular relate to bugs where an error is given on a generic
cast, but the assignment can be valid, and should therefore get an
"unchecked conversion" warning, as the types are not "provably distinct"
as, it seems is the wording of the JLS (see bottom of
http://bugs.sun.com/view_bug.do?bug_id=6557279).
an example is:
Iterator<Enum<?>> it = null;
Iterator<Enum> error = (Iterator<Enum>)it;
which gives an error, while the following, which has the same erased
types doe work, with the appropriate warning:
Iterator<Enum<?>> it = null;
Iterator<Enum> error = (Iterator)it;
As a user of Eclipse, I want to benefit from generics, and be able to
work with legacy classes.
Therefore, the question I've got for those who'll discuss it, is:
Should Eclipse continue to re-implement Sun's bugs, or should there be a
distinct policy change for e4 or even for e3.5?
When all is said and done, these bugs can be just another checkbox in
the "Errors/Warnings" preference page, defaulting to "Error", with a
Quick-fix to change the preference for the project to "Warning".
|
|
|
| Re: e3.5 & e4 - Is it about time Eclipse compiler fixed bugs that Sun hasn't? [message #252622 is a reply to message #252618] |
Thu, 10 April 2008 21:30  |
| Eclipse User |
|
|
|
Originally posted by: wharley.bea.com
"Neale" <neale@nealeupstone.com> wrote in message
news:ftm3qh$alo$1@build.eclipse.org...
> In bugs https://bugs.eclipse.org/bugs/show_bug.cgi?id=158870 and
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=99107, we have closed, *not
> fixed*, compiler bugs that correspond to bugs that Sun has had "In
> progress" since 2005.
>
> These, in particular relate to bugs where an error is given on a generic
> cast, but the assignment can be valid, and should therefore get an
> "unchecked conversion" warning, as the types are not "provably distinct"
> as, it seems is the wording of the JLS (see bottom of
> http://bugs.sun.com/view_bug.do?bug_id=6557279).
>
> an example is:
> Iterator<Enum<?>> it = null;
> Iterator<Enum> error = (Iterator<Enum>)it;
> which gives an error, while the following, which has the same erased types
> doe work, with the appropriate warning:
> Iterator<Enum<?>> it = null;
> Iterator<Enum> error = (Iterator)it;
>
> As a user of Eclipse, I want to benefit from generics, and be able to work
> with legacy classes.
>
> Therefore, the question I've got for those who'll discuss it, is:
>
> Should Eclipse continue to re-implement Sun's bugs, or should there be a
> distinct policy change for e4 or even for e3.5?
>
> When all is said and done, these bugs can be just another checkbox in the
> "Errors/Warnings" preference page, defaulting to "Error", with a Quick-fix
> to change the preference for the project to "Warning".
Interesting discussion topic. I would submit three points to the
discussion:
1. Some companies base commercial products on Eclipse, and license the Java
trademark; for instance, IBM and BEA both sell Java compilers. These
companies need to run, and pass, the Java Certification Kit (JCK) to get the
license. In some cases, the JCK tests rely on Sun Java bugs. This is
obviously bogus, but it is true and sometimes difficult to work around. I
don't know whether that explains this particular case or not.
2. Sometimes it is not easy to fix a subtle compiler bug without major
changes to the compiler, which add the risk of other bugs. In the case of
an abstruse corner case, it may not be worth the effort. Again, not saying
that's the case here; you asked a general question.
3. Do you want your code to compile on Eclipse but not Sun? Keep in mind
that Eclipse-exported ant scripts run against javac, by default.
-Walter Harley
JDT APT
|
|
|
| Re: e3.5 & e4 - Is it about time Eclipse compiler fixed bugs that Sun hasn't? [message #252628 is a reply to message #252618] |
Fri, 11 April 2008 05:15 |
| Eclipse User |
|
|
|
Neale wrote:
> In bugs https://bugs.eclipse.org/bugs/show_bug.cgi?id=158870 and
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=99107, we have closed,
> *not fixed*, compiler bugs that correspond to bugs that Sun has had "In
> progress" since 2005.
>
> These, in particular relate to bugs where an error is given on a generic
> cast, but the assignment can be valid, and should therefore get an
> "unchecked conversion" warning, as the types are not "provably distinct"
> as, it seems is the wording of the JLS (see bottom of
> http://bugs.sun.com/view_bug.do?bug_id=6557279).
>
> an example is:
> Iterator<Enum<?>> it = null;
> Iterator<Enum> error = (Iterator<Enum>)it;
> which gives an error, while the following, which has the same erased
> types doe work, with the appropriate warning:
> Iterator<Enum<?>> it = null;
> Iterator<Enum> error = (Iterator)it;
>
> As a user of Eclipse, I want to benefit from generics, and be able to
> work with legacy classes.
>
> Therefore, the question I've got for those who'll discuss it, is:
>
> Should Eclipse continue to re-implement Sun's bugs, or should there be a
> distinct policy change for e4 or even for e3.5?
>
> When all is said and done, these bugs can be just another checkbox in
> the "Errors/Warnings" preference page, defaulting to "Error", with a
> Quick-fix to change the preference for the project to "Warning".
>
>
>
Neale,
As I explained to you in bug reports already, these are not javac bugs
we try to mimic but behaviors described by the Java language spec. Just
because javac happens to have bugs in this area as well, doesn't mean it
gets all cast semantics wrong. The javac bug you point at is a different
scenario which I admit is buggy.
To clarify, we do not try to mimic Javac bugs, we try to implement the
spec, even if at times the spec is fuzzy or has some inconsistencies. We
try to resolve them with spec masters, and provides the best behavior;
for the benefit of our Java users (as Walter observed, we do not want to
split our community of users).
If you can claim that the spec is wrong (argue with spec provider), and
win this fight, then we will adjust our semantics to whatever the spec
decides. In this very example, I believe the spec is accurate. Remember
that raw types have some limitations.
Sincerly,
Philippe
|
|
| |
| Re: e3.5 & e4 - Is it about time Eclipse compiler fixed bugs that Sun hasn't? [message #252657 is a reply to message #252628] |
Mon, 14 April 2008 15:45 |
| Eclipse User |
|
|
|
Philippe,
Thanks for pointing out that I gave a bad example. I ought not type
when tired.
I wouldn't know who to approach regarding the spec. I had a go at
trying to find JLS 5.5, which seemed to be referred to as the latest,
and failed.
So, the example I have given agrees with the JLS, which I'll have to
take your word on, not having the JLS or the in-depth knowledge.
This still doesn't answer the question of Eclipse fixing *bugs* that Sun
hasn't, rather than closing them.
I think that there is a case for the Eclipse compiler being both:
- the best implementation of the JLS
and
- with a JLS-deviation enabled, the best Java compiler available.
As an end user, I do not want a JLS compiler, I want a compiler that
gives me the most correct behaviour, with the ability to see warnings
where using Sun's compiler will give errors.
While, I can see the point that some people have made about
compatibility with the Sun compiler (although not Ant scripts: my
Luntbuild continuous integration sys is running the Eclipse compiler
using Eclise exported Ant files), this does not preclude having
behaviour that gives us end users more power.
Thanks for your tolerance,
Neale ;)
Philippe Mulet wrote:
> Neale wrote:
>> In bugs https://bugs.eclipse.org/bugs/show_bug.cgi?id=158870 and
>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=99107, we have closed,
>> *not fixed*, compiler bugs that correspond to bugs that Sun has had
>> "In progress" since 2005.
>>
>> These, in particular relate to bugs where an error is given on a
>> generic cast, but the assignment can be valid, and should therefore
>> get an "unchecked conversion" warning, as the types are not "provably
>> distinct" as, it seems is the wording of the JLS (see bottom of
>> http://bugs.sun.com/view_bug.do?bug_id=6557279).
>>
>> an example is:
>> Iterator<Enum<?>> it = null;
>> Iterator<Enum> error = (Iterator<Enum>)it;
>> which gives an error, while the following, which has the same erased
>> types doe work, with the appropriate warning:
>> Iterator<Enum<?>> it = null;
>> Iterator<Enum> error = (Iterator)it;
>>
>> As a user of Eclipse, I want to benefit from generics, and be able to
>> work with legacy classes.
>>
>> Therefore, the question I've got for those who'll discuss it, is:
>>
>> Should Eclipse continue to re-implement Sun's bugs, or should there be
>> a distinct policy change for e4 or even for e3.5?
>>
>> When all is said and done, these bugs can be just another checkbox in
>> the "Errors/Warnings" preference page, defaulting to "Error", with a
>> Quick-fix to change the preference for the project to "Warning".
>>
>>
>>
> Neale,
>
> As I explained to you in bug reports already, these are not javac bugs
> we try to mimic but behaviors described by the Java language spec. Just
> because javac happens to have bugs in this area as well, doesn't mean it
> gets all cast semantics wrong. The javac bug you point at is a different
> scenario which I admit is buggy.
>
> To clarify, we do not try to mimic Javac bugs, we try to implement the
> spec, even if at times the spec is fuzzy or has some inconsistencies. We
> try to resolve them with spec masters, and provides the best behavior;
> for the benefit of our Java users (as Walter observed, we do not want to
> split our community of users).
>
> If you can claim that the spec is wrong (argue with spec provider), and
> win this fight, then we will adjust our semantics to whatever the spec
> decides. In this very example, I believe the spec is accurate. Remember
> that raw types have some limitations.
>
> Sincerly,
> Philippe
>
>
>
|
|
|
Goto Forum:
Current Time: Wed May 28 23:23:18 EDT 2025
Powered by FUDForum. Page generated in 0.04196 seconds |
Home