Re: sjavac always compiled?
On 10/06/2015 10:21, Andreas Lundblad wrote: On Wed, Jun 10, 2015 at 11:02:19AM +0200, Andreas Lundblad wrote: What's the approperiate procedure here? Should I submit a patch that adds the type arguments to avoid forcing people to update their boot jdks? I have now pushed a patch that adds the type arguments. http://hg.openjdk.java.net/jdk9/dev/langtools/rev/5021d414632a Thanks for that. I should probably have tested with 8u40 as a boot JDK before bringing up this issue. -Alan
Re: sjavac always compiled?
On Wed, Jun 10, 2015 at 11:02:19AM +0200, Andreas Lundblad wrote: > What's the approperiate procedure here? Should I submit a patch that adds the > type arguments to avoid forcing people to update their boot jdks? I have now pushed a patch that adds the type arguments. http://hg.openjdk.java.net/jdk9/dev/langtools/rev/5021d414632a -- Andreas
Re: sjavac always compiled?
On Wed, Jun 10, 2015 at 09:06:44AM +0100, Alan Bateman wrote: > > > On 10/06/2015 09:00, Erik Joelsson wrote: > >Hello, > > > >Sjavac has always been compiled in the interim langtools step, the > >configure flag only affects using it to compile the rest of the > >java classes. > > > >Has a bug been created for this? > > > I haven't created a bug for this as I wasn't sure if this was > something in my environment or an issue with the sjavac patch and > some interaction with the interim javac build. I can reproduce this by compiling that method alone using 8u31. Seems to be a javac type inference bug, because changing Collectors.toMap to Collectors.toMap solves the issue. (It seems to have been fixed in 8u40.) What's the approperiate procedure here? Should I submit a patch that adds the type arguments to avoid forcing people to update their boot jdks? -- Andreas
Re: sjavac always compiled?
On 10/06/2015 09:00, Erik Joelsson wrote: Hello, Sjavac has always been compiled in the interim langtools step, the configure flag only affects using it to compile the rest of the java classes. Has a bug been created for this? I haven't created a bug for this as I wasn't sure if this was something in my environment or an issue with the sjavac patch and some interaction with the interim javac build. -Alan
Re: sjavac always compiled?
Hello, Sjavac has always been compiled in the interim langtools step, the configure flag only affects using it to compile the rest of the java classes. Has a bug been created for this? /Erik On 2015-06-10 09:53, Alan Bateman wrote: There was a sjavac update pushed to jdk9/dev yesterday (JDK-8054717). I seem to be running into build issues on OS X since then (clean build, not a reconfigure). My boot JDK is 8u31. My configure command does not specify --enable-sjavac so I'm surprised this code is being compiled. Anyone else seeing this? -Alan Building target 'default' in configuration 'macosx-x86_64-normal-server-release' Compiling 830 files for BUILD_INTERIM_LANGTOOLS /ws/jdk9-dev/langtools/src/jdk.compiler/share/classes/com/sun/tools/sjavac/Util.java:231: error: no suitable method found for collect(Collector>) return c.stream().collect(Collectors.toMap(indexFunction, o -> o)); ^ method Stream.collect(Supplier,BiConsumerCAP#2>,BiConsumer) is not applicable (cannot infer type-variable(s) R#1 (actual and formal argument lists differ in length)) method Stream.collect(Collector) is not applicable (cannot infer type-variable(s) R#2,A,CAP#3,T#3,K,U (argument mismatch; Collector> cannot be converted to Collector>)) where T#1,I,R#1,T#2,R#2,A,T#3,K,U are type-variables: T#1 extends Object declared in method indexBy(Collectionextends T#1>,Function) I extends Object declared in method indexBy(Collectionextends T#1>,Function) R#1 extends Object declared in method collect(Supplier,BiConsumerT#2>,BiConsumer) T#2 extends Object declared in interface Stream R#2 extends Object declared in method collect(Collectorsuper T#2,A,R#2>) A extends Object declared in method collect(Collectorsuper T#2,A,R#2>) T#3 extends Object declared in method toMap(Functionsuper T#3,? extends K>,Function) K extends Object declared in method toMap(Functionsuper T#3,? extends K>,Function) U extends Object declared in method toMap(Functionsuper T#3,? extends K>,Function) where CAP#1,CAP#2,CAP#3,CAP#4 are fresh type-variables: CAP#1 extends Object from capture of ? CAP#2 extends T#1 from capture of ? extends T#1 CAP#3 extends Object from capture of ? CAP#4 extends Object from capture of ? 1 error
sjavac always compiled?
There was a sjavac update pushed to jdk9/dev yesterday (JDK-8054717). I seem to be running into build issues on OS X since then (clean build, not a reconfigure). My boot JDK is 8u31. My configure command does not specify --enable-sjavac so I'm surprised this code is being compiled. Anyone else seeing this? -Alan Building target 'default' in configuration 'macosx-x86_64-normal-server-release' Compiling 830 files for BUILD_INTERIM_LANGTOOLS /ws/jdk9-dev/langtools/src/jdk.compiler/share/classes/com/sun/tools/sjavac/Util.java:231: error: no suitable method found for collect(Collector>) return c.stream().collect(Collectors.toMap(indexFunction, o -> o)); ^ method Stream.collect(Supplier,BiConsumerCAP#2>,BiConsumer) is not applicable (cannot infer type-variable(s) R#1 (actual and formal argument lists differ in length)) method Stream.collect(Collector) is not applicable (cannot infer type-variable(s) R#2,A,CAP#3,T#3,K,U (argument mismatch; Collector> cannot be converted to Collector>)) where T#1,I,R#1,T#2,R#2,A,T#3,K,U are type-variables: T#1 extends Object declared in method indexBy(Collectionextends T#1>,Function) I extends Object declared in method indexBy(Collectionextends T#1>,Function) R#1 extends Object declared in method collect(Supplier,BiConsumer,BiConsumer) T#2 extends Object declared in interface Stream R#2 extends Object declared in method collect(Collectorsuper T#2,A,R#2>) A extends Object declared in method collect(Collectorsuper T#2,A,R#2>) T#3 extends Object declared in method toMap(Functionsuper T#3,? extends K>,Function) K extends Object declared in method toMap(FunctionT#3,? extends K>,Function) U extends Object declared in method toMap(FunctionT#3,? extends K>,Function) where CAP#1,CAP#2,CAP#3,CAP#4 are fresh type-variables: CAP#1 extends Object from capture of ? CAP#2 extends T#1 from capture of ? extends T#1 CAP#3 extends Object from capture of ? CAP#4 extends Object from capture of ? 1 error
