As the title suggests, I need to implement Coarsened Exact Matching inside a Java application. I found out that Renjin embeds this library but I cannot figure out how to use it in my Java app, i.e. how to install it, invoke matching methods etc...
Any idea or example? Thx a lot.
I added tcltk stubs to Renjin today, so with the latest version you can now use the cem package.
There are no plans to add true support for Tcl/Tk graphical user interfaces, so any functions from cem that actually rely on tcltk will fail, but all of the actual computation should work.
Read better:
This package cannot yet be used with Renjin it depends on other packages which are not available: tcltk
The reason is that TCL/TK requires native code, which is a pain to use in Java. Because nobody did write that code yet it cannot be used yet.
Related
I have created a library which supports an application, however in the newest version of the application the developer has changed the structure without changing the class names.
So version 1 of the application has classX in package A but version 2 has classX in package B. How can I develop my library in a way which allows supporting both of these in the same build?
Edit: My library is dependent on the application, not the other way around.
That is a bad decision, if you still want to make it work you need to provide skeleton classes with old structure and delegate calls to new version of class but it would get very dirty
better to not provide backward compatibility if you are firm with the renaming decision
Short answer: You can't.
Real answer: Your library should be able to exist independently of any application that uses it. The purpose of a library is to provide a set of reusable, modular code that you can use in any application. If your library is directly dependent on application classes, then it seems like a redesign should be seriously considered, as your dependencies are backwards. For example, have A.classX and B.classX both implement some interface (or extend some class) that your library provides, then have the application pass instances of those objects, or Class's for those objects, to the library.
If your "library" can't be designed this way then consider integrating it into application code, making it a direct part of the application, and come up with a better team workflow for you, the other developer, and others to work on the same project together.
Quick fix answer: Do not provide backward compatibility, as Jigar Joshi states in his answer.
Bad answer: You could hack a fragile solution together with reflection if you really had to. But please note that the "real answer" is going to last in the long run. You are already seeing the issues with the design you have currently chosen (hence your question), and a reflection based solution isn't going to prevent that from happening again (or even be reliable).
I would like to mark usage of certain methods provide by the JRE as deprecated. How do I do this?
You can't. Only code within your control can have the #Deprecated annotation added. Any attempt to reverse engineer the bytecode will result in a non-portable JRE. This is contrary to Java's write once, run anywhere methodology.
you can't deprecate JRE methods, but you can add warnings or even compile errors to your build system i.e. using AspectJ or forbid the use of given methods in the IDE.
For example in Eclipse:
Go to Project properties -->Java Compiler --> Errors Warnings, Then enable project specific settings, Expand Deprecated and restrited APIs category
"Forbidden reference (acess rule)"
Obviously you could instrument or override the class adding #Deprecated annotation, but it's not a clean solution.
Add such restrictions to your coding guidelines, and enforce as part of your code review process.
You only can do it, if and only if you are building your own JRE! In that case just add #Deprecated above the corresponding code block! But if you are using Oracle's JRE, you are no where to do so!
In what context? Do you mean you want to be able to easily configure your IDE to inhibit use of certain API? Or are you trying to dictate to the world what APIs you prohibit? Or are you trying to do something at runtime?
If the first case, Eclipse, and I assume other IDEs, allow you to mark any API as forbidden, discouraged, or accessible at the package or class level.
If you mean the second, you can't, of course. That would be silly.
If you are trying to prohibit certain methods from being called at runtime, you can configure a security policy to prevent code loaded from specified locations from being able to call specific methods that check with the SecurityManager, if one is installed.
You can compile your own version of the class and add it to the boot class path or lib/ext directory. http://docs.oracle.com/javase/tutorial/ext/basics/install.html This will change the JDK and the JRE.
In fact you can remove it for compiling and your program won't compile if it is used.
Snihalani: Just so that I get this straight ...
You want to 'deprecate methods in the JRE' in order to 'Making sure people don't use java's implementation and use my implementation from now on.' ?
First of all: you can't change anything in the JRE, neither are you allowed to, it's property of Oracle. Uou might be able to change something locally if you want to go through the trouble, but that 'll just be in your local JRE, not in the ones that can be downloaded from the Oracle webpage.
Next to that, nobody has your implementation, so how would we be able to use it anyway? The implementations provided by Oracle do exactly what they should do, and when a flaw/bug/... is found it'll be corrected or replaced by a new method (at which point the original method becomes deprecated).
But, what mostly worries me, is that you would go and change implementations with something you came up with. Reminds me quite lot of phishing and such techniques, having us run your code, without knowing what it does, without even knowing we are running your code. After all, if you would have access to the original code and "build" the JRE, what's to stop you from altering the code in the original method?
Deprecated is a way for the author to say:
"Yup ... I did this in the past, but it seems that there are problems with the method.
just in order not to change the behaviour of existing applications using this method, I will not change this method, rather mark it as deprecated, and add a method that solves this problem".
You are not the author, so it isn't up to you to decide whether or not the methods work the way they should anyway.
Is there a way to implement interface which doesn't exist in Android SDK version that I'm using for development but exists in later Android versions through reflection or somehow else?
I need to implement interface "WebViewClassic.TitleBarDelegate" which (as well as class WebViewClassic) appeared in API-16, but don't exist in earlier API's.
How can it be done without upgrading development to API-16?
It must be implemented by my custom class derivative from WebView, because WebView implementation invokes methods of this interface.
So alternatively maybe some trick can be made to substitute one method to another in runtime at the moment of invocation?
Or maybe finally appeared some means to make releases for different API versions in one package?
Any suggestions would be great.
Maybe you can take relevant files from the Android Sources and put them into your project? I've seen this for some classes when someone needed to tweak those classes a little. Not sure about your case though.
We have been using Google collections in the production for several months. We would like to start using guava for additional functions. However, I'm afraid to bring guava into our product stack b/c some developers may start to use 'beta' classes.
We have various unit-tests in our code but at this point, I prefer not to include 'beta' class b/c it is subject to change in the future.
Is there any easy way to do detect if the project includes any 'beta' guava classes?
Overstock.com recently released a Findbugs plugin that flags usage of #Beta classes, methods, or fields.
In your unit tests, setup an aspect to log and/or fail when any of the beta classes (or any unwelcome class) is used.
Apparently Google Guava has an #Beta annotation which indicates which classes or methods you don't want to use.
Unfortunalty this annotation is #Retention(value=CLASS) which I've never used but since it's supposed to be kept in .class files it might mean that it will still be availiable to Class.getDeclaredAnnotations(). If it's not you will have to use CGLIB or similar bytecode level library to find it.
Given that you might want to instrument your CI application or add a checking classloader to your app to detect usage of beta API
If you're using eclipse, access rules are one option. You'd get a compile-time error whenever you are importing or otherwise using a restricted class.
Here is a list of Guava's Beta Classes.You will have to tell other developers to check this link before using a guava class.
I was thinking you could probably use reflection for that if you had a list of beta classes, which you can using Gili's link. Then it gets pretty easy - just see this answer:
Can you find all classes in a package using reflection?
I'd probably just put that in a unit test and have the unit test fail if it sees a class you don't like.
I have a scenario where I have code written against version 1 of a library but I want to ship version 2 of the library instead. The code has shipped and is therefore not changeable. I'm concerned that it might try to access classes or members of the library that existed in v1 but have been removed in v2.
I figured it would be possible to write a tool to do a simple check to see if the code will link against the newer version of the library. I appreciate that the code may still be very broken even if the code links. I am thinking about this from the other side - if the code won't link then I can be sure there is a problem.
As far as I can see, I need to run through the bytecode checking for references, method calls and field accesses to library classes then use reflection to check whether the class/member exists.
I have three-fold question:
(1) Does such a tool exist already?
(2) I have a niggling feeling it is much more complicated that I imagine and that I have missed something major - is that the case?
(3) Do you know of a handy library that would allow me to inspect the bytecode such that I can find the method calls, references etc.?
Thanks!
I think that Clirr - a binary compatibility checker - can help here:
Clirr is a tool that checks Java libraries for binary and source compatibility with older releases. Basically you give it two sets of jar files and Clirr dumps out a list of changes in the public api. The Clirr Ant task can be configured to break the build if it detects incompatible api changes. In a continuous integration process Clirr can automatically prevent accidental introduction of binary or source compatibility problems.
Changing the library in your IDE will result in all possible compile-time errors.
You don't need anything else, unless your code uses another library, which in turn uses the updated library.
Be especially wary of Spring configuration files. Class names are configured as text and don't show up as missing until runtime.
If you have access to the source code, you could just compile source against the new library. If it doesn't compile, you have definitely a problem. If it compiles you may still have a problem if the program uses reflection, some kind of IoC stuff like Spring etc.
If you have unit tests, then you may have a better change catch any linking errors.
If you have only have a .class file of the program, then I don't know any tools that would help besides decomplining class file to source and compiling source again against the new library, but that doesn't sound too healthy.
The checks you mentioned are done by the JVM/Java class loader, see e.g. Linking of Classes and Interfaces.
So "attempting to link" can be simply achieved by trying to run the application. Of course you could hoist the checks to run them yourself on your collection of .class/.jar files. I guess a bunch of 3rd party byte code manipulators like BCEL will also do similar checks for you.
I notice that you mention reflection in the tags. If you load classes/invoke methods through reflection, there's no way to analyse this in general.
Good luck!