American Java Idol
I'm basically looking for opinions on this code, suggestions, ideas, or down right bashing. Be my Simon Cowell. It needs a method to parse from a string, but I can deal with that later. I made a Version class that is simple to use by any application (or so I think). I know I could use enums and varargs if I kept this approach...what do you think?
publicclass Versionimplements Comparable<Version>, java.io.Serializable{
privatestaticfinallong serialVersionUID = -3820214876542357769;
publicstaticfinalint MAJOR_VERSION = 0;
publicstaticfinalint MINOR_VERSION = 1;
publicstaticfinalint RELEASE_VERSION = 2;
publicstaticfinalint QUANTIFIER_TYPE = 3;
publicstaticfinalint QUANTIFIER_VERSION = 4;
publicstaticfinalint BUILD = 5;
publicstaticfinalint QUANTIFIER_TYPE_ALPHA = 0;
publicstaticfinalint QUANTIFIER_TYPE_BETA = 1;
publicstaticfinalint QUANTIFIER_TYPE_GAMMA = 2;
publicstaticfinalint QUANTIFIER_TYPE_RELEASE_CANDIDATE = 3;
publicstaticfinal String[] QUANTIFIER_TYPE_STRINGS ={"a","b","g","rc"};
privateint[] version =newint[]{Integer.MIN_VALUE,Integer.MIN_VALUE,Integer.MIN_VALUE,
Integer.MIN_VALUE,Integer.MIN_VALUE,Integer.MIN_VALUE};
transientprivate StringBuffer versionString =new StringBuffer();
public Version(){}
public Version(int major,int minor){
version[MAJOR_VERSION] = major;
version[MINOR_VERSION] = minor;
}
public Version(int major,int minor,int release){
version[MAJOR_VERSION] = major;
version[MINOR_VERSION] = minor;
version[RELEASE_VERSION] = release;
}
public Version(int major,int minor,int release,int quantifierType,int quanitifier){
version[MAJOR_VERSION] = major;
version[MINOR_VERSION] = minor;
version[RELEASE_VERSION] = release;
version[QUANTIFIER_TYPE] = quantifierType;
version[QUANTIFIER_VERSION] = quanitifier;
}
public Version(int major,int minor,int release,int quantifierType,int quanitifier,int build){
version[MAJOR_VERSION] = major;
version[MINOR_VERSION] = minor;
version[RELEASE_VERSION] = release;
version[QUANTIFIER_TYPE] = quantifierType;
version[QUANTIFIER_VERSION] = quanitifier;
version[BUILD] = build;
}
public Version(int major,int minor,int release,int build){
version[MAJOR_VERSION] = major;
version[MINOR_VERSION] = minor;
version[RELEASE_VERSION] = release;
version[BUILD] = build;
}
publicvoid setVersion(int scheme,int value){
versionString.setLength(0);//reset string
version[scheme] = value;
}
publicint compareTo(Version v){
int temp;
for (int i = 0; i < version.length; i++){
temp = version[i] - v.version[i];
if (temp != 0)return temp;
}
return 0;
}
public String toString(){
if (versionString.length() != 0)return versionString.toString();
boolean started =false;
if (version[MAJOR_VERSION] != Integer.MIN_VALUE){
started =true;
versionString.append(version[MAJOR_VERSION]);
}
if (version[MINOR_VERSION] != Integer.MIN_VALUE){
if (started) versionString.append('.');
started =true;
versionString.append(version[MINOR_VERSION]);
}
if (version[RELEASE_VERSION] != Integer.MIN_VALUE){
if (started) versionString.append('.');
started =true;
versionString.append(version[RELEASE_VERSION]);
}
if (version[QUANTIFIER_TYPE] != Integer.MIN_VALUE && version[QUANTIFIER_VERSION] != Integer.MIN_VALUE){
versionString.append(QUANTIFIER_TYPE_STRINGS[version[QUANTIFIER_TYPE]]);
versionString.append(version[QUANTIFIER_VERSION]);
}
if (version[BUILD] != Integer.MIN_VALUE){
versionString.append(" Build ");
versionString.append(version[BUILD]);
}
return versionString.toString();
}
publicstaticvoid main(String[] args){
System.out.println(new Version(1,2,3));
System.out.println(new Version(1,2,3,QUANTIFIER_TYPE_BETA,1));
System.out.println(new Version(1,2,3,QUANTIFIER_TYPE_RELEASE_CANDIDATE,2));
System.out.println(new Version(1,2,3,353));
}
}
[9499 byte] By [
robtafta] at [2007-11-27 2:39:15]
> The class and methods need comments.
>
Agreed
> For initialization you can use a single constructor
> to do the work rather than repeating it in every
> ctor. The other ctors just call that one (passing in
> undef values for fields not defined.)
>
Nice idea, but from a users standpoint, would you want to use a constructor that just has 2 fields when you just have major and minor version, or make everyone pass in all fields?
> You need bound checking. After all is '-3' a valid
> value for any of the fields.
>
I am assuming this is for the setVersion method. I'm not really sure if this method is really useful anyway. I guess the quantifier falls into this as well. Enums will fix that one.
> You might consider accessors for each of the sub
> parts - like a getMajor(), etc. Otherwise someone
> will probably end up parsing the string value.
>
Good idea. I might feel obligated to make setter methods as well. Part of me wants to make this atomic and eliminate the set method.
> You might also consider padding in the toString()
> method so instead of "1.2.3" it becomes
> "001.002.003".
I thought about that, I wasn't really sure how I could incorperate that. One of the ideas was to make it store a small amount of data and not have a lot of overhead when using Serialization. Actually I was thinking of having the Version class, and also having a VersionFormatter for going to and from Strings. Maybe this would be the appropriate place for it.
>
> Keep in mind of course that toString() is not a
> substitute for a display method. If you want to get
> complicated you could add a display method. All
> sorts of bells and whistles that you could add
> there.
Good point.
>
> Normally you would probably want a build number, not
> just major, minor, release. At least if this relates
> to software that would be the case.
>
Build number is in there, after the quantifier.
> In the same way I am not sure that I get QUANTIFIER.
> Again in terms of software a release candidate would
> often just be an earlier build than the final
> release. That depends on what the usage of this is.
The idea of quantifier is for pre-releases, like RC, Alpha, Beta, and Gamma. I did some research at one point, and these were the most common 'non numeric' parts of versions (Gamma is pretty rare, but I found it somewhere). I wasn't sure how to incorperate this into a system of numbers, so this is the approach I used with a number to represent the quantifier. Maybe using Enums will make this easier to look at and understand.
I'm not even sure that my terminology is right for some of this, like Quantifier and scheme. Anyway, thanks for the suggestions, always open to more.
> > The class and methods need comments.
> >
> Agreed
>
> > For initialization you can use a single constructor
> > to do the work rather than repeating it in every
> > ctor. The other ctors just call that one (passing in
> > undef values for fields not defined.)
> >
> Nice idea, but from a users standpoint, would you
> want to use a constructor that just has 2 fields when
> you just have major and minor version, or make
> everyone pass in all fields?
I didn't say use one. I said one has all of the code and the others call it.
>
> > You might consider accessors for each of the sub
> > parts - like a getMajor(), etc. Otherwise someone
> > will probably end up parsing the string value.
> >
> Good idea. I might feel obligated to make setter
> methods as well. Part of me wants to make this
> atomic and eliminate the set method.
>
That of course depends on usage. But I wouldn't expect that a valid use case would exist for updating them individually.
> > You might also consider padding in the toString()
> > method so instead of "1.2.3" it becomes
> > "001.002.003".
> I thought about that, I wasn't really sure how I
> could incorperate that. One of the ideas was to make
> it store a small amount of data and not have a lot of
> overhead when using Serialization. Actually I was
> thinking of having the Version class, and also having
> a VersionFormatter for going to and from Strings.
> Maybe this would be the appropriate place for
> it.
>
In terms of serialization how would you expect to have - 3 or 3 million?
Note as well that you can add additional control to serialization, which would preclude the string from being serialized.
>
> >
> > Normally you would probably want a build number, not
> > just major, minor, release. At least if this relates
> > to software that would be the case.
> >
>
> Build number is in there, after the
> quantifier.
>
> > In the same way I am not sure that I get
> QUANTIFIER.
> > Again in terms of software a release candidate
> would
> > often just be an earlier build than the final
> > release. That depends on what the usage of this
> is.
>
>
> The idea of quantifier is for pre-releases, like
> RC, Alpha, Beta, and Gamma. I did some research at
> one point, and these were the most common 'non
> numeric' parts of versions (Gamma is pretty rare, but
> I found it somewhere). I wasn't sure how to
> incorperate this into a system of numbers, so this is
> the approach I used with a number to represent the
> quantifier. Maybe using Enums will make this easier
> to look at and understand.
>
> I'm not even sure that my terminology is right for
> some of this, like Quantifier and scheme.
> Anyway, thanks for the suggestions, always open to
> more.
Yes but those are labels - like that you put on a web page. But again that depends on the usage.
