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 41848

Summary:	Remove the Hacks class from the Project UI module
Product:	projects	Reporter:	Petr Hrebejk <phrebejk>
Component:	Generic Infrastructure	Assignee:	Milos Kleint <mkleint>
Status:	RESOLVED FIXED
Severity:	blocker	CC:	jglick, jrechtacek
Priority:	P4	Keywords:	ARCH
Version:	4.x
Hardware:	All
OS:	All
Issue Type:	DEFECT	Exception Reporter:
Bug Depends on:
Bug Blocks:	41535, 49990

Description Petr Hrebejk 2004-04-08 13:29:02 UTC

Probably this can go away now? Since we have core
& openide branched anyway. Petre do you want to do it?

In fact it will probably have to wait untli we
resolve all the issues with log/phys. views and
supplying actions into the context menus. But
let's have it recorded.

Comment 1 Jesse Glick 2004-04-08 14:55:11 UTC

I already got rid of some stuff, but more remains.

Also there should not remain any overrides or masks in the
projects/projectui layer.

Comment 2 Jesse Glick 2004-06-15 13:05:39 UTC

Provisionally marking as a defect to make sure it is considered in the
D timeframe.

Comment 3 Petr Hrebejk 2004-06-15 13:56:52 UTC

What remains in Hacks is adding the project specific new Action into
the FolderLoader. (I doubt that this will disapear in D)

And the update of the MainWindow title. This is probably up to you Jesse.

The layer looks pretty clean. We are only hiding the Folder template
which is probably OK.

Comment 4 Jesse Glick 2004-08-10 05:01:46 UTC

Well probably can't do much about the rest.

Comment 5 _ rkubacki 2004-10-07 15:50:55 UTC

The remaining hacks slows down startup.

Re window title: Can we enhance for instance StatusDisplayer with a
method to set app title text? That way we can avoid reflection to
NbTopManager that takes signifact time in ModuleRestored. Would it be
feasible?

Comment 6 Jesse Glick 2004-10-07 16:10:13 UTC

No API changes now please. Can be considered for E. StatusDisplayer is
the wrong place, anyway; should just be a public method in
o.o.w.WindowManager, I suppose.

Re. overhead for using reflection to access NbTopManager.WindowSystem:
surely this cannot be significant! We are using one Class.forName and
one Class.getMethod. Perhaps you are seeing the effect of some
reflection system being initialized? Or if it really consumes a
measurable amount of time to load one Method in the current JRE, we
should be filing a JRE performance bug.

Comment 7 Petr Hrebejk 2005-03-29 11:32:55 UTC

Almost all hacks are removed already. The only ramining is the Main window title
which is waiting for support from winsys I think. Downgrading to P4.

Comment 8 Jesse Glick 2006-08-16 17:12:03 UTC

Updating window title no longer uses reflection and is here to stay.

jrechtacek added some reflective call to TemplateWizard.reload(DataObject) which
indicates an API defect somewhere, so he can evaluate that.

Comment 9 Milos Kleint 2008-06-06 10:46:17 UTC

closing the issue as fixed as I understand from the comments everything is done.

Comment 10 Jesse Glick 2008-06-06 19:38:30 UTC

The TemplateWizard.reload(DataObject) hack should probably still be reevaluated.