- Notifications
You must be signed in to change notification settings - Fork1.2k
ArmoredOutputStream showing v@RELEASE_NAME@#1853
Uh oh!
There was an error while loading.Please reload this page.
Uh oh!
There was an error while loading.Please reload this page.
-
How can I get rid of the v@RELEASE_NAME@ in this code or is this a bug? I'm using bcpg-jdk18on, bcprov-jdk18on, bcutil-jdk18on release 1.78.1 Do I need to explicitly set the version? Shouldn't it infer from the maven version? |
BetaWas this translation helpful?Give feedback.
All reactions
Replies: 1 comment 5 replies
Uh oh!
There was an error while loading.Please reload this page.
Uh oh!
There was an error while loading.Please reload this page.
-
Yep, this is a bug - the 1.8 and later build is now built exclusively by gradle, the main reason being we need to use the OSGI plugin to support OSGI multi-release files. I'll admit it's a bit neater as well... anyway, seems this particular item got missed. Have a look athttps://downloads.bouncycastle.org/betas the version of bcpg should now report the correct string if you run:
Note: the trend now is to not report version information in the files directly as there are concerns the information makes it too easy to pick out vulnerable files. There is also an ArmoredOutputStream.Builder class which provides more control over the headers (this was added in 1.76 so you should find it works for you now). Any questions please let me know. |
BetaWas this translation helpful?Give feedback.
All reactions
-
Onebig problem with your Gradle build is that it insists on havingall the JDKs installed. Since my system is sane, it only has JDK-21 (and JDK-11 for truly weird cases). Until that (i.e., insistence on having JDK-8) issue is resolved, I am stuck with Ant build process. Suspect there are many users in the same boat as me. |
BetaWas this translation helpful?Give feedback.
All reactions
-
Unfortunately "sourceCompatibility = 1.8" only means code level - it's still possible to call API that only exist in later JVMs if you do not ensure the boot class path is correct, although looking at all the changes required for OSGi, I think we may need to check that that is still always the case. I haven't tried this, but I can't think of any reason the gradle build would not work if everything was set to point at Java 21 - Java 21 will produce byte code back to Java 8 and in your case the source code is already vetted (assuming you're not making any changes) so the bootclass path problem should not occur. |
BetaWas this translation helpful?Give feedback.
All reactions
-
Yes, but only when you use "-source=1.8" (and/or "-target=1.8"). If you use the "--release=8" parameter instead when calling javac (available since Java 9) you can effectively prevent your code from using newer API methods that aren't available in earlier ones :-) |
BetaWas this translation helpful?Give feedback.
All reactions
Uh oh!
There was an error while loading.Please reload this page.
Uh oh!
There was an error while loading.Please reload this page.
-
Thanks. Cool! Will investigate. |
BetaWas this translation helpful?Give feedback.
All reactions
-
Okay, this is a bit of a divergence from the actual topic, but we've just pushed a new set of gradle files which will hopefully simplify things a bit. |
BetaWas this translation helpful?Give feedback.