I would like to know if anyone has had any luck modifying a Java methods bytecode at a run-time with JVMTI. JVMTI has a getter for a methods bytecode, but from what I understand it does not have any support for replacing the buffer. Any information would be awesome, thanks.
You need to register a class file load hook and retransform the classes you want to change.
Related
in java the Thread.join(long millis) method is not a synchronized method. also you can see this method declaration form this link: https://docs.oracle.com/javase/9/docs/api/java/lang/Thread.html#join-long- but eclipse and idea showing this method as synchronized. you can look at the following picture to what I want to mean. by the way, I am using java 9 in eclipse
how can I fix this problem in eclipse ?
Eclipse and IntelliJ are showing you the actual code, and thus are correct by defintion. The apparent mismatch is because Javadoc doesn't show whether a method is synchronized.
This was a deliberate design decision; see this bug report. Quoting:
It's important for the developer to know whether it's safe for multiple threads
to operate on an object concurrently, However, this synchronization can be
done either in public methods or in private methods, and the Java Platform API
spec should not declare one to be preferred over the other. A licensee should
be able to achieve synchronization internally if they wish.
Therefore, the general description of a class should mention whether the class is thread-safe or not. Individual method descriptions that are exceptions should mention that they are exceptions.
The TL;DR is that synchronized is an implementation detail, not part of the method contract. So Javadoc doesn't show it.
I was reading about code-injection at run-time and there are many tools/APIs available like Javassist, GluonJ and AspectJ which provide features to inject code. However, I did not understand purpose for injecting code at run-time while we can do override behaviors by sub-classing in Java. With Javassist and GluonJ, I can create classes at run-time but why does anyone do that, in the first place? Can anyone please help me to understand the difference and purpose of code injection ?
Code injection is usually used into application that are used to modify/check/trace other software. In Java we usually reffer to this kind of library as Bytecode modification libraries so if you look on the internet you will probably find more information under this name.
Here I listed a couple of examples of big and famous projects that I now are using Bytecode modification into their cores:
Evosuite: this project takes an application in input and generates unit test for it. Code injection is used to explore the desired project and dependencies and traceability
JaCoCO: this project is a tool for Java project. It is supposed to be attached to your application and once you run your JUnit tests it is going to generate a report on the coverage achieved. Obviously here code injection is necessary to trace every method call made during test execution.
Using Java instrumentation, we can access a class that is loaded by the Java classloader from the JVM and modify its bytecode by inserting our custom code, all these done at runtime. We need not worry about security, these are governed by the same security context applicable for Java classes and respective classloaders.
We are able to access some java application using this as they run in same classloader.
Now what we are trying to do is to access eclipse RCP application using java instrumentation but in RCP each bundle has its own classloader and our instrumentation code runs with java application classloader.
when we are accessing it, it is throwing "Workbench has not been created yet" exception whereas the workbench is up and running.(I hope this is because of diffrent classloaders for both of them).
I have tried doing thing from here but to no success.
Is there any way we can work RCP application out with java instrumentation.
When you instrument a class, the references of the inserted code are resolved by the ClassLoader of the modified class. If that class loader does not delegate to the application loader, e.g. because it is rule based and doesn’t know your instrumentation specific classes you can’t enforce delegation.
What you can do:
Use access override to define classes in the scope of the loader of the instrumented class. Since defineClass is final the bundle class loader can’t intercept it. However, the references of these injected classes are again resolved by the bundle loader so you have to add all required instrumentation classes this way.
Since the bundle class loader will do the parent loader delegation for the official Java API classes, you can instrument one of the core Java classes to add a helper method which will be called by the instrumented classes and delegates to your instrumentation classes which must have been added to the boostrap loader
You can use the trick described in the answer you have already linked to put a MethodHandle into the system properties. The instrumented classes can retrieve and invoke it as MethodHandle is a core class which will be correctly resolved by the bundle loader and the underlying method can be invoked without having access to its defining class (assuming that parameter and return types are all either primitive types or core classes).
I am writing a software in java and this inheritance problem always crops up. Funny enough, I don't get problems when i run the program in my IDE (Eclipse Kepler) but once i export it to an executable jar, problem starts. I think I am the only one experiencing this problem because all searches on google show the direct opposite.
My problem is I have an interface named VoteType. This interface is implemented by several concrete classes. I save the concrete implementation to a file using XMLEncoder and retrieve it using XMLDecoder.
But when i try to cast it to the interface it implements VoteType, I get a ClassCastException. What could possibly be causing this?
You are not precise enough to track this down, but I assume that the interface and the object implementing the interface and which is created via XMLDecoder are created by different class loaders. Could that be the reason?
See also this problem: Solution for the ClassCastException due to ClassLoader issue
In my GWT application, I made a control to display/edit a numerical value with an associated unit (for example to convert meters <-> feet).
How could I use the JScience library (jsr-275 implementation) in the client part ?
I try to add it to my project but it didn't compile:
No source code is available for type java.text.ParsePosition
Thanks for your help.
This is not a problem with the JScience library as such.
GWT compiles java to javascript and as such needs access to the java source code. Also, not all of the JDK classes are available in the GWT emulation library, and ParsePosition (indeed all of java.text.*) is one of them...
It is not clear from your stacktrace excerpt whether you have used ParsePosition directly or it is the JScience library that does, but either way you will have to rewrite your code to not use that class on the client side (if possible) or perform the conversion on the server side, where the GWT JRE restrictions do not apply.
Have a look at JRE Emulation Reference for a complete overview of what's available to you.
Cheers and good luck,