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 37133 - Inability to update updater.jar
Summary: Inability to update updater.jar
Alias: None
Product: platform
Classification: Unclassified
Component: Autoupdate (show other bugs)
Version: 3.x
Hardware: All All
: P2 blocker (vote)
Assignee: t_h
: 43618 (view as bug list)
Depends on:
Blocks: 37010 37119 48955
  Show dependency tree
Reported: 2003-11-10 23:35 UTC by Unknown
Modified: 2008-09-02 16:16 UTC (History)
9 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter:


Note You need to log in before you can comment on or make changes to this bug.
Description Unknown 2003-11-10 23:35:28 UTC
As per
Comments From Petr Hrebejk:
Updating the updater.jar is not (supported).Maybe
it worked by accident but it never was feature of
the AU toupdate the updater.jar and will not be.

This inability to update updater.jar seems to be a
serious issue. This means that if any bug is found
in updater, then fixes for those bugs can only be
made available to users in the next release.
Comment 1 Petr Hrebejk 2003-11-11 09:42:01 UTC
This means that you require the updater.jar to update itself. Please
feel free to give advices how to make sure that this works in all cases.
Comment 2 Antonin Nebuzelsky 2003-11-11 10:49:57 UTC
Hrebejk, sorry, but this is NOT an enhancement. This is a regression.
It used to work for several releases. I am changing this back to
"defect", so that we don't lose track of it.

Please, don't close or change to enhancement important bugs which
prevent Support from delivering patches.
Comment 3 Petr Hrebejk 2003-11-11 10:56:29 UTC
No this is not regression at all. I already said that this never was
a feature of the AU and I'm not planing to make it a feature. (IE it's
rather a wontfix enhancement for me).
If it worked for you it worked by accident.
Comment 4 Jan Chalupa 2003-11-12 13:43:06 UTC
Changing back to DEFECT.

It used to work in the past, now it doesn't. Hrebejk, you say it
worked by accident, but I haven't seen any explanation why it doesn't
work now and what are the technical reasons why it can't be supported.
Until then, I consider it a DEFECT and a REGRESSION.
Comment 5 _ ttran 2003-11-12 14:39:58 UTC
No, updater.jar cannot update itself, at least on Windows.  When it's
running the file is locked by JVM, one cannot  rewrite it.  It may
work on Unix, but definitely not Windows even in the past unless they
changed something in the JVM

This is a similar situation to runide.exe, one cannot update it.

What is the bug which forced us to update the updater.jar?  Even if it
is a serious bug, it's already too late.  We are in chicken-and-egg,
Catch-22 situation.  Autoupdate facility just have to work.
Comment 6 Petr Hrebejk 2003-11-12 14:47:37 UTC
Yes that was one reason for why it never was supported,. Another
reason is that it does not seem smart to update something you are just
loading classes and resouces from. Are you sure it worked are you sure
that it did not copy the updater.jar into user dir where it is not used? 
Anyway may I ask how an never supported feture can turn into regression?
Comment 7 Antonin Nebuzelsky 2003-11-12 15:36:01 UTC
To Trung's question:
> What is the bug which forced us to update the updater.jar?

We don't need to fix a bug in updater.jar now, but we did it in the
past. See the bug #29875. This fix was delivered to the users of
Sierra ME because the bug prevented them from downloading an ME
update. The post-install hook was not executed by the Updater if
userdir path contained spaces. This was fixed and delivered via
autoupdate.nbm (where updater.jar was included - thus noone could have
assumed updating updater.jar is not supported). And AFAIK it worked
fine. On Windows.
Comment 8 Marian Mirilovic 2003-12-01 10:49:08 UTC
reassigne to Jirka - new owner of autoupdate
Comment 9 Unknown 2003-12-22 17:33:31 UTC
> This means that you require the updater.jar to update itself.
> this never was a feature of the AU.If it worked it worked by accident.
Is the above limitation documented? Else shouldn't this issue be
considered a bug/regression in so much as it used to work?

Also, the severity of this issue really depends on how stable
updater.jar is and how likely will there be a need to release fixes
for it. QA can adjust the priority of this issue depending on the
stability of updater.
Comment 10 Jan Chalupa 2004-01-07 16:11:42 UTC
> Is the above limitation documented? Else shouldn't this issue be
> considered a bug/regression in so much as it used to work?

This is actually an outstanding issue that was pointed out long time
ago (see issue #24361). Even though it reportedly worked in the past,
there is no guarantee it would work in general.

Functionality provided by updater.jar is relatively simple and stable,
and the inability to update it via AU is not an urgent issue at this
point. However, it is likely that this feature will be required in the
future and so it's desirable to have it implemented in the next
(post-3.6) release.
Comment 11 Jaroslav Tulach 2004-06-25 08:21:00 UTC
*** Issue 43618 has been marked as a duplicate of this issue. ***
Comment 12 _ ttran 2004-06-25 08:42:13 UTC
not for Promotion D -> TM = future
Comment 13 Peter Zavadsky 2005-01-26 22:26:15 UTC
Chau, how is this important for us? What is a difference between our
and NB need of this? I am decreasing the priority.
Comment 14 Peter Zavadsky 2005-01-27 21:44:09 UTC
Adding Chau, so she could answer the previous question.
Comment 15 Ch Nguyen 2005-01-27 22:07:19 UTC
I understand that this is a difficult issue to fix.  Unfortunately, we
are increasingly depending on the autoupdate functionality to deliver
the update bits for our product and there are a few missing features
in autoupdate we need that will in turn require the updater to update
itself.  What if the format of the NBMs change, etc? So it would be
very important to have updater to update itself (including on Windows)
as a critical need.

Having said that, I don't have any problem if you defer the
enhancement until "future" releases.  But I would like us to keep the
same priority P3 if possible.  Thanks.
Comment 16 Jiri Rechtacek 2005-01-31 10:28:42 UTC
What about a extra functionality of AutoUpdate client (not the
Updater)? The client will check any extra catalog or any extra section
in the common catalog, if there is a updater of Updater will start new
task: install new updater.jar in some specific folder (other then
originaly updater.jar placement) and the launcher will check this
folder before run IDE and do upgrade of updater.jar.
Not easy or outright way to do the task to update updater.jar :-(
Comment 17 Jan Chalupa 2005-01-31 14:52:56 UTC
Re Jiri's proposal: Might work. However, unlike the usual autoupdate
scenarios, the user would be required to explicitly exit the IDE and
restart it for the changes to take effect. Instead of restarting the
IDE automatically, it could just exit and instruct the user to restart

It would require changes to the launchers, of course. And it would
still not allow for updating the .exe launchers themselves (which is
another requirement).
Comment 18 Unknown 2005-01-31 18:02:08 UTC
The ability to update updater.jar itself may not really be required,
provided other requirements are met by providing appropriate features.
For instance, refer to the issue 48955: updater splash cannot be
updated since it is part of updater.jar. To solve this, the spalsh gif
can be moved out of updater.jar in which case it can be updated
independently. Other such requirements can be collected from other
users like cnguyencasj and implemented. I think, as long as
updater.jar is maintained as simply a very small core that merely
copies files and delegates everything else, it will not matter if it
can be updated by itself.
Comment 19 Jiri Rechtacek 2008-01-29 11:52:14 UTC
Autoupdate part and linux launcher changes were integrated:
Now I'm waiting for update of windows launcher.
Comment 20 t_h 2008-02-04 09:34:55 UTC
Windows launcher part, changes:
Comment 21 rbalada 2008-09-02 15:51:49 UTC
We had an opportunity to verify this implementation works well when we were preparing NB 6.1 Patch2.