Currently I'm trying to implement OSGI Version Ranges (for a different topic, but I like the way they define version ranges). However I'm having a hard time to find the specific Definition of a Version Range in OSGI.
Unfortunately, the OSGI API does contain a Version class but not a VersionRange class. It seems like all OSGI Containers come up with their own interpretation of the (somewhat unfindable) Version Range definition.
Therefore I have several questions:
If I used versionRange=1.4.0, would this map to Version >= 1.4.0?
Is this a valid version range: versionRange=[1.0.0,0]: I'd say yes (version 1.0.0 up to any version), Eclipse implementation accepts it as a version but does not handle it correctly.
Would this be a valid versionRange aswell: versionRange=[1.0.0,0)?
Where is the actual source of truth for all those questions? I seem to be unable to find it.
So, to answer your concrete questions in order:
If I used versionRange=1.4.0, would this map to Version >= 1.4.0?
Yes. This is exactly the way spec says it should be interpreted (see below).
Is this a valid version range: versionRange=[1.0.0,0]
Yes, it is a valid range, but it will not evaluate to what you seem to be expecting.
It effectively evaluates to an empty set of versions, so no version will match this expression.
Would this be a valid versionRange aswell: versionRange=[1.0.0,0)?
Same as above -- it is a valid version range, but it will evaluate to an empty set.
Where is the actual source of truth for all those questions? I seem to be unable to find it
The specs are available on OSGi Alliance's home page from:
http://www.osgi.org/Release4/Download (for R4 specs)
Below is an excerpt from the OSGi R4 core specification that covers the version ranges:
Version Ranges
A version range describes a range of versions using a mathematical interval notation. See [31] Mathematical Convention for Interval Notation.
The syntax of a version range is:
version-range ::= interval | atleast
interval ::= ( '[' | '(' ) floor ',' ceiling ( ']' | ')' )
atleast ::= version
floor ::= version
ceiling ::= version
If a version range is specified as a single version, it must be interpreted as the range [version,∞). The default for a non-specified version range is 0, which maps to [0.0.0,∞).
Note that the use of a comma in the version range requires it to be enclosed in double quotes. For example:
Import-Package: com.acme.foo;version="[1.23, 2)",
com.acme.bar;version="[4.0, 5.0)"
In the following table, for each specified range in the left-hand column, a version x is considered to be a member of the range if the predicate in the right-hand column is true.
[1.2.3, 4.5.6) | 1.2.3 <= x < 4.5.6
[1.2.3, 4.5.6] | 1.2.3 <= x <= 4.5.6
(1.2.3, 4.5.6) | 1.2.3 < x < 4.5.6
(1.2.3, 4.5.6] | 1.2.3 < x <= 4.5.6
1.2.3 | 1.2.3 <= x
Version ranges are precisely defined in section 3.2.6 of the OSGi Core Specification. You're correct that there is no VersionRange class in the current API, though there will be in the next specification release.
OSGi framework implementations do not come up with their own interpretation of ranges; if you find a case where a specific framework interprets a range differently from section 3.2.6 of the Core Spec then please raise a bug against that framework.
To address your specific questions:
Yes, version=1.4.0 on an Import-Package (or bundle-version=1.4.0 on a Require-Bundle) does map informally to "version >= 1.4.0".
I believe that both of these version ranges are valid, BUT they will never match any version. E.g. first example will match only version x where x >= 1.0.0 and x<=0. There is no value of x that can satisfy both of these requirements. So it sounds like Eclipse is behaving correctly... it should successfully parse the range string but never return any results.
As already mentioned, the "source for truth" is section 3.2.6 of the OSGi Core Specification.... page 29 if you are reading the R4.3 version of the document.
1) versionRange=1.4.0 is equivalent to [1.4.0, infinity)
2) I'd say it isn't valid, since the floor should be lower than the ceiling.
3) The next OSGi spec will define a VersionRange class, I believe.
See RFC 175 in http://www.osgi.org/Download/File?url=/download/osgi-early-draft-2011-09.pdf. It defines an update to the version definition and also introduces a VersionRange class.
Version ranges can be empty such as your example in the second bullet. An empty version range includes no versions.
Related
I wish to check if a user's Java version is at least 1.8.0_171. I mean that specific iteration or higher, meaning 1.8.0_151, for instance, would not work.
I planned to originally use org.apache.commons.lang3.SystemUtils' isJavaVersionAtLeast(JavaVersion requiredVersion) method, but it seems that you cannot specify the iteration number.
Based on this and Java's changing way of representing version numbers in Java (e.g. 1.8 then 9), what is the best way to check the Java version of the user in the Java program?
Edit:
This was marked as a duplicate of this question; however, I think it is different in that it asks how to compare the java version with a certain version given the changes in format of how the java version is shown.
Even with the versioning change, I think the solution is still as simple as using the following boolean expression:
"1.8.0_171".compareTo(System.getProperty("java.version")) <= 0
If the user's java.version property is any less than 1.8.0_171, then the above expression returns false, and vice versa. This works for using "9" or "10" in place of the java.version property as well.
Pretty simple question: I often forget that using the less than and greater than symbols in Javadoc doesn't work without using the either a literal block or </>, since they're treated as formatting tags. This subsequently causes my Jitpack build to fail. I use IntelliJ IDEA as my main Java IDE, which appears to give no warning when I use angle brackets in JavaDoc; Is there a way to check against improper usage of these symbols?
According to Serge Baranov from JetBrain's support team:
It's a known limitation, please vote for https://youtrack.jetbrains.com/v2/issue/IDEA-165488.
The issue's description reads as expected:
Idea's 'HTML problems in Javadoc (DocLint)' does not report any
problems in the following javadoc:
/**
* a < b > c
*/
void test();
However, javadoc generation will fail in this case:
Test.java:5: error: malformed HTML
* a < b > c
^
Test.java:5: error: bad use of '>'
* a < b > c
^
Usually this problem is noticed only at the javadoc generation phase
of Maven build process and that's rather inconvenient.
Also, it would be great to have an intention to escape such symbols in
javadoc as > / <.
However, as of this posting, the bug has no special priority, spent time, or verification (though it has been triaged.) Developer/SO user Roman Shevchenko appears to be assigned to the issue. I wouldn't expect a fix any time particularly soon, given this isn't exactly a huge issue.
While testing the search api locally (Java SDK - 1.9.6) i'm getting unexpected results doing equality and range checks against numbers which are small.
For example, if i index three documents with the following fields:
numeric: 0.0011
numeric: 0.0022
numeric: 0.0033
I get the following results for the following queries:
numeric: 0.0033 -> []
numeric= 0.0033 -> []
numeric>= 0.0033 -> []
numeric < 0.0033 -> [document1, document2, document3]
numeric < 0.0022 -> [document1, document2]
numeric < 0.0021 -> [document1, document2]
numeric < 0.002 -> [document1]
I assume there is something in the implementation which indexes or runs queries against numbers at a granularity other than exact? Should I expect these
results to be reflected in the real appengine environments? What precision can I rely on?
The main challenge i am trying to solve is the ability to store numbers which fall outside of the SearchApiLimits.MINIMUM_NUMBER_VALUE and SearchApiLimits.MAXIMUM_NUMBER_VALUE and still operate on them. At the moment, shifting them by moving the decimal place is the only option I have been able to come up. Are there any alternatives that allow good control over how much precision is lost in the translation first to a double (the type in the java api), and then whatever is happening under the hood?
For the first part of the question,
I have not been able to reproduce your results with the newest version of the API. If you can reproduce your results in version 1.9.7 then post some code and I'll take a look at it again. The dev server and the production server should behave the same, and if not, then it is a bug.
One alternative to get around the limits is by not storing them as numbers but as atoms. But then you won't be able to apply the <,>,<=,..., operators only equality.
It should be noted that the local FTS is not the same code as the App Engine server. I think it's lucene or something.
The documentation at this page states that
Any value may be set using the corresponding set<Value> method.
However, I am not sure how to interpret this statement. I have tried the following but none of them compile, and nor did I expect them to.
certificate.set3();
certificate.setThree();
serverCertificate.set<3>();
What is the correct method call to set the version number explicitly?
You can not. It explicitely says:
This class represents a X.509 version 3 certificate, as specified by
ISO/IEC and ANSI X9.
Update:
Seems that you can not actually set the version. It "configures" itself the proper version depending on which extensions you use. In V1 there were no extensions and in V2 just few.
The version number per default is set to 1 indicating a Version 1
certificate. When including subjectUniqueID or issuerUniqueID, the
version automatically will be set to 2, and when adding an extension
increased to 3.
I've downloaded Sigar API ( http://support.hyperic.com/display/SIGAR/Home ) and would like to use it in a project to get information about different processes which are running.
My problem is that I can't really find some useful code snippets to learn from and the javadoc from their website isn't of much help, because I don't know what I should be looking for.
Do you have any ideea where I could find more information?
To find the pid (which is needed to find out information about a certain process), you can use a ProcessFinder.
The method to find a single process pid is findSingleProcess(String expression). Example:
Sigar sigar=new Sigar();
ProcessFinder find=new ProcessFinder(sigar);
long pid=find.findSingleProcess("Exe.Name.ct=explorer");
ProcMem memory=new ProcMem();
memory.gather(sigar, pid);
System.out.println(Long.toString(memory.getSize()));
The expression syntax is this:
Class.Attribute.operator=value
Where:
Class is the name of the Sigar class minus the Proc prefix.
Attribute is an attribute of the given Class, index into an array or key in a Map class.
operator is one of the following for String values:
eq - Equal to value
ne - Not Equal to value
ew - Ends with value
sw - Starts with value
ct - Contains value (substring)
re - Regular expression value matches
operator is one of the following for numeric values:
eq - Equal to value
ne - Not Equal to value
gt - Greater than value
ge - Greater than or equal value
lt - Less than value
le - Less than or equal value
More info here: http://support.hyperic.com/display/SIGAR/PTQL
If you are using Windows 7 try doing something
likefindSingleProcess("State.Name.ct=explorer");
In their latest package, they give a lot of usage examples under bindings\java\examples. Check them out.
The hyperic site seems to be gone, but this https://layer4.fr/blog/2016/10/10/os-monitoring-with-java/ tells you how to hook Sigar to Java. You do need to put the sigar-amd64-winnt.dll file somewhere on the DLL path (e.g. C:\Windows)