Develop Reference

Check if a Java version is greater than a certain iteration in Java?

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.

how to set TOS flag using websockets in java

i want to use websockets in my java application, but have to specify the TOS flag. Is there a common way to do this properly? how do i configure socket settings typically?
thanks in advance!

This can be done with the setTrafficClass(int) method from the java.net.Socket class. The JavaDoc has a good description of the allowed parameter values and what it refers to:
For Internet Protocol v4 the value consists of an octet with precedence and TOS fields as detailed in RFC 1349. The TOS field is bitset created by bitwise-or'ing values such the following :-
• IPTOS_LOWCOST (0x02)
• IPTOS_RELIABILITY (0x04)
• IPTOS_THROUGHPUT (0x08)
• IPTOS_LOWDELAY (0x10)
The last low order bit is always ignored as this corresponds to the MBZ (must be zero) bit.

Difference between Locale.getAvailableLocale and assetManager.getLocale in android?

Is there any difference or are they same (except the format they return) ?

After a quick Google, I've found this:
http://androiddevevelopmentnotes.blogspot.com/2011/08/how-to-find-available-locales-in-andoid.html
Locale.getAvailableLocales() - returns a pretty large number of
Locales.
Activity.getAssets().getLocales() - returns the Locales that the
AssetManager contains data for, which is typically a lot less than
what Locale.getAvailableLocales() returns.

From the doc:
getAvailableLocales
Returns an array of all installed locales. The returned array represents the union of locales supported by the Java runtime environment and by installed LocaleServiceProvider implementations. It must contain at least a Locale instance equal to Locale.US.
and
getLocales
Get the locales that this asset manager contains data for.
So the first is returning all locales available on the system and the second one is returning locales "backed by assets"

Maximum Length of Android versionName / versionCode (Manifest)

I am trying to find out the maximum length of both the android:versionName and android:versionCode attributes of the android manifest file?
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
package="com.xxxx.xxxx"
android:versionCode="185" <--- THIS ATTRIBUTE
android:versionName="1.0.185"> <--- AND THIS ATTRIBUTE
Is there a maximum value or will it pretty much allow anything if there is no maximum are there certain rules in place?

Based on android documentation:
android:versionCode — An integer value that represents the version of the application code, relative to other versions.
Edit - Android documentation explicitly states -
Warning: The greatest possible value for android:versionCode is MAXINT
(2147483647). However, if you upload an app with this value, your app
can't ever be updated.
Based on oracle documentation:
By default, the int data type is a 32-bit signed two's complement integer, which has a minimum value of -2^31 and a maximum value of (2^31)-1. In Java SE 8 and later, you can use the int data type to represent an unsigned 32-bit integer, which has a minimum value of 0 and a maximum value of (2^32)-1.
android:versionName — A string value that represents the release version of the application code, as it should be shown to users.
Regarding String max length, this SO question may help you.

Update 08/11/2016 (UTC):
The docs has been updated. Not the old MAX_INT value or the 2000000000.
Warning: The greatest value Google Play allows for versionCode is 2100000000.
Cross-post for visibility here.
It seems there was a recent change in Google, making the maximum versionCode up to 2000000000 only.
Reference post: Google Play Developer Console error: The version code of your APK is high and you risk not being able to update your APK
PS: For those who are planning to provide reference to the official documentation where the mentioned max value is 2147483647, please read the answer first in the post I referenced. It mentions that as of current date (08/10/2016), its still not updated.

Let's look at the website.
versionCode is an integer
versionName is a String
android:versionCode — An integer value that represents the version of the application code, relative to other versions.
The value is an integer so that other applications can programmatically evaluate it, for example to check an upgrade or downgrade relationship. You can set the value to any integer you want, however you should make sure that each successive release of your application uses a greater value. The system does not enforce this behavior, but increasing the value with successive releases is normative.
Typically, you would release the first version of your application with versionCode set to 1, then monotonically increase the value with each release, regardless whether the release constitutes a major or minor release. This means that the android:versionCode value does not necessarily have a strong resemblance to the application release version that is visible to the user (see android:versionName, below). Applications and publishing services should not display this version value to users.
So the version code is an integer. It doesn't specify the signage or the number of bits, but we can assume that it can't be negative, and guess 32 bits. So we can guess that it can be between 0 and 2^32. Java by default has signed 32 bit integers, so that would provide values from -2^31 to 2^31. Of course, if it was a 64 bit integer, then it would be between 0 and 2^64.
android:versionName — A string value that represents the release version of the application code, as it should be shown to users.
The value is a string so that you can describe the application version as a .. string, or as any other type of absolute or relative version identifier.
As with android:versionCode, the system does not use this value for any internal purpose, other than to enable applications to display it to users. Publishing services may also extract the android:versionName value for display to users.
This one is a String, so it has no maximum value.

I have an app which version string and code is formatted as yy.mmmm.hhnn, so, now, Jun 28, 19:50 generates the version 20.0728.1950. I never had any problem with this versioning system in both Android and iOS, so versions until 20.9999.9999 are OK.
For Android, the documentation clearly states that the max version code is 2100000000 (21.0000.0000), so PANIK! =)
For my new versions, I'm considering in using this version system: yy.1ddd.hhnn, where ddd is the day of the year (from 1 to 366). Since I cannot use any major version other then 20, my version will be the 1 before the day of year (and I'll be able only to update the app for more 9 years).
So, be careful in your version choosing, otherwise, you won't be able to update the app anymore (at least without changing the app id, but that would be a completely new app and you'll lose everything (reviews, etc.))

