Hmmm....

I guess I see no need to go down that path.

Jim Blackler wrote:
> Well it may be possible to compile most of a class, for instance if I
> introduce a field with an invalid type. Only at the moment that
> something tried to use that type would an exception be thrown.
>
> 2008/10/24 Jess Holle <[EMAIL PROTECTED]>:
>   
>> So I guess that should mean a "compile all possible classes" compiler more
>> than a lenient compiler.
>>
>> In a CI environment you might have 100's of modified sources.  If some fail
>> to compile, you'd like to ensure that (1) all other possible sources are
>> compiled [javac will simply stop trying at some point and thus fail to
>> compile some sources which could be comiled] and (2) continue with the build
>> even though some compilations failed.  If this is coupled with retention of
>> previous class versions, then you're about as lenient as possible from a CI
>> perspective -- but not from the perspective of producing class files for
>> bogus sources or guessing the intent of bogus source.
>>
>> Jim Blackler wrote:
>>
>> Consider a continuous build server that makes a large project, then
>> runs tests on the code. If one programmer makes a submission that
>> causes a compile error in a method, this breaks the build and the
>> tests never even start. However many tests may never execute the
>> broken method. Assuming the programmer that broke the build isn't me
>> (of course), I'd still like to see my own test results. It would also
>> be nice to get a visual indication of which tests the compile error
>> would affect in practice.
>>
>> Jim
>>
>> 2008/10/24 Alexey Zinger <[EMAIL PROTECTED]>:
>>
>>
>> I hope I'm not missing something crucial in this discussion, but what is the
>> benefit of running partially compiled code?  If I introduce a compilation
>> error, why do I want to proceed with either an incomplete class set or one
>> class out-of-date, while another is new?
>>
>> Alexey
>> 2001 Honda CBR600F4i (CCS)
>> 1992 Kawasaki EX500
>> http://azinger.blogspot.com
>> http://bsheet.sourceforge.net
>> http://wcollage.sourceforge.net
>>
>>
>>
>> --- On Fri, 10/24/08, Reinier Zwitserloot <[EMAIL PROTECTED]> wrote:
>>
>>
>>
>> From: Reinier Zwitserloot <[EMAIL PROTECTED]>
>> Subject: [The Java Posse] Re: A lenient compiler?
>> To: "The Java Posse" <[email protected]>
>> Date: Friday, October 24, 2008, 9:39 AM
>> Eclipse does this, even if you don't use the debugger.
>> The method with
>> the error in it is replaced with a simple exception, and
>> the rest is
>> compiled normally. When that method is called, it blows up,
>> otherwise,
>> it runs fine.
>>
>> There are two separate steps in creating a lenient
>> compiler:
>>
>> 1. 'error recovering' parser: We're obviously
>> not going to get far if
>> the simplest of syntax errors makes the parser just stop.
>>
>> 2. a compiler that still produces a class file and knows to
>> insert a
>> dummy.
>>
>>
>> #1 is by far the hardest thing to do, and we're in
>> luck: javac is even
>> better at recovery than ecj these days (particularly when
>> you use a
>> lot of anonymous classes; the ecj error recovery system
>> just stops
>> flat out when something goes wrong there), and the new
>> langtools
>> project is focussed on improving recovery even more. #2 is
>> relatively
>> easy, but as far as I can tell, javac doesn't currently
>> do it. Hacking
>> javac shouldn't even be that difficult, but, given that
>> the hard work
>> is already done, it would be great if the official javac
>> just had a
>> parameter (something like -Xdummy at first, possibly
>> introduce it as a
>> required feature for the 'jdk' stamp (no -X, just
>> -dummy), later. It
>> might be worth it to see what netbeans does; if it does
>> produce dummy
>> code, then just rip the javac back out of netbeans, and
>> voila.
>>
>>
>> On Oct 24, 1:39 pm, Christian Catchpole
>> <[EMAIL PROTECTED]>
>> wrote:
>>
>>
>> Or simply..
>>
>> for (;;) {
>>   System.out.println("Donkey.");
>>
>> }
>>
>> On Oct 24, 4:32 pm, Casper Bang
>>
>>
>> <[EMAIL PROTECTED]> wrote:
>>
>>
>> - at the failing code block, insert throw
>>
>>
>> new
>>
>>
>> CodeMissingYouNoobRuntimeException();
>>
>>
>> Nah, better to reuse
>>
>>
>> java.nio.charset.CoderMalfunctionError ;)
>>
>>
>>
>>
>>
>>
>>
>>     
>
> >
>
>   


--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---

Reply via email to