Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

possibility to generate only a subset of implementations #26

Closed
h2000 opened this issue Oct 8, 2014 · 5 comments
Closed

possibility to generate only a subset of implementations #26

h2000 opened this issue Oct 8, 2014 · 5 comments

Comments

@h2000
Copy link

h2000 commented Oct 8, 2014

Hello leventov,

At first thanks for the very cool library.

Is it possible to build the library with a subset of primitives e.g. key={int,long} value={int,long,double} to reduce the jar size?

@leventov
Copy link
Owner

leventov commented Oct 8, 2014

Thanks you.

Yes, it is possible, but it is not simple, requires to edit gradle configs and deep understanding of the library structure to fix compilation errors you will face on this way.

As an alternative, your can use the whole lib and shrink your application with ProGuard.

If both ways are unacceptable, I have an idea of another solution for this problem, but it is not yet implemented and not public. Will be publicised not less than in a couple of months, likely even longer time.

@leventov
Copy link
Owner

leventov commented Oct 8, 2014

@h2000 Ok, here is the solution for your specific case, I hope it will help you and people with same questions with different sets of needed specializations:

Note: this is verified only for master at dd2db28 and key={int,long} value={int,long,double} configuration. Also I sacrificed precision of the shrink (hence jar sizes) for simplicity:

$ git clone git@github.com:OpenHFT/Koloboke.git
$ cd Koloboke
$ ./gradlew :buildMeta

Then open lib/build.gradle and add two lines to configure(jpsgTasks) block:

configure(jpsgTasks) {
    // ..prev lines unchanged
    never 'byte|char|short|float'
    exclude 'key=double|obj,value=int|long|double|obj', 'key=int|long,value=obj'
}

Then return to the command line:

$ cd lib
$ ../gradlew buildMain -x findbugsMain -x findbugsTest

Then you have 120 KB koloboke-api-jdk6-7-0.6.2.jar in api/build/libs/ dir and 2.6 MB koloboke-impl-jdk6-7-0.6.2.jar in impl/build/libs/.

@h2000
Copy link
Author

h2000 commented Oct 8, 2014

Very cool, I'll try it tomorrow morning first thing!!
:)

@h2000
Copy link
Author

h2000 commented Oct 8, 2014

Could not wait ;). It compiles successfully. I used:
../gradlew buildMain -x findbugsMain -x findbugsTest -x javadoc

If javadoc is activitated, it failed with:

:lib:api:javadoc
HOME/hft-java/Koloboke/lib/api/src/main/java/net/openhft/koloboke/collect/Equivalence.java:308: error: reference not found
     * It is needed because, for example, {@link net.openhft.koloboke.collect.map.ObjObjMap}'s
                                                 ^
HOME/hft-java/Koloboke/lib/api/build/generated-src/jpsg/main/java/net/openhft/koloboke/function/DoubleBinaryOperator.java:28: error: reference not found
 * in {@link net.openhft.koloboke.collect.map.ObjDoubleMap#merge(Object, double, DoubleBinaryOperator)}
             ^
HOME/hft-java/Koloboke/lib/api/build/generated-src/jpsg/main/java/net/openhft/koloboke/function/DoubleDoubleToDoubleFunction.java:32: error: reference not found
 * in {@link net.openhft.koloboke.collect.map.DoubleDoubleMap#compute(double, DoubleDoubleToDoubleFunction)}
             ^
HOME/hft-java/Koloboke/lib/api/build/generated-src/jpsg/main/java/net/openhft/koloboke/function/IntBinaryOperator.java:28: error: reference not found
 * in {@link net.openhft.koloboke.collect.map.ObjIntMap#merge(Object, int, IntBinaryOperator)}
             ^
HOME/hft-java/Koloboke/lib/api/build/generated-src/jpsg/main/java/net/openhft/koloboke/function/LongBinaryOperator.java:28: error: reference not found
 * in {@link net.openhft.koloboke.collect.map.ObjLongMap#merge(Object, long, LongBinaryOperator)}
             ^
5 errors
:lib:api:javadoc FAILED

@leventov
Copy link
Owner

leventov commented Oct 8, 2014

@h2000 Good catch. I haven't experienced that probably because I use Java 6 javadoc executable, which treat such problems as warnings by default, Java 8 javadoc became less tolerant by default. If you need Javadocs generated, configure javadoc { failOnError = false } in libs/api/build.gradle file.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants