Does JMH support Tycho?

[Aleksey Shipilev]

(continuing to churn the backlog)

Thanks for doing the sample OSGi projects! In order for us OpenJDK folks
to accept your code, we need signed Oracle Contribution Agreement [1]
from your side -- that will also give you credit in OpenJDK :)

I have a few questions:

 a) So, should we ship the jmh-core-osgi module which will use Felix to
generate the OSGi wrapper bundle, then you can use JMH with OSGi? If the
answer is "yes", then we can use your sample as the basis for that.

 b) Do we *have* to have binary libs in lib/ for this bundle magic to
work? We can not commit binary files into OpenJDK repos, so this might
be a deal breaker.

 c) Do we need to do any additional deployment steps, or just publishing
the jmh-core-osgi in Maven Central is enough for OSGi-enabled users to
pick it up?

Thanks,
-Aleksey.

[1] http://openjdk.java.net/contribute/

On 04/07/2014 07:09 PM, Bureck, Max wrote:
> Hey,
> 
> Creating a wrapper OSGi bundle for JMH is pretty simple :)
> Here is a project that can do this:
> http://www.fokus.fraunhofer.de/files/file.php?h=R3aad70ac803ebf6e933c7e7d5c8a508d
> 
> Cheers,
> Max
> 
> -----Original Message-----
> From: Bureck, Max 
> Sent: Monday, April 07, 2014 4:23 PM
> To: 'Aleksey Shipilev'; jmh-dev at openjdk.java.net
> Subject: RE: Does JMH support Tycho?
> 
> Hi,
> 
> Phew, this seems to be way more tricky than expected. 
> 
> First some general information:
> 
> For the tests I am running I don't necessarily need an OSGi framework running. I don't need to benchmark code that uses the OSGi service layer and none of the classloader magic of OSGi is needed (e.g. there are no cases in which the same bundle in different versions is needed by different parts of the code to be benchmarked). So, in my simple cases all dependencies can be just thrown on the class path and the code runs "standalone" without the OSGi framework.
> 
> But for more sophisticated code making use of OSGi features, an OSGi environment probably has to be started, the benchmark bundle has to be loaded with its dependencies and the benchmark has to be started. I am not sure what would be the best way of interaction. One way to do this would be to do all the setup on start of the benchmark. Or maybe the benchmark could itself be an OSGi bundle with an activator that starts the benchmark as soon as the bundle is activated. In this case the OSGi dependencies do not have to be part of the benchmark bundle itself. This second option should be easier to implement, but is probably cumbersome to use if there is no IDE support or external helper tool for simple startup.
> 
> Now to the example project I promised:
> 
> In my small sample project I could not reproduce the correct build anymore. I tried combining configuration a lot, but no luck :( Maybe this has to do with non-deterministic (or project-structure dependent) order of steps, or order of application of configuration, or whatever.
> Well, here you can find a very simple sample Tycho based project with one OSGi dependency (which will be downloaded from the Eclipse Kepler update site during build):
> 
> http://www.fokus.fraunhofer.de/files/file.php?h=R4b971a8efde43617ef7b477cf4a8a420
> 
> Let me know if you have questions regarding the project.
> 
> Be aware that this project includes the binaries of JMH and its dependencies to make the build work. Otherwise, Tycho would need OSGi versions of the dependencies. To make this work, we would need an OSGi-ified version of JMH. The dependencies may come from Maven repositories, but they have to be OSGi bundles.
> 
> There are two ways of achieving this:
> 1. Build a wrapper project, containing all dependent libraries. Have the libraries on the bundle classpath and export the JMH packages from the bundle as public API.
> 2. Make JMH Jars OSGi bundles directly.
> 
> I tried if I could make the 2nd option possible. It worked, but it has one problem: The jopt dependency is no OSGi bundle, so it does have to be included in the JMH bundle.
> 
> To build JMH Core as an OSGi bundle, I downloaded the head revision of JMH and adjusted the build script of jmh-core, using the Apache Felix Bundle for Maven:
> http://felix.apache.org/site/apache-felix-maven-bundle-plugin-bnd.html
> 
> I changed the packaging to "bundle" and added the following plugin-section:
> 
> <plugin>
> 	<groupId>org.apache.felix</groupId>
> 	<artifactId>maven-bundle-plugin</artifactId>
> 	<version>2.4.0</version>
> 	<extensions>true</extensions>
> 	<configuration>
> 		<instructions>
> 			<Import-Package>org.apache.commons.math3.*,!sun.management,!sun.management.counter,!javax.annotation,!joptsimple,!sun.misc</Import-Package>
> 			<Embed-Dependency>jopt-simple;scope=runtime|compile;optional=false</Embed-Dependency>
> 		</instructions>
> 		<unpackBundle>true</unpackBundle>
> 	</configuration>
> </plugin>
> 
> I can also try to come up with a separate OSGi wrapper-project (option 1.). This would include JMH with dependencies as libraries and export the JMH packages from the bundle. Maybe, with some configuration magic, this could just include JMH and jopt-simple declaring dependencies to core math (which already is an OSGi bundle).
>  
> Cheers,
> Max
> 
> -----Original Message-----
> From: Aleksey Shipilev [mailto:aleksey.shipilev at oracle.com]
> Sent: Wednesday, April 02, 2014 5:32 PM
> To: Bureck, Max; jmh-dev at openjdk.java.net
> Subject: Re: Does JMH support Tycho?
> 
> On 04/02/2014 06:11 PM, Bureck, Max wrote:
>> 1) It seems that the dependencies are available on the classpath 
>> during compilation.
> 
> Ok, good.
> 
>> 2) I am not sure how dependency resolving is done by the Tycho build, 
>> but I guess it is needed, because you need not only to find dependent 
>> classes for compilation, but also need to respect the package 
>> visibility rules (only packages exported from one bundle can be 
>> imported by other bundles/made visible to other bundles).
> 
> Understood. You probably need to initialize OSGi engine before the JMH run then?
> 
>> I will create a simple sample project that demonstrates the problem 
>> and come back to you.
> 
> It would be very cool, let's do that.
> 
>> Please refrain from puns about Eclipse needing performance benchmarks 
>> badly ;-)
> 
> I will try to refrain from the pun about Eclipse needing performance benchmarks badly on this list.
> 
> Thanks,
> -Aleksey.
>