Lew said:
Sure it does.
It doesn't say "6.1 is the latest version". It says, "Your 6.1 version
is up to date".
Those statements are synonymous.
And 6.1 version is not up to date, is it?
So those statements are also false.
And yet, there is a 6.5 version of NetBeans. Doesn't that hint that
your analysis needs enhancement?
No, it just means that the statement made by the updater was incorrect.
My analysis of what that statement implied stands.
Elsewhere I have highlighted an explicitly contradictory pair of
statements, one uttered by the "check for updates" menu item of NB 6.1
when activated and one on the NB Web site.
It seems clear that both statements cannot simultaneously be true, and
that the one on the Web site is true.
It follows that the updater has a bug that causes it to make incorrect
statements to the user from time to time.
Elsewhere, another user reported reproducing this behavior, so it is
likely that the bug can be corrected with relative ease.
But you are investigating a specific problem that is hurting you, that's
exactly what you need to do.
No, I do not. I simply need to report the problem, not investigate it
laboriously like I was going to be fixing it myself. That's not my
responsibility. It is the development team's responsibility.
If you want me to do that work for them, even though I have other fish
to fry right now, my going rate is $60 an hour.
That you have. Reread my earlier posts if you want to find it.
Otherwise, this discussion is over.
It certainly does. I posted the exact message a short time ago, along
with a message on the NB Web site that directly contradicts it. Of the
two, the message on the Web site appears to be accurate, making it the
updater that is in error.
And yet NetBeans 6.5 is the most recent version.
That would mean that the Web site has two contradictory pieces of
information: one, a certain statement at
http://www.netbeans.org/community/releases/65/relnotes.html and two,
whatever data is retrieved by the NB updater when it goes checking for
whether there are any updates.
It's clearly possible that the bug in the NB updater is physically
located on their web server rather than in the client code in NB. It
remains the case that the bug exists, though, regardless of its precise
location.
If it's on the server, though, it might be possible to fix it simply by
updating an apparently-outdated piece of data somewhere on the site,
without having to change any of the client code. That would be convenient.
Depends on how you define "error".
It certainly includes the case that the software says, and I quote,
"Your IDE is up to date!" when the Web site makes it clear that that's
not true.
It happens that NB 6.5 is the most
recent version of NB, and, from your evidence, that version 6.1 doesn't
report that.
It in fact DOES, EXPLICITLY report the inverse, when asked explicitly to
"Check For Updates".
And that, by any reasonable definition, constitutes an error.
Maybe, like many, many other software products, versions
only report up-to-dateness in their own context and not that of some
later version when it comes out.
That does not make sense. If every version is an island, then every
version is always the most up to date version of that version, which
renders the whole notion of versions or of "up-to-dateness" useless.
Regardless of the above, it is not what users expect. Users expect that
a feature named "check for updates" will say "no updates available" if
and only if they are using the absolutely most current, gee-whiz,
bleeding-edge released version of a product. So, not beta or alpha
versions or nightly builds, but certainly versions prominently featured
as non-beta on the front page of the product's Web site.
It just means that you have to investigate what's different between the
setups. I suggest you examine netbeans.conf.
I haven't hand-hacked mine, so nothing about it should be "wrong" in any
trouble-causing way. If anything is, it means the preferences dialog
code contains a bug in that it wrote through a change without properly
validating it first.
Then again, I haven't used the preferences dialog to tweak anything that
was obviously related to NB's memory-allocation or garbage-collection
policy, either. So that stuff should be factory-default on my
installation, regardless. And if the factory defaults are bad, then once
again the fault lies elsewhere than with me.
I corrected that typo before you responded.
What? That's not a typo, it's a baldly false statement. It's perfectly
grammatical and correctly spelled, but semantically wrong, in other words.
And I certainly had not read any correction or retraction of it at the
time that I posted my response.
Who made that suggestion? Not I.
Somebody did.
It's not a question of you "munging" the file, but of it perhaps not
being optimal out of the box.
I should not need to hand-hack a .conf file just to use a product in the
manner intended by its developers. This isn't the dark ages when the
state of the art in computer user interfaces was a unix command prompt,
vi, and emacs. This is twenty years later.
The process size is not a reliable indicator of maximum heap, quite the
contrary. It actually indicates that -Xmx is far below 200 MB. Process
size includes class space, the JVM itself and a host of non-heap
allocations.
Wrong. Generously assuming that all of that stuff required a whopping 50
megs, if the -Xmx was the next lower setting, 128M, the process size
would be at most around 180. 200+ therefore requires the -Xmx be at 256
or higher, though a process size below 300 or so would indicate that the
actual Java heap is not all the way up to 256 megs in size.
With tens of megs of room in the heap, GC pauses should then only be
occasional and very brief.
The problem observed is something unrelated to memory use, save that it
may have CAUSED memory use. With the stuff open I usually have open, NB
is usually around 150-180M in size. When it goes into freezy-slushy-mode
it bloats up suddenly to up to 240. Something is both creating and
referencing a lot of objects AND using a lot of CPU when that happens.
Packratting combined with consequent ArrayList/HashMap resizing could be
the culprit.
Perhaps, or perhaps not. Or perhaps more people who use NB are
modifying netbeans.conf than you think.
Few users hand-hack configuration files in this day and age. That is a
statistical fact, Jack.
In any event, empirical evidence is best. If you adjust the
configuration and the problem goes away, Bob's your uncle.
I do not know how, and I'd much rather it work properly out of the box
anyway.
