I want to emulate a given type from a third-party library (GAE),
a Java class that is not supported by GWT:
com.google.appengine.api.datastore.GeoPt;
How do I emulate this class so GWT will support it? Where should I put the GeoPt.java file in my GWT app?
I cannot put it in the client path the packaging is different that my app. What could be the solution for this?
Further I assume, you have a module com.example.Example.gwt.xml .
I think you have two options. You can create a separate module, eg. AppEngine.gwt.xml, which source tag set to "api" and you put it into on com.google.appengine level. Then, you module need to inherit it - <inherits name="com.google.appengine.AppEngine"/>. It can be even in the same project - one project might have multiple modules.
Another approach is when you eg. want to reimplement a class only in GWT, while use same one in pure Java. Then in your module you create tag which points to a folder that will be a kind of root for a replaced classes. So, in your module you add <super-source path="appengine"/> and then you would put the class to com.example.appengine.com.google.appengine.api.datastore.GeoPt. You can read more on this at Organizing Projects, go to Overriding one package implementation with another section
Related
Well it's actually not in the library itself, it's in a different library which depends on the annoration processor.
I have the roughly the following project structure.
Annotation Processor -> Android Library module -> Android App module
In the Android app I use annotations on some classes and the processor generates class that I'd like to use (and call its methods) in the library module. Is that even possible?
Right now I can only access it from the App module itself.
I actually feel like it all quite makes sense, just wonder if there is some way how to workaround that.
(When I pull the classes referencing generated code from the library module into app module itself, it works perfectly, I just want to have them in the library)
So far the only solution I was able to come up with was to not use the generated class itself, but rather define an interface, use that and let the code generator generate an implementation of it. Then provide the implementation from the app module back to the library module at runtime.
Is it possible to modularize the app/models folder adding packages into it in play2.1 framework (java)?
Actually I have to put all of my classes (models) into app/models folder, otherwise play! framework can't find my classes on compilation time. I really don't like to have all of my classes into a single folder.
I did a research about play2 projects on github and most of them are simple and have all of their models into app/models with no packages into this folder as the samples bundled with the framework.
Do you add packages into app/models folder in your project? If so, do you have to configure something else?
Thanks for your time.
You can create as many packages in the models package as you want, and I consider this good practice. I.e. this is how my current structure looks like:
/models
/i18n
/forms
/roles
/utils
/users
The only thing that you must change is that you must use the fully qualified name as parameter in templates. (see this post)
Besides that, if you call static methods, you must also use the full name: #User.getUsername becomes #users.User.getUsername.
I have solution split into 2 projects:
The independent project contains interface ExampleInf and declares some services needed for the application. Those services are provided by the third party API (Hadoop client API). This project contains GUI components and other application logic but does not link third party libraries that provide services declared by ExampleInf. There is no class implementing ExampleInf in this project.
The dependent project that contains links to third party libraries. This project contains class ExampleImpl that encapsulates third party API and implements ExampleInf.
In the independent project there is class (let's call it class A) that consumes (uses) services declared by ExampleInf. Because the independent does not link the dependent project, in order to use ExampleInf it needs to load its implementation ExampleImpl dynamically in runtime. Also it needs to dynamically load all the third party libraries required by ExampleImpl.
Currently this is done by a bunch of constants (public static final String attributes) that contain paths to dependent project where dynamically loaded resources are located and a lot of messy ClassLoader code. I do not consider this to be a good solution. Is there any pattern, best practice or common way how this can be done? What would you recommend in your experience?
This pattern reminds me a bit of dependency injection in Java EE. At least I think it is good idea to externalize the locations of classes and libraries (.jar-s) that need to be loaded dynamically to XML and then load them all in cycle instead of calling ClassLoader.loadClass separately for each constant. Is there any nice clean way how to load XML in the same package and load classes and jars specified by that XML? Code example would be much appreciated.
You can use the ServiceLoader utility to do this (this is how many of the jdk services are loaded, e.g. xml libraries and modern jdbc driver libraries). If the dependent project is part of the classpath at startup, then you are good to go (assuming it is setup correctly). otherwise, you would need to load the dependent project in a nested classloader and pass that to the load(Class,ClassLoader) method (or set the classloader as the current context classloader before calling load(Class)).
I am not so aware of the java project structure. I have few selenium tests which I want to write in java. So I have chosen eclipse as my editor. Here I wan to create a new java project with proper folder structure as I am planning to add few more java classes in future.
Please let me know how to create an idea java project in eclipse. I have seen people create something like com.org.project_name etc and then src , resources directories inside that.
I am not able to make any sense out of those. Please explain.
The software project management tool Apache Maven recommends, uses and expects a common directory layout that can be considered as best practise.
An overview can be found here: Introduction to the Standard Directory Layout
In Java you can create packages. Simply said packages are folders that contain classes.
The statement import java.net.Socket means: from the folder java/net import the class named Socket.
The statement package myApplication.util.SuperCounter means that the class SuperCounter can be found under myApplication/util folder.
Packages are an easy way to organize your work. Because in a big project you will have class name collisions (i.e. classes that use the same name). With packages you can avoid it.
Also Java supports default (private, public, protected). Default methods, attributes, classes can only be seen by elements in the same package!
Eclipse should create the proper folders for you...here is an example
http://www.wikihow.com/Create-a-New-Java-Project-in-Eclipse
If you want to have a Java Project then go to File -> New -> Java Project.
If its web application then, select Dynamic Web Project.
These will automatically create the required structures.
In Java you work in packages, which define the scope of your classes, and is basically the only thing you should really be concentrating on in the beginning. There's a good article on the subject here - http://docs.oracle.com/javase/tutorial/java/package/packages.html
I have a Java project that expects external modules to be registered with it. These modules:
Implement a particular interface in the main project
Are packaged into a uni-jar (along with any dependencies)
Contain some human-readable meta-information (like the module name).
My main project needs to be able to load at runtime (e.g. using its own classloader) any of these external modules. My question is: what's the best way of registering these modules with the main project (I'd prefer to keep this vanilla Java, and not use any third-party frameworks/libraries for this isolated issue)?
My current solution is to keep a single .properties file in the main project with key=name, value=class |delimiter| human-readable-name (or coordinate two .properties files in order to avoid the delimiter parsing). At runtime, the main project loads in the .properties file and uses any entries it finds to drive the classloader.
This feels hokey to me. Is there a better way to this?
The standard approach in Java is to define a Service Provider.
Let all module express their metadata via a standard xml file. Call it "my-module-data.xml".
On your main container startup it looks for a classpath*:my-module-data.xml" (which can have a FrontController class) and delegates to the individual modules FrontController class to do whatever it wants :)
Also google for Spring-OSGI and their doco can be helpful here.
Expanding on #ZZ Coder...
The Service Provider pattern mentioned, and used internally within the JDK is now a little more formalized in JDK 6 with ServiceLoader. The concept is further expanded up by the Netbeans Lookup API.
The underlying infrastructure is identical. That is, both API use the same artifacts, the same way. The NetBeans version is just a more flexible and robust API (allowing alternative lookup services, for example, as well as the default one).
Of course, it would be remiss to not mention the dominant, more "heavyweight" standards of EJB, Spring, and OSGi.