Re: Netbeans failure mode
- From: secret decoder ring <sdring@xxxxxxxxxxxxxxx>
- Date: Wed, 03 Dec 2008 13:42:59 -0500
Lew wrote:
secret decoder ring wrote:Which implies that there is no NetBeans 6.5, or any other number higher than 6.1.
No, it doesn't.
Sure it does.
I suppose you are technically correct that it did not explicitly *say* that, but it is a strong implication. "6.1 is the latest version" makes
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.
it very unlikely that there is a 6.5, since it is very uncommon (if it's
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.
That's because I don't have an exact number. I'd have to shut down NB, dig up a stopwatch, and start it up again, and I can't be bothered to do that at the drop of a proverbial hat.
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.
I DID give an estimate, however, despite your implication above that I didn't.
I must have missed it.
That you have. Reread my earlier posts if you want to find it. Otherwise, this discussion is over.
I am not being snide about anything. I am simply pointing out that whatever it is, it is NOT NetBeans 6.1 and consequently might behave differently from NetBeans 6.1.
Agreed
That statement is in direct contradiction with my copy of NB 6.1 self-reporting as being the most recent NetBeans
Which it doesn't do.
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.
data it retrieved from the NB Web site that can reasonably be characterized as having come from the proverbial horse's mouth.
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.
Of course, it could be the case that your statement is correct and my copy of NB 6.1 is in error (somehow failing to detect the existence of a more up to date version), rather than the other way around.
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.
That is very odd, in light of the above.
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.
You haven't answered Mark Space's question about your OS
I most certainly have.
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.
The slow startup time is not a primary complaint of mine. But it makes problems that force the user to restart NB to be onerous enough for this reason that I think suggesting people just resign themselves to occasionally restarting NB is "not good enough".
Who made that suggestion? Not I.
Somebody did.
I would look into your netbeans.conf.
Why? It is not possible that I've munged this file, for the simple
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.
You might wish to allocate a wee bit more -Xmx to NB
I doubt it. When it was doing its CPU-saturating-hang thing I noticed the process size was upwards of 200 megs. I infer that the -Xmx is 256M or more, which "ought to be enough", at least for the time being.
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.
Since my copy's GC parameters are still the factory defaults, if those GC parameters were the problem, a large proportion of all NB 6.1 installs would be similarly affected, which you claim is not the case.
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.
.
- Follow-Ups:
- Re: Netbeans failure mode
- From: Arne Vajhøj
- Re: Netbeans failure mode
- From: Lew
- Re: Netbeans failure mode
- Prev by Date: Re: Non-abstract factory design pattern versus using constructor directory
- Next by Date: Re: WAR task and including jspf files in jsp
- Previous by thread: Re: Netbeans failure mode
- Next by thread: Re: Netbeans failure mode
- Index(es):
Relevant Pages
|
