This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.

Bug 244698 - Provide a Version class
Summary: Provide a Version class
Status: NEW
Alias: None
Product: platform
Classification: Unclassified
Component: -- Other -- (show other bugs)
Version: 8.0
Hardware: PC All
: P2 normal (vote)
Assignee: Petr Hejl
URL:
Keywords: API
Depends on:
Blocks:
 
Reported: 2014-05-23 15:39 UTC by Petr Hejl
Modified: 2014-05-23 16:47 UTC (History)
1 user (show)

See Also:
Issue Type: ENHANCEMENT
Exception Reporter:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Petr Hejl 2014-05-23 15:39:49 UTC 
I believe we should provide a Version class for common usage. Perhaps it should be in org.openide.util. So far we have couple of such classes all around. One I would like to use after same refactoring is in the web.common in org.netbeans.modules.web.common.api package.

It is copied from j2ee which itself is copied from serverplugins. web.common was enough so far, but there are also use cases for non-web plugins to use the version class.
Comment 1 Jaroslav Tulach 2014-05-23 15:52:08 UTC 
I don't know what is in web.common, but there is 
http://bits.netbeans.org/dev/javadoc/org-openide-modules/org/openide/modules/SpecificationVersion.html
Comment 2 Petr Hejl 2014-05-23 16:20:25 UTC 
(In reply to Jaroslav Tulach from comment #1)
> I don't know what is in web.common, but there is 
> http://bits.netbeans.org/dev/javadoc/org-openide-modules/org/openide/modules/
> SpecificationVersion.html

Thanks for the point Jardo. Though it seems to be too strict regarding the notation :(

The Version from web common supports JSR277 notation MAJOR_NUMBER[.MINOR_NUMBER[.MICRO_NUMBER[.UPDATE_NUMBER]]][-QUALIFIER] and also dotted notation used by Oracle MAJOR_NUMBER[.MINOR_NUMBER[.MICRO_NUMBER[.UPDATE_NUMBER[.QUALIFIER]]]] and with limited functionality it can deal with generic string. It should be also extended to be able to parse MAJOR[.MINOR[.MICRO[.QUALIFIER]] used by JBoss.

There are just too many formats :/ It is not common requirement to compare and use different formats together. On the other hand I'd prefer one Version class rather than couple of them for each format.

I'm not sure whether we can extend SpecificationVersion this way and whether it would be reasonable.

Perhaps good enough would be a method returning SpecificationVersion that would parse just MAJOR.MINOR.MICRO ignoring the rest. I believe nobody really depends on update or qualifier right now. Of course such requirement may appear anytime in near future.

What do you think?
Comment 3 Jaroslav Tulach 2014-05-23 16:47:34 UTC 
The class is likely to accept only numbers. But without any limit. Extending it to qualifier (compared alphabetically and being last may be an option). Posible having different factory methods for different formats!?