is OperatingSystem#getVersion really returning null?

[Koper, Dies]

According to the Javadoc OperatingSystem#getVersion can return null:

* @return operating system version or null if it couldn't be
determined.

Most api implementations however populate this field with
osBuilder.version(ComputeServiceUtils.parseVersionOrReturnEmptyString(..
.)), hence it becomes "" if undetermined.

So I added code to the FGCP implementation to set version to null if
this method returns "", but I now notice none of the other providers do.

I'd like to suggest we either change the javadoc to follow the
implementations or change the implementation to follow the Javadoc.
Any preferences?

Cheers,
Dies

PS: I find this helper method awesome as it covers almost all my version
parsing needs!

[Andrei Savu]

On Tue, Feb 28, 2012 at 4:35 AM, Koper, Dies <di...@fast.au.fujitsu.com> wrote:

I'd like to suggest we either change the javadoc to follow the
implementations or change the implementation to follow the Javadoc.
Any preferences?

I would go for updating the javadoc to match the behaviour if this is consistent 

across multiple providers. 

[Adrian Cole]

+1.

pull for javadoc welcome! :)

-a
p.s. glad you like the parser thingy

> --
> You received this message because you are subscribed to the Google Groups
> "jclouds-dev" group.
> To post to this group, send email to jclou...@googlegroups.com.
> To unsubscribe from this group, send email to
> jclouds-dev...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/jclouds-dev?hl=en.

[Koper, Dies]

OK.
You'll have to be patient though.. New to git.
I was able to make a patch for ChiliProject the other day but somehow
the command line doesn't work well with my jclouds checkout..
Asking me for my password, and then no matter what I fill in, a few
seconds later the command prompt just comes back.
I don't think git is very Windows user friendly/mature.

After forking/cloning the repository, do I still need to create a branch
locally (and if so how?) or just start making my changes, commit them
and push them?

Thanks,
Dies

> dev+uns...@googlegroups.com.

[Adrian Cole]

heh no problem. first pull being a javadoc update is probably a good idea :)

once you have a local clone of your fork, you create a branch and push
that to origin, then submit a pull request. There's also a tool
called gitflow which automates this quite a bit.
https://github.com/nvie/gitflow

cheers,
-a

[Koper, Dies]

Hi Andrei, Adrian,

I had a closer look at it and it does seem to return null in some cases
after all.
I think there is an anti-pattern about using return statements in
various places in a method that was followed here and that must have
caused this issue.
If the osVersionMap does not contain the osFamily passed to the method,
it returns "".
If it does, it may return null, or the version you want, but probably
not "".

I can't find any code that examines the return value and does anything
particular if it is "".
So I suppose we have the following two options to address this:

1. Document its behaviour: OperatingSystem#getVersion returns "" when ..
uh.. the OS family is not in some internally kept map; and return null
if the version could not be determined for other reasons.

2. Fix the method to return null instead of "" and update the Javadoc
and helper method name accordingly.

I would think 2. is safe enough as current users would have complained
already that the OS family could not be determined if this method ever
returned "" for someone.

Regards,
Dies Koper

> -----Original Message-----
> From: jclou...@googlegroups.com [mailto:jclouds-
> d...@googlegroups.com] On Behalf Of Adrian Cole
> Sent: Friday, 2 March 2012 10:42 AM
> To: jclou...@googlegroups.com
> Subject: Re: is OperatingSystem#getVersion really returning null?
>

> dev+uns...@googlegroups.com.

[Adrian Cole]

+1 for making it return null

[Andrew Phillips]

> +1 for making it return null

...accompanied by a @Nullable annotation, please! ;-)

ap