On Tue, May 24, 2011 at 8:00 AM, Grzegorz Kossakowski < [email protected]> wrote:
> 2011/5/24 Eric Ayers <[email protected]>: > > Hi Grzegorz, > > > > You mentioned the compiled classes in the class path are used to > > populate the type orace. For the most part, the type oracle types are > > compiled from source. Types that don't have source are then checked > > to see if they are binary annotations and then a type oracle reference > > is entered. > > I have addNewTypes method in mind: > > http://www.google.com/codesearch/p?hl=en#A1edwVHBClQ/dev/core/src/com/google/gwt/dev/javac/TypeOracleMediator.java&l=380 > > It reads class file data and uses it to populate TypeOracle, right? > Yes, that class does read bytecode, but the source of the bytecode isn't usually compiled .class files from the classpath, its the result of running JDT on the sources. I think it might be confusing because I worked on a project to try to build type oracle from bytecode from any compiler, but we have kind of abandoned that effort in favor of creating an equivalent to javac that spits out more than just bytecode with each compiled class. > > > Could it be true that scala-library.jar contains both libraries to use > > with the GWT compiler and some sort of runtime environment (sources) > > to compile with your app? If so, maybe the solution is to split > > scala-library.jar into the equivalent of 'dev' and 'user' components, > > such that 'user' is not needed for running the compiler and 'dev' is > > not needed for the app to link against. > > I think the answer is no. Let me explain the issue a little bit more. > The scala-library.jar contains the whole scala runtime library > including things like scala collections, etc. Those classes are used > by gwtc itself to handle jribble input (alternative to java input). > > Now, application written in Scala is going to use the same classes > (e.g. collections) but of different version. Thus we need two versions > of .class files on the classpath: one (call it A) used by gwtc > implementation and one (call it B) used for application itself. We > need B version of .class files on a classpath because JDT needs those > classes in order to properly resolve references to Scala code > (application code) from Java code. We also need B in order to populate > TypeOracle in addNewTypes method. > > Does this explain the issue a bit better now? > I think I see why you are having the problem, yes. But since the collections in B are only needed at the source level (Type Oracle does not need .class files), your "dev" jar could just contain .class files and a separate "runtime" jar could just contain .java sources and not .class files. I think this would fix your build woes, but it might make debugging the collections a bit tricky. > -- > Grzegorz Kossakowski > > -- > http://groups.google.com/group/Google-Web-Toolkit-Contributors > -- Eric Z. Ayers Google Web Toolkit, Atlanta, GA USA -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
