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