I'm doing a project with modules in android, and within each module I have sub-packages with their respective entities, repositories, etc. To handle access within this packages, I must use public class, and this gives access to other modules. I need a single class/packages to be used as an API that can be Access from other modules and hides internal implementation.
I'dont know if java allow this? how i can do this?
thanks
Access from other modules and hides internal implementation
Yep. Extract the API to an interface and then define an implementation of that interface with a visibility modifier lower than that of the public interface. Hide the binding of that interface-to-concrete implementation via an init method of your module. Expose this init method to your module too.
Using dependency injection or a service locator pattern, you can then request the implementation of this interface from your caller modules. Generally, in more complex applications, it's dependency injection you're wanting to use. In this case, a factory method is required to bind between the interface and concrete implementation.
If you are using a dependency injection library with Java then you're likely looking at using an #Binding and an #Provides method to achieve this wiring and provisioning respectively.
Related
I have an interface A with a method Result doAction(Param param). I have a Spring application that will use implementations of the interface and call doAction() on it.
But the application does not define an implementation itself. The idea is that other people can provide their own implementations of the interface in JARs (plugins), the main application will pull those in as dependencies, and call doAction() on the JAR's implementation.
Any idea how I can do this in practice? The ideas I had were:
Try to autowire the implementation through Spring Boot, but for that I would need to know its package and add it to the component scan. So it would mean putting requirements on the naming of the "plugin" jar. Something I would prefer not to do.
With plain Java my first idea was to keep a registry of implementations (e.g. a Set<Interface A>), but the plugin wouldn't be able to access the registry -- it would be a dependency cycle.
What I'm doing right now is defining a Rest API that the "plugin" needs to implement, deploy the plugin in the same environment and the main application just makes the calls through the Rest API.
But for performance reasons I'm looking for a solution with more direct calls that doesn't involve communication over the network. Any suggestions?
I am adding swagger 1.5.0 support to an existing java application that implements 20+ different REST APIs and uses Jersey 1.17.1 with package scanning. Does anyone have any best practice recommendations? For example:
Should swagger definitions be added to each java class or can they be
added to an independent file(s) to avoid touching each class?
Each API requires the same set of headers which I have defined in great details for the first class using #ApiImplicitParam. Instead of
repeating that information for every operation of every class, is
there a way to apply it to all APIs?
There are a zillion ways to integrate the swagger 1.5.x libraries (note: 1.5.10 is latest) with a JAX-RS application. I suggest you follow a scheme like in the swagger-petstore and split the files by top-level path segments, which should provide a logical organization.
For repeated headers, you can have each resource class extend a base class which has an annotated class-level variable. That will apply to each operation in the classes that extend it.
I split up my projects into multi-module projects often and heavily.
How can I declare in the Maven 3 POM that "Some implementation of API xy has to be available in the package".
For example, if I split my services layer in a services-api and services-impl and declare in the API that the deployable has to have a dependency on an implementation of services-api, even if its not the services-impl module itself.
Is this possible?
If you need an implementation of an API, then something has to choose which impl. If you don't care which, you have then 2 choices:
Either you just choose an impl and declare it in the POM, using <scope>runtime</scope>, which excludes the impl at compile time, but it will be made available to the container.
Or you use or implement a Service Provider Interface (SPI)
To quote from the Oracle tutorial (emphasis added):
A set of programming interfaces and classes that provide access to some specific application functionality or feature. The service can define the interfaces for the functionality and a way to retrieve an implementation.
My question: is there a way to use javax.inject (or any other Java injection framework) for a consumer of a Provider to use multiple implementations at runtime if the number of implementations is unknown at build time?
Some background on my need for this: I work on reusable frameworks which, for the most part, combine the use of a factory and a service locator to load implementations. Several of these seem like they could be reworked to use proper dependency injection, at least insofar as removing the service locator, but there are some that require loading all implementations found on the class path. This is achieved through a simple "multi-implementation" implementation which then loads the other implementations, saving the instances off in a collection and looping over them when the API is called.
I assume you are running on the Java SE platform (as opposed to a Java EE platform) in which case I would highly recommend HK2 (see https://hk2.java.net/2.2.0/). It has a lot of support for efficiently instantiating services and it is certainly the case that multiple implementations of the same contract can be available at runtime. Then at runtime there are a whole manner of mechanisms that you can use to choose which particular implementation will satisfy the dependency (i.e., service ranking or assisted injection etc)
For build time with hk2 you can create "inhabitant" files that describe services to the point where they can be satisfied at runtime without classloading all of them (only the one that is picked will be classloaded if you do it properly). This can be a huge performance boost at boot time of your application (if that sort of thing matters to you).
If you are running on a Java EE platform you can also use HK2, but you should then also give a long look at CDI. Both CDI and HK2 are implementations of JSR-330, and so both work with javax.inject API
So you basically have one implementation that delegates a call to an API method to all other implementations. you will need to inject this bean in all the dependencies you can do this in spring by giving this bean (this implementation instance) an id and then inject it using #Autowired #Qualifier("bean_id"). now for listing all implementations that can be done easily in spring by injecting an applicationContext into your delegate implementation and then querying the applicationContext for all beans implementing the API interface.
So I'm writing a bunch of components (that will be packaged as JARs), and they are all using Guice for DI. These components are just reusable, "commons"-type JARs that will be used by other downstream projects.
My understanding with Guice is that you implement a concrete Module and use that to bind objects together and, in effect, configure all of your DI. It is also my understanding that you should then have a single "bootstrapping" phase where the Guice injector is created, and then all dependencies the module is configured with are then fetched from that injector with injector.getInstance(SomeClass.class).
That would work great in standalone application, that had some entry point, where you could invoke an init()-style method to then bootstrap Guice with, but in a headless JAR that has no entry point, I'm struggling with trying to determine when/where/how to bootstrap Guice.
These will be JARs living on the classpath and, at any point in time, an external entity could invoke and class and any method inside of them. I thought about using up a "lazy initialization" set up, where a method checks to see if its dependencies have been configured yet, and, if so, kicks off a bootstrap method.
But that's a really terrible solution! Partly, because that would require every class to have its own Module (which is ridiculous), and it would also pollute my entire codebase with DI-related code.
I'm clearly missing some Guice fundamentals here, otherwise I don't see how Guice could be used in anything other than an app where execution from start to finished is known and controlled. Any code samples are a huge plus! Thanks in advance.
If other code wants to configure your classes without using Guice, it should be able to. However, you should provide a Guice module which binds everything in a reasonable way so that other code (perhaps other modules) can install your module, and then inject the dependencies into their own classes.
Of course, you don't need to expose a module yourself at all - you can leave it up to others to perform all the binding. However, you may wish to provide a module to avoid exposing your implementation details - you can expose a public interface and a public module, but then keep the implementation package-private. The module can bind the interface to the implementation without the caller knowing anything about it.
You may also want to investigate private modules, so that you can bind dependencies that your code needs, without exposing them more widely.
Something, somewhere is going to have to create an injector - but if your code is just "library" code, then it almost certainly shouldn't be you. You shouldn't be performing the injection yourself - you should just be making your code amenable to injection.