@andreififiita in short, no, probably because it caused some problems for actually being able to remove types that were otherwise unreachable - my guess is it has to do with holding on to Class instances (and passing them around anywhere you want, etc), as opposed to just doing an instanceof check, which could be done more simply
what are you trying to do with this? if you are dealing with two classes, i think you could check it with subclassType.getSuperclass().equals(clazz), but i dont think getInterfaces is emulated either (likely so they can be removed as well)
@niloc132 Well i was thinking that in the future i might modify the class hierarchy so i am afraid that type of code would not work anymore. For example let's say i have main class ShipClass, which is extended by BigShipClass. The code above will not work for a class BigFishingShipClass that extends BigShipClass (which extends ShipClass), am i correct? (please don't mind the fact that modelling in this example should be done with properties and types, not different classes, it is just a random example)
ditto requestfactory-server, if anyone still uses that
it isnt a hard change (can even be made automatically, i contributed such a script to the grpc-java project not long ago), just depends on how a contributor wants to get it done
just filed Vertispan/gwt-rpc#39 for the gwt-rpc fork that i worked on
@andreififiita i don't understand why that wouldnt work - if you just loop and check the superclass, your use case should work great?
it could be worth a little time to see what it would take to add such emulation, and see if it generally adds a cost - or finish modeling what you're thinking of and see if you can write your own without changing gwt (with other costs that might incur for use cases other than yours)
I use DominoKit and GWT 2.9.0. I can see all source code in Chrome except one module. I copied one working module into my new module and I just made some simple change on the new module at Java source and its related pom.xml. I can compile the new module successfully. But I can't see its source code in Chrome. I can't figure it out. I do appreciate it if you would give me some suggestion.
1 reply
Finally, I made my project work perfect (DominoKit, UI, MVP). GWT is a very good tool. I list what I found so far:
- "mvn clean install" works although there are some package name errors after renaming.
- "mvn clean install" finishes without error. But code is not sent to Chrome.
- New module is not loaded till I changed some other module.
After I set it up right, everything is a piece of cake.\
rconoverq (rconoverq): the only dependency on servlets at all is if you use gwt-rpc or request-factory, otherwise jetty 11 or even vertx etc will work great
Gwt runs its dev mode using jetty 9 presently, but production js doesn’t require any particular server (and using the provided server apis only depend on the old servlet api at this time, but we can certainly update that, and welcome contributions)
(teavm did just get a 0.7 release, i've been meaning to try that out, been waiting for it for a long time)
gwt 2.10 is about ready for acceptance testing for a release, bust most of the improvements are happening outside the compiler and old (but backwards compatible) runtime
j2cl is worth a look if you are interested in kt as a frontend language and gwt-level optimized output, though i haven't personally tried putting kt through it yet
@dac2k9_twitter you can set a system property to exclude one or more java 9+ module jars from annotation scanning, or give the test builds of gwt 2.10 a try
agreed that dont use devmode for server code is the best answer, though given the question seems to be focusing on a workaround...
i'm mistaken about setting a system property, instead you have to override the gwt-provided JettyLauncher type and pass it to dev mode as an argument. Something like this in your project (this is not client code, but you also don't want it shipping with your server...)
public class DevModeJettyLauncher extends JettyLauncher {
@Override
protected WebAppContext createWebAppContext(TreeLogger logger, File appRootDir) {
WebAppContext webAppContext = super.createWebAppContext(logger, appRootDir);
webAppContext.setAttribute("org.eclipse.jetty.server.webapp.WebInfIncludeJarPattern", "none");//this is just a regex that matches nothing
return webAppContext;
}
}add to args something like -server com.company.project.server.dev.DevModeJettyLauncher
@mnouwens if you've got a use case and some time to help us validate it (i havent used kotlin much), either over in the vertispan/j2cl channel or on the j2cl-maven-plugin issue tracker. I don't expect google to provide working samples of this for quite some time, given the gaps in their other samples at github.com/google/j2cl
@/all GWT 2.10 needs testers, please take a look if you'll have a spare hour next week sometime to help us confirm there are no last-second surprises https://groups.google.com/g/google-web-toolkit-contributors/c/zazInoF0-dA
@viego:legacy-project.de rough release notes:
- Updated htmlunit and jetty to more recent versions
- Dropped support for IE8/9/10
- Dropped support for Java 7
- Support long classpaths by using CLASSPATH env vars to run child permutation workers
- Many enhancements to emulation APIs and generated code
- Changed maven groupid from com.google.gwt to org.gwtproject
for GWT 2.10 it might be nice to fix the support for mouse wheel events. I mentioned it in https://github.com/gwtproject/gwt/issues/9671#issuecomment-942799703 , see also gwtproject/gwt#8459, gwtproject/gwt#6457
my hope is that after we finish this transition away from google managing the release, we can release more rapidly, so it shouldn't take too long to get this hammered out
I hope that contributing to the gwt project will become easier and that the 2.x developemnt will receive some great changes and we can stand on the same level of perception as angular or react
@viego:legacy-project.de the CLA won't be required, and github pull requests will be used - but the main gwtproject/gwt repo will mostly be for the compiler itself, and will aim to maintain backwards compatibility wherever possible (since gwt-dev relies on a specific gwt-user version, and we don't want to limit projects from updating their compiler just because they use now-deprecated or removed features)
instead, the new modules being created are intended to be the way forward for future development, how to add/change/remove apis, and to keep them decoupled from the compiler itself (and indeed, compatible with j2cl out of the box
@dac2k9_twitter check out the gwt-contrib mailing list, there is a posting about a sample maven repo that hosted at repo.vertispan.com with some artifacts that try out the new groupid, and contain all of the other changes to be made in gwt 2.10 - the latest version is 2.10.0-new-groupid-5
if you're asking how to test the official release, that will be ready early next week, after I've gotten a few other testing volunteers (mostly need people with access to windows, ie11)