OrientDB having trouble with Unicode, Turkish, and enums

I am using a lib which has an enum type with consts like these;
Type.SHORT
Type.LONG
Type.FLOAT
Type.STRING
While I am debugging in Eclipse, I got an error:
No enum const class Type.STRİNG
As I am using a Turkish system, there is a problem on working i>İ but as this is an enum const, even though I put every attributes as UTF-8, nothing could get that STRING is what Eclipse should look for. But it still looks for STRİNG and it can't find and I can't use that. What must I do for that?
Project > Properties > Resouce > Text file encoding is UTF-8 now. Problem keeps.
EDIT: More information may give some clues which I can't get;
I am working on OrientDB. This is my first attempt, so I don't know if the problem could be on OrientDB packages. But I am using many other libs, I have never seen such a problem. There is a OType enum in this package, and I am only trying to connect to the database.
String url = "local:database";
ODatabaseObjectTx db = new ODatabaseObjectTx(url).
Person person = new Person("John");
db.save(person);
db.close();
There is no more code I use yet. Database created but then I get the java.lang.IllegalArgumentException:
Caused by: java.lang.IllegalArgumentException: No enum const class com.orientechnologies.orient.core.metadata.schema.OType.STRİNG
at java.lang.Enum.valueOf(Unknown Source)
at com.orientechnologies.orient.core.metadata.schema.OType.valueOf(OType.java:41)
at com.orientechnologies.orient.core.sql.OCommandExecutorSQLCreateProperty.parse(OCommandExecutorSQLCreateProperty.java:81)
at com.orientechnologies.orient.core.sql.OCommandExecutorSQLCreateProperty.parse(OCommandExecutorSQLCreateProperty.java:35)
at com.orientechnologies.orient.core.sql.OCommandExecutorSQLDelegate.parse(OCommandExecutorSQLDelegate.java:43)
at com.orientechnologies.orient.core.sql.OCommandExecutorSQLDelegate.parse(OCommandExecutorSQLDelegate.java:28)
at com.orientechnologies.orient.core.storage.OStorageEmbedded.command(OStorageEmbedded.java:63)
at com.orientechnologies.orient.core.command.OCommandRequestTextAbstract.execute(OCommandRequestTextAbstract.java:63)
at com.orientechnologies.orient.core.metadata.schema.OClassImpl.addProperty(OClassImpl.java:342)
at com.orientechnologies.orient.core.metadata.schema.OClassImpl.createProperty(OClassImpl.java:258)
at com.orientechnologies.orient.core.metadata.security.OSecurityShared.create(OSecurityShared.java:177)
at com.orientechnologies.orient.core.metadata.security.OSecurityProxy.create(OSecurityProxy.java:37)
at com.orientechnologies.orient.core.metadata.OMetadata.create(OMetadata.java:70)
at com.orientechnologies.orient.core.db.record.ODatabaseRecordAbstract.create(ODatabaseRecordAbstract.java:142)
... 4 more
Here is OType class: http://code.google.com/p/orient/source/browse/trunk/core/src/main/java/com/orientechnologies/orient/core/metadata/schema/OType.java
And other class; OCommandExecutorSQLCreateProperty:
http://code.google.com/p/orient/source/browse/trunk/core/src/main/java/com/orientechnologies/orient/core/sql/OCommandExecutorSQLCreateProperty.java
Line 81 says: type = OType.valueOf(word.toString());

Am I correct to assume you are running this program using a turkish locale? Then it seems the bug is in line 118 of OCommandExecutorSQLCreateProperty:
linkedType = OType.valueOf(linked.toUpperCase());
You would have to specify the Locale whose upper casing rules should be used, probably Locale.ENGLISH as the parameter to toUpperCase.

This problem is related to your database connection. Presumably, there's a string in OrientDB somewhere, and you are reading it, and then trying to use it to select a member of the enum.
I'm assuming in the code that you posted that the variable word comes from data in the database. If it comes from somewhere else, then the problem is the 'somewhere else'. If OrientDB, for some strange reason, returns 'STRİNG' as metadata to tell you the type of something, then that is indeed a defect in OrientDB.
If that string actually contains a İ, then no Eclipse setting will have any effect on the results. You will have to write code to normalize İ to I.
If you dump out the contents of 'word' as a sequence of hex values for the chars of the string, I think you'll see your İ staring right at you. You have to change what's in the DB to have a plain old I.

Unfortunately, it is related with regional setting, locale of your OS which is Turkish.
Two work around options :
1. Change your regional settings to English-US
2. Give encoding to the jvm as command line param for setting locale to English
-Duser.language=en -Duser.region=EN
I have created bug reports for xmlbeans, exist and apache cxf for the same issue. Enumeration toUpper is the point of the exception.
Some related links:
https://issues.apache.org/jira/browse/XMLSCHEMA-22
http://mail-archives.apache.org/mod_mbox/xmlbeans-user/201001.mbox/%3CSNT123-DS11993DD331D6CA7799C46CF6650#phx.gbl%3E
http://mail-archives.apache.org/mod_mbox/cxf-users/201203.mbox/%3CBLU0-SMTP115A668459D9A0DA11EA5FAF6460#phx.gbl%3E
https://vaadin.com/forum/-/message_boards/view_message/793105
http://comments.gmane.org/gmane.comp.apache.cxf.user/18316

One work-around is to type Type.ST and then press Ctrl-space. Eclipse should auto-complete the variable name without you having to figure out how to enter a dotless capital I on a Turkish keyboard. :)