Re: [gwt-contrib] gwtc classpath
2011/5/24 John Tamplin : > For user code (that which will be compiled by GWT), it only looks for class > files from the classpath for annotations that it doesn't have the source to. > In DevMode, it will also load user classes from the classpath if the > visible source file is annotated with @GwtScriptOnly. John, There's one thing worrisome: mac-grek:google grek$ pwd /Users/grek/tmp/gwt-trunk/dev/core/src/com/google mac-grek:google grek$ find . -name *.java | xargs grep 'get[a-zA-Z]*ClassLoader' | wc -l 63 I'm not sure if this means anything but I wanted let you know that there are quite a few places in the code that are asking for a classloader. -- Grzegorz Kossakowski -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] gwtc classpath
2011/5/24 Eric Ayers : > If you are in the guts of the compiler and want to populate the type oracle > form byte code, you can build a list of TypeOracleMediator.TypeData objects > from any bytecode you like (doesn't have to be on classpath). This won't > feed into the building of the AST - that has to build from source. Thanks Eric and John for your reply. This solves only one problem - populating TypeOracle with data that is not coming from JDT. Other problem is with running JDT. How can I add specific classes to JDT's classpath and make it not inherit classpath of gwtc in order to avoid two different versions of the same .class files? -- Grzegorz Kossakowski -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] gwtc classpath
On Tue, May 24, 2011 at 9:33 AM, Grzegorz Kossakowski < grzegorz.kossakow...@gmail.com> wrote: > 2011/5/24 Eric Ayers : > > 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. > > Do you want to say that gwtc doesn't read .class files from classpath > at all? Or if it does in what cases and what for? > > > 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. > > The problem is that I don't have .java files for scala-library (it's > written in scala but compiled to jribble[1]). If I have java class J > referring to scala class S (that we have .jribble for) then in order > to run JDT for J we need information about S. The idea was to use > .class file corresponding to S so JDT can correctly resolve references > to S from J and build it's AST. Then JDT could build AST nodes for > Java files that would get converted to GWT nodes and for jribble we > have our own logic that converts jribble directly to GWT nodes without > JDT involved in a process. We would need to populate TypeOracle with > data corresponding jribble classes but we could use the same .class > files that JDT was using for Scala (jribble) code. > > To sum up: > * version A of scala-library is needed by gwtc itself and we need > (and have) only .class files for it > * version B of scala-library is in two forms: .jribble files and > .class files. Class files are needed by JDT in order to resolve > references to scala-library from Java sources of application we are > compiling and by special logic that populates TypeOracle for that > application for .jribble files. We need .jribble files to build GWT > AST nodes. > > Now the question is how can I make version B of .class files visible > only to JDT and special logic in TypeOracleMediator? Sounds I need > custom classloader but I fear that gwtc reads .class files somewhere > else for whatever purpose and I would get some nasty inconsistencies > that would be extremely hard to debug. > If you are in the guts of the compiler and want to populate the type oracle form byte code, you can build a list of TypeOracleMediator.TypeData objects from any bytecode you like (doesn't have to be on classpath). This won't feed into the building of the AST - that has to build from source. > If it's not a case how can I plug my own classes that would be visible > to JDT? Is AbstractCompiler. INameEnvironmentImpl what I should be > looking at? > > [1] jribble contains similar information as java code but jdt doesn't > know about it, obviously. > > -- > 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
Re: [gwt-contrib] gwtc classpath
On Tue, May 24, 2011 at 9:33 AM, Grzegorz Kossakowski < grzegorz.kossakow...@gmail.com> wrote: > 2011/5/24 Eric Ayers : > > 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. > > Do you want to say that gwtc doesn't read .class files from classpath > at all? Or if it does in what cases and what for? For user code (that which will be compiled by GWT), it only looks for class files from the classpath for annotations that it doesn't have the source to. In DevMode, it will also load user classes from the classpath if the visible source file is annotated with @GwtScriptOnly. -- John A. Tamplin Software Engineer (GWT), Google -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] gwtc classpath
2011/5/24 Eric Ayers : > 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. Do you want to say that gwtc doesn't read .class files from classpath at all? Or if it does in what cases and what for? > 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. The problem is that I don't have .java files for scala-library (it's written in scala but compiled to jribble[1]). If I have java class J referring to scala class S (that we have .jribble for) then in order to run JDT for J we need information about S. The idea was to use .class file corresponding to S so JDT can correctly resolve references to S from J and build it's AST. Then JDT could build AST nodes for Java files that would get converted to GWT nodes and for jribble we have our own logic that converts jribble directly to GWT nodes without JDT involved in a process. We would need to populate TypeOracle with data corresponding jribble classes but we could use the same .class files that JDT was using for Scala (jribble) code. To sum up: * version A of scala-library is needed by gwtc itself and we need (and have) only .class files for it * version B of scala-library is in two forms: .jribble files and .class files. Class files are needed by JDT in order to resolve references to scala-library from Java sources of application we are compiling and by special logic that populates TypeOracle for that application for .jribble files. We need .jribble files to build GWT AST nodes. Now the question is how can I make version B of .class files visible only to JDT and special logic in TypeOracleMediator? Sounds I need custom classloader but I fear that gwtc reads .class files somewhere else for whatever purpose and I would get some nasty inconsistencies that would be extremely hard to debug. If it's not a case how can I plug my own classes that would be visible to JDT? Is AbstractCompiler. INameEnvironmentImpl what I should be looking at? [1] jribble contains similar information as java code but jdt doesn't know about it, obviously. -- Grzegorz Kossakowski -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] gwtc classpath
On Tue, May 24, 2011 at 8:00 AM, Grzegorz Kossakowski < grzegorz.kossakow...@gmail.com> wrote: > 2011/5/24 Eric Ayers : > > 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
Re: [gwt-contrib] gwtc classpath
2011/5/24 Eric Ayers : > 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? > 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? -- Grzegorz Kossakowski -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] gwtc classpath
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. 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. On Mon, May 23, 2011 at 6:29 PM, Grzegorz Kossakowski wrote: > Hello, > > I run into a case when I want to have different classpath for running > gwtc (through com.google.gwt.dev.Compiler class) from classpath > containing source code that gwtc would compile. > > Let me give you a specific scenario. My fork of gwt is using > scala-library.jar of some version A for implementing internals of > gwtc. Now application that gwtc should compile uses different version > B of scala-library.jar that is binary incompatible with A. Is it > possible to run gwtc so it uses A for it's own execution but uses B > for JDT execution, populating TypeOracle, etc.? > > One thing that's worth mentioning: I'm talking here about compiled > classes in classpath because they are used to populate TypeOracle. > Source code (used for constructing GWT AST nodes) is in one copy > corresponding to version B. > > -- > 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
[gwt-contrib] gwtc classpath
Hello, I run into a case when I want to have different classpath for running gwtc (through com.google.gwt.dev.Compiler class) from classpath containing source code that gwtc would compile. Let me give you a specific scenario. My fork of gwt is using scala-library.jar of some version A for implementing internals of gwtc. Now application that gwtc should compile uses different version B of scala-library.jar that is binary incompatible with A. Is it possible to run gwtc so it uses A for it's own execution but uses B for JDT execution, populating TypeOracle, etc.? One thing that's worth mentioning: I'm talking here about compiled classes in classpath because they are used to populate TypeOracle. Source code (used for constructing GWT AST nodes) is in one copy corresponding to version B. -- Grzegorz Kossakowski -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
