The manual for OpenJML (http://jmlspecs.sourceforge.net/OpenJMLUserGuide.pdf) intimates that static-checking of Java compilation units can be done programmatically.
Unfortunately, the manual entry for static-checking (Section 5.2.4) is empty, and no specific examples appear to be given for this.
Does anyone know of a simple example?
Unfortunately I cannot help you out for OpenJML, even in the new version of the manual, the section you refer to is empty.
However, you could try other tools such as the KeY program verifier with which you can statically prove your JML annotations correct, either using KeY as a front-end or also programmatically as a back-end. The code at the page referred to, which presents the programmatic usage of the symbolic execution API of KeY may be look quite intimidating at the first glance, but it contains a lot of boilerplate which you might actually not need because the available all options are explained.
For verification (aka "static checking"), you could look into the "key.core.example" package in the current source distribution which should get you started.
As for my knowledge, OpenJML and KeY are the currently only actively maintained tools for statically checking JML annotations. There were others, such as ESC/Java2 and KRAKATOA, but they seem to be outdated. KeY is actively maintained, but does not cover all of the Java language in contrast to OpenJML (maybe there will be LLVM or bytecode versions in the future, since there are corresponding plans, then the situation might improve).
Related
My real question is about how to look up the expectations on the methods (the 'contract' for a method) in Spring. I keep hitting questions, where unless I find some blogger or a stack-overflow that addresses that specific issue, there seems to be no informative documentation. Am I looking the wrong places? Do I need to buy some book?
In the current specific case: I have working looking up a user/password by making my SQL table map to Spring's defaults, but when a user is absent it's hitting a null pointer exception. I see JdbcUserDetailsManager's "void setUserExistsSql( anSQLString)", and I want to know if that sql-string should return a boolean? a null? and what it should be 'named.' Googling is not turning up any usage examples, nor any documentation. The javadocs I'm finding are uncommented. I can guess-and-test, but it seems there should be a better way to look-it-up?
Ok, I've been working with spring since version 1, and many other open-source projects follow the same pattern. Documentation is hard and expensive to produce, and programmers donating their time for free often don't want to write it. Spring though is one of the better projects as far as documentation is concerned.
However, I've always found it necessary to link spring's source code into my project. If you're using maven you can download the sources along with the jars, and tools like IntelliJ (and probably eclipse) will allow you to drill down into the source and to trace its execution with their debuggers.
With these types of projects it is almost always necessary at some point to drill down and read the source, and that's a good thing because the source is always up to date and always exactly describes the behaviour you're trying to use. Documentation on the other hand is often badly written using an informal language (e.g. English) and it can never accurately describe anything, especially if it's being written or read by someone who isn't a native speaker, which is often the case.
So, to answer your question -- look to the source.
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!
I'm developing a system that allows developers to upload custom groovy scripts and freemarker templates.
I can provide a certain level of security at a very high level with the default Java security infrastructure - i.e. prevent code from accessing the filesystem or network, however I have a need to restrict access to specific methods.
My plan was to modify the Groovy and Freemarker runtimes to read Annotations that would either whitelist or blacklist certain methods, however this would force me to maintain a forked version of their code, which is not desirable.
All I essentially need to be able to do is prevent the execution of specific methods when called from Groovy or Freemarker. I've considered a hack that would look at the call stack, but this would be a massive speed hit (and it quite messy).
Does anyone have any other ideas for implementing this?
You can do it by subclassing the GroovyClassLoader and enforcing your constraints within an AST Visitor. THis post explains how to do it: http://hamletdarcy.blogspot.com/2009/01/groovy-compile-time-meta-magic.html
Also, the code referenced there is in the samples folder of Groovy 1.6 installer.
You should have a look at the project groovy-sandbox from kohsuke. Have also a look to his blog post here on this topic and what is solution is addressing: sandboxing, but performance drawback.
OSGi is great for this. You can partition your code into bundles and set exactly what each bundle exposes, and to what other bundles. Would that work for you?
You might also consider the java-sandbox (http://blog.datenwerke.net/p/the-java-sandbox.html) a recently developed library that allows to securely execute untrusted code from within java.
Also see: http://blog.datenwerke.net/2013/06/sandboxing-groovy-with-java-sandbox.html
I have a post-compilation step that manipulates the Java bytecode of generated classes. I'd like to make life as painless as possible for library consumers, so I'm looking at ways I can make this process automatic and (if possible) compiler agnostic.
The Annotation Processing API provides many of the desired features (automatic service discovery; supported by Eclipse). Unfortunately, this is aimed at code generators and doesn't support manipulation of existing artefacts:
The initial inputs to the tool are
considered to be created by the zeroth
round; therefore, attempting to create
a source or class file corresponding
to one of those inputs will result in
a FilerException.
The Decorator pattern recommended by the API is not an option.
I can see how to perform the step with a runtime agent/instrumentation, but this is a worse option than a manual build step as it would require anyone even peripherally touched by the API to configure their JVMs in a non-obvious manner.
Is there a way to plug into or wrap the compiler tool as invoked by javac? Has anyone successfully subverted the annotation processors to manipulate bytecode, no matter what the doc says?
The Groovy compiler is the only bytecode compiler which allows to hook into the compilation process (example: Generate bytecode to support the Singleton pattern)
The Annotation Processing API is not meant to change the code. As you have already found out, all you can do is install a classloader, examine the bytecode at runtime and manipulate it. It's braindead but it works. This follows the general "we're afraid that a developer could try something stupid" theme which you will find throughout Java. There is no way to extend javac. The relevant classes are either private, final or will change with the next version of Java.
Another option is to write annotated Java, for example you write a class "ExampleTpl.java". Then, you use a precompiler which expands the annotations in that file to get "Example.java". In the rest of the code, you use Example and ignore ExampleTpl.
For Eclipse, there is a bug report to automate this step. I'm not aware of any other work in this area.
It can be done.
Take a look at my blog post Roman Numerals, in our Java where an annotation processor is used to rewrite code. Limitation being that it works with Sun's javac only.
I'm working on a Java library and would like to remove some functions from it. My reasons for this is public API and design cleanup. Some objects have setters, but should be immutable, some functionality has been implemented better/cleaner in different methods, etc.
I have marked these methods 'deprecated', and would like to remove them eventually. At the moment I'm thinking about removing these after few sprints (two week development cycles).
Are there any 'best practices' about removing redundant public code?
/JaanusSiim
Set a date and publicize it in the #deprecated tag. The amount of time given to the removal depends on the amount of users your code has, how well connected you are with them and the the reason for the change.
If you have thousands of users and you barely talk to them, the time frame should probably be in the decades range :-)
If your users are your 10 coworkers and you see them daily, the time frame can easily be in the weeks range.
/**
* #deprecated
* This method will be removed after Halloween!
* #see #newLocationForFunctionality
*/
Consider it this way, customer A downloads the latest version of you library file or frame work. He hits compile on this machine and suddenly he see thousands of errors because the member file or function does no longer exist. From this point on, you've given the customer a reason why not to upgrade to your new version and to stay with the old version.
Raymond Chen answers this the best with his blog about win32 API,
Though, our experience in our software house has been, once the API has been written we have to carry the API to the end of the product life cycle. To help users to new versions, we provide backwards compatibility with the old commands in the new framework.
It depends on how often the code is rebuild. For example, if there are 4 applications using the library, and they are rebuild daily, a month is a long enough time to fix the deprecated calls.
Also, if you use the deprecated tag, provide some comment on which code replaces the deprecated call.
Use #deprecated tag. Read the Deprecation of APIs document for more info.
After everyone using the code tells you they have cleaned up on their side, start removing the deprecated code and wait and see if someone complains - then tell them to fix their own code...
Given that this is a library, consider archiving a version with the deprecated functions. Make this version available in both source code and compiled form, as a backup solution for those who haven't modernized their code to your new API. (The binary form is needed, because even you may have trouble compiling the old version in a few years.) Make it clear that this version will not be supported and enhanced. Tag this version with a symbolic symbol in your version control system. Then move forward.
It certainly depends at which scale your API is used and what you promised upfront to your customers.
As described by Vinko Vrsalovic, you should enter a date when they have to expect the abandon of the function.
In production, if it's "just" a matter of getting cleaner code, I tend to leave things in place even past the deprecating date as long as it doesn't break anything.
On the other hand in development I do it immediately, in order to get things sorted out quickly.
You may be interested in examples of how deprecation works in some other projects. For example, here follows what the policy in the Django project for function deprecation is:
A minor release may deprecate certain features from previous releases. If a feature in version A.B is deprecated, it will continue to work in version A.B+1. In version A.B+2, use of the feature will raise a PendingDeprecationWarning but will continue to work. Version A.B+3 will remove the feature entirely.
too bad you are not using .Net :(
The built in Obsolete attribute generates compiler warnings.