I can think of other cases where a more lenient compiler would be
nice, for instance the following pattern compiles nicely with Eclipse,
but causes havoc with Sun's which isn't able to do the forward
referencing:
public enum PlayerState {
STOPPED(PlayerState.PLAYING),
PLAYING(PlayerState.STOPPED, PlayerState.PAUSED),
PAUSED(PlayerState.PLAYING, PlayerState.STOPPED);
private final EnumSet<PlayerState> transitions;
PlayerState(final PlayerState... transitions){
this.transitions =
EnumSet.copyOf( Arrays.asList(transitions));
}
// State transition and query logic below...
}
So yeah, a strict compiler can save your @$$, but a little deviance
from a naive spec would also be nice!
/Casper
On Oct 23, 1:02 pm, Jess Holle <[EMAIL PROTECTED]> wrote:
> This is the one error (apart from some cases where Java is currently
> unable to infer a generic type when it is absolutely obvious and I have
> to help it out -- which are likely to be addressed in Java 7) that I
> think makes *no* sense whatsoever. This is a fine /warning/, but should
> never have been an /error.
>
> /Otherwise I'd firmly say make the compiler strict as hell.
>
> /--
> /Jess Holle
>
> Casper Bang wrote:
> > Considering how it's an error in Java to catch a checked exception
> > which is never thrown, I don't think what you suggest will sound
> > attractive to this crowd. The Sun compiler is the worst of the bunch,
> > people who want leniency usually use the Eclipse's compiler from what
> > I've seen.
>
> > /Casper
>
> > On Oct 23, 11:39 am, "Jim Blackler" <[EMAIL PROTECTED]> wrote:
>
> >> IntelliJ makes a great job of continuing to parse a source file (for
> >> preview warnings etc) despite errors in the file. In other words the
> >> whole file doesn't light up red when there's a syntax error early on.
> >> It appears as if it can't make sense of an expression it sets it to
> >> 'null' and soldiers on.
>
> >> When I'm working on a very large codebase, I'd like a compiler that
> >> did the same. That allowed me to run a program despite a compile error
> >> or two. Think of it as 'errors as warnings' as opposed to 'warnings as
> >> errors'. If the execution reached a part of the program that couldn't
> >> compile, it's translated to a runtime error.
>
> >> Why would I want to run a broken program? Isn't that the antithesis of
> >> the view that any red flags as to problems should be raised as soon as
> >> possible?
>
> >> Well, it might be that the compile error was caused by another
> >> programmer, in a part of the program I rarely execute. Then I'd like
> >> to get on with my work while he fixes it.
>
> >> It might be that I made a mistake that caused one build error and two
> >> test errors. If I can run the tests, those errors might be informative
> >> to me.
>
> >> Maybe I'd like as much information as possible from my continuous
> >> integration server, rather than it throwing in the towel before the
> >> tests, because one function won't compile.
>
> >> I would never suggest part-broken code should be published or
> >> deployed, but I think occasionally it could be a useful productivity
> >> and debugging aid.
>
> >> Is this a concept that has been tried?
>
> >> Jim
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "The
Java Posse" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/javaposse?hl=en
-~----------~----~----~----~------~----~------~--~---
