I believe that what you expect from the GWT compiler is probably a lot harder to achieve than "just" pruning unused methods (which is already a great feature IMO).
gwtc compiles Java source -> Javascript. I assume that it can't read Java bytecode at all (?) So just providing a jar file which contains class A as bytecode won't work. In theory, gwtc might be able to completely ignore A, but that's generally not so easy. (It's something that javac can't do either: It needs a .java file or a .class file for every type you reference.) Therefore, I wouldn't say that it's a shame, or that it's disappointing at all. It would be a quite ambitious feature for a compiler of a strongly typed language. On Jan 21, 5:12 pm, getaceres <[email protected]> wrote: > I have something similar. I have this: > > package com.company.pack > class A {} > > package com.company.client > class B implements Serializable { > <some serializable fields> > private transient A field; > > private A getA() { > return field; > } > > private void setA(A val) { > this.field = val; > } > > } > > Both classes are JPA classes and it's only that B class has a > relationship with a non serializable A class, which the GWT client > doesn't have to know about. The rest of it, is serializable. > In this case, class A and B are in the same jar and the jar has the > sources included, but only B is in the GWT module (the client folder). > When I try to include this jar in my GWT project, I get an exception: > > No source code is available for type com.company.pack.A; did you > forget to inherit a required module? > > I tried putting the GwtTransient annotation to field A but the result > is the same. I think that GWT should completely ignore the classes > that are transient and its getters and setters and don't try to even > compile them. > It's a shame that, almost for every hibernate class that I have, I > have to create another class which has exactly the same fields, except > for one or two of them, and that I have to be putting all the data > from one bean to another all the time. It would be so much simple to > mark in my beans just the parts that the compiler shouldn't care > about. > > On 14 ene, 14:55, Chris Lercher <[email protected]> wrote: > > > > > Well, it works for me. I didn't try it with TopLink - I used POJOs > > instead - but when I declare the fieldtransient, it works (according > > to the SOYC Compile Report). > > > ---------------------- > > Example: > > > public class WantThat implements Serializable { > > privatetransientDontWantThat dontWantThat; > > > public DontWantThat getDontWantThat() { > > return dontWantThat; > > } > > > } > > > public class DontWantThat implements Serializable { > > > } > > > @RemoteServiceRelativePath("some") > > public interface SomeService extends RemoteService { > > WantThat getWantThat();} > > > ------------------------- > > > DontWantThat is not in my Compile Report. If I remove thetransient > > keyword, it is. > > > Maybe there's something different with your case. Maybe something is > > accessing your "getDontWantThat()"? Circular references at least?
-- You received this message because you are subscribed to the Google Groups "Google Web Toolkit" 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/google-web-toolkit?hl=en.
