I use JPype to build a SOAP client in my python based test platform. However, I need to extend a Java class to make a call like this:
Like
void process(Context parameter)
The type Context here is a class and to give an implementation, I need to extend Context in python using JPype.
class MyContext extends Context { //override the methods}
With JProxy functionality (in JPype), I'm able to "implement" java interfaces.
But I want to extend a class not an interface. Any help is appreciated.
This very much a limitation. JPype does not allow sub-classing.
sourceforge link
Changed the SOAP method to accept an interface in the API contract.
JPype is an effort to allow Python programs full access to Java class libraries. This is achieved not through re-implementing Python, as Jython/JPython has done, but rather through interfacing at the native level in both virtual machines.
Eventually, it should be possible to replace Java with Python in many, though not all, situations. JSP, Servlets, RMI servers and IDE plugins are all good candidates.
Once this integration is achieved, a second phase will be started to separate the Java logic from the Python logic, eventually allowing the bridging technology to be used in other environments, i.e. Ruby, Perl, COM, etc ..
Related
I want to use musicg to analysis audio fingerprint.
But I got following error in musicg library.
IllegalAccessError: class Test
(in unnamed module #0x33f88ab) cannot access class com.sun.media.sound.FFT
(in module java.desktop)
because module java.desktop does not export com.sun.media.sound to unnamed module #0x33f88ab
What should I do?
Environment
Kotlin
JDK 17(downgrade available)
musicg 1.4.2.2
My code
fun main(args: Array<String>) {
FFT(10, 20)
}
got exception in FFT(10, 20)
com.sun and its sub-packages are not part of the public Java API. They implement some standard Java APIs, but you shouldn't refer to them directly. (They're likely to change and/or be renamed or removed between JVM releases, and non-Sun/Oracle JVMs probably won't have them at all.)
In most cases you should access the public API classes (e.g. in javax.sound) instead. (Those may use sun.*/com.sun.*/etc. classes internally as needed, but that's merely an implementation detail.)
In early versions of Java, there was nothing to stop people using those internal implementation classes, and so some developers got into bad habits. But Java 9 added a module system, which restricts access to them. The error message you see is a result of that.
The details are in JEP 260. The intent was that there would be public APIs for all of the critical APIs that were being restricted. However, according to this Oracle forum page, the work wasn't completed, and so there are some internal APIs for which no public equivalent exists yet.
FFT looks like one of those classes that has been overlooked. I can't see a direct replacement for it, I'm afraid. Is there a third-party library you can use? This question gives some options.
I am trying to understand and exercise the plugin pattern, as explained by Martin Fowler.
I can understand in which way it makes use of the separated interface pattern, and that it requires a factory to provide the right implementation of the interface, based on the currently used environment (test, prod, dev, etc). But:
How exactly does the factory read the environment values and decide which object (implementing the IdGenerator interface) to create?
Is the factory a dependency of the domain object (DomainObject)?
Thank you very much.
The goal of the Plugin pattern is to provide a centralized configuration runtime to promote modularity and scalability. The criteria that determines which implementation to select can be the environment, or anything else, like account type, user group, etc. The factory is just one way to create the desired plugin instance based on the selection criteria.
Implementation Selection Criteria
How your factory reads the selection criteria (environment state) depends on your implementation. Some common approaches are:
Command-Line Argument, for example, CLI calls from different CI/CD pipeline stages can pass a dev/staging/production argument
YAML Config Files could be deserialized into an object or parsed
Class Annotations to tag each implementation with an environment
Feature Flags, e.g. SaaS like Launch Darkly
Dependency Injection framework like Spring IoC
Product Line Engineering software like Big Lever
REST Endpoint, e.g. http://localhost/test/order can create a test order object without notifying any customers
HTTP Request Parameter, such as a field in the header or body
Dependency on Factory
Since the DomainObject calls the factory to create an object with the desired implementation, the factory will be a dependency of the domain object. That being said, the modern approach is to use a dependency injection (DI) library (Guice, Dagger) or a framework with built-in DI (Spring DI, .Net Core). In these cases, there still is a dependency on the DI library or framework, but not explicitly on any factory class.
Note: The Plugin design pattern described on pp.499-503 of PEAA was written by Rice and Foemmel, not Martin Fowler.
You will want to get a full PFD of the "Patterns of Enterprise Application Architecture". What is visible on Fowler's site is basically first half-page of any chapter :)
What is being describes is basically the expanded version of idea behind polymorphism.
I don't think "plugin" can actually be described as a "pattern". It's more like result of other design choices.
What you have are .. emm ... "packages", where the main class in each of them implements a third party interface. Each of those packages also have their internal dependencies (other classes or even other libraries), which are used for some specific task. Each package has it's of configuration (which might be added through DIC config) ans each of them get "registered" in your main application.
The mentioning of a factory is almost a red herring, because these days that functionality would be applied using DIC.
I'm trying to test a class that utilizes a repository class that is interfaced with through static methods. The actually repository interacts with a database. I do not want to setup a database in Test, I only to make sure that the repository methods are called. In the RSpec world I would do something like allow(NodeRepository).to receive(:create).and_return(true). Is there a similar feature in MSpec or some other .NET testing tools.
It's not possible to stub static methods in. NET without extra testing tools like TypeMock Isolator. All freely available mocking tools on .NET use dynamic proxies that cannot hook into non-virtual methods (which static methods are).
Well, I'm creating a library and that library needs to take all other libraries and make them work "alike".
For example: Imagine that I have 5 libraries, and all that libraries has the same idea, work to the same case, but they have their own way to work, their own API, and what I need is to make them work using a single API.
What is in my mind is to create a "factory" with a "trust list" inside of the factory that allows the user to choose different libraries to create, and the "factory" look on the "trust list" and if the library really exists, it creates and return the library.
But it can also be made using interfaces, where I can accept only classes that implements an specified interface, where I will have the security of the implementation of the methods that I want, so what this mean? All the libraries needs to implement that interface, implement the methods and make a kindle of wrapper to the library and that way they will work with the same API. The user can create a library using the factory and use the same API to all of them.
I don't know if you understand what I'm trying to explain, but I want to know, based on what I said, what is the best on my situation, "bridge" or "adapter" pattern?
And also, is my idea correct or am I crazy? (The interface and factory thing, and also the bridge and adapter, tell me what you have in mind).
Thank you all in advance.
The Bridge pattern is designed to separate a class's interface from its implementation so you can vary or replace the implementation without changing the client code.
I think you can specify public non-virtual interface, then using Template Method in each of these public functions invoke implementation method.
class Basic {
public:
// Stable, nonvirtual interface.
void A { doA();}
void B { doB();}
//...
private:
// Customization is an implementation detail that may
// or may not directly correspond to the interface.
// Each of these functions might optionally be
// pure virtual
virtual void doA { impl_ -> doA();}
virtual void doB { impl_ -> doB();}
};
These lectures might be useful:
Bridge pattern
Template method
Sounds like adapter to me. You have multiple adapter implementations, which is basic polymorphism and each adapter knows how to adapt to the specific library.
I don't see how the bridge pattern would make any sense here. You would typically use that in places where you use these libraries, but you don't know the specific library implementation yet.
Say FrameworkA consumes a FrameworkA.StandardLogger class for logging. I want to replace the logging library by another one (the SuperLogger class).
To make that possible, there are interfaces: FrameworkA will provide a FrameworkA.Logger interface that other libraries have to implement.
But what if other libraries don't implement that interface? FrameworkA might be a not popular enough framework to make SuperLogger care about its interface.
Possible solutions are:
have a standardized interface (defined by standards like JSR, PSR, ...)
write adapters
What if there is no standardized interface, and you want to avoid the pain of writing useless adapters if classes are compatible?
Couldn't there be another solution to ensure a class meets a contract, but at runtime?
Imagine (very simple implementation in pseudo-code):
namespace FrameworkA;
interface Logger {
void log(message);
}
namespace SuperLoggingLibrary;
class SupperLogger {
void log(message) {
// ...
}
}
SupperLogger is compatible with Logger if only it implemented Logger interface. But instead of having a "hard-dependency" to FrameworkA.Logger, its public "interface" (or signature) could be verified at runtime:
// Something verify that SupperLogger implements Logger at run-time
Logger logger = new SupperLogger();
// setLogger() expect Logger, all works
myFrameworkAConfiguration.setLogger(logger);
In the fake scenario, I expect the Logger logger = new SupperLogger() to fail at run-time if the class is not compatible with the interface, but to succeed if it is.
Would that be a valid thing in OOP? If yes, does it exist in any language? If no, why is it not valid?
My question stands for statically-typed languages (Java, ...) or dynamically typed languages (PHP, ...).
For PHP & al: I know when there is no type-check you can use any object you want even if it doesn't implement the interface, but I'd be interested in something that actually checks that the object complies with the interface.
This is called duck typing, a concept that you will find in Ruby ("it walks like a duck, it quacks like a duck, it must be a duck")
In other dynamically typed languages you can simulate it, for example in PHP with method_exists. In statically typed languages there might be workarounds with reflection, a search for "duck typing +language" will help to find them.
This is more of a statically typed issue than a OOP one. Both Java and Ruby are OO languages, but Java woudlnt allow what you want (as its statically typed) but Ruby would (as its dynamically typed).
From a statically typed language point of view one of the major (if not the major) advantage is knowing at compile time if an assignment is safe and valid. What you're looking for is provided by dynamically typed languages (such as Ruby), but isnt possible in a statically typed language - and this is by design (compile time safety).
You can, but it is ugly, do something like (in Java):
Object objLogger = new SupperLogger();
Logger logger = (Logger)objLogger;
This would pass at compile time but would fail at runtime if the assignment was invalid.
That said, the above is pretty ugly and isnt something I would do - it doesnt give you much and risks an unpleasant (and possibly suprising) exception at runtime.
I guess the best you could hope for in a language like Java would be to abstract the creation away from where you want to use it:
Logger logger = getLogger();
With the internals of getLogger deciding what to return. This however just defers the actual creation to further down - you'll still have to do so in a statically typed safe way.