I need to get the OS version and Browser Version from the user-agent HTTP header. Is there any standard API which should parse it and return? One more question. What is OS_TEXT, OS_CODE, BROWSER_TEXT, BROWSER_CODE in this context?
Through HttpServletRequest I could only get the user agent string, But I require browser version and os version which any way is part of user_agent. But my question is there any method which will return something like this
No. But if you have the User-Agent header you've got all you need don't you? The HTTP specification only requires a list of product/product-version tokens, it doesn't specify what those should be so there is nothing the Servlet specification can do to parse it.
There may be utility classes out there - I don't know any.
This may be a futile excercise anyway since some browsers do not follow the standard and others deliberately spoof this header (Opera for example can be configured to pretend it is IE). Why do you need to know the browser? What do you need to do with this information?
In which case could you not just change the database table and store the contents of the User-Agent header itself? Then whatever needs to report on this can do the logic to workout what the data means.
That looks waaaaaaay obsolete. No Firefox? No IE 7 and 8? No XP? No Opera? No Safari? No Vista? And who cares about Netscape 4.0 vs. Netscape 4.7 these days?
Also note that the UA string can contain both "MSIE 5" and "Mozilla", a case not being handled by that code.
I can only repeat: You need to understand WHY this information is being collected; only then can you make informed decisions about what is and is not important.
Paul's suggestion also is a good one. If you save the UA string in full, then you can later dissect it as required (even as the requirements, and your understanding of UA strings, changes) in addition to doing any analysis on the spot.
One more thing I forgot to mention is, we are storing the User-agent field in a single database field. The logic for parsing the different field values need not be their on the storing application as their can be many applications logging the same information . Only the reporting module needs to be able to understand and parse the user-agent.
Imagine a scenario when you have used this in 5 different applications and a new browser version comes up. If the logic of parsing is present on reporting side then you need to just upgrade the reporting module not all 5 applications.