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 98133 - Should be able to expand a .java file in the Projects window
Summary: Should be able to expand a .java file in the Projects window
Status: RESOLVED DUPLICATE of bug 96196
Alias: None
Product: java
Classification: Unclassified
Component: Source (show other bugs)
Version: 6.x
Hardware: All All
: P2 blocker with 10 votes (vote)
Assignee: Petr Hrebejk
Depends on:
Reported: 2007-03-17 03:24 UTC by _ gsporar
Modified: 2007-06-01 01:08 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 _ gsporar 2007-03-17 03:24:34 UTC
In NetBeans 5.5 it is possible to expand a .java file's node in the Projects
window and see a list of classes contained in that .java file.  Those classes
can then be expanded to see the Fields, Constructors, Methods, and Beans in the

This feature has been removed.

Please bring it back.

While it is true that the information can be seen in the Navigator window, not
everyone uses the Navigator window.  Or has the Navigator window open all the time.

Note that for users who might consider converting from Eclipse, the inability to
expand .java files in the Projects window could lessen their interest in
NetBeans since Eclipse provides expansion in its Project Explorer (which is
equivalent to the Projects window in NetBeans).

A somewhat related issue:
Comment 1 _ wadechandler 2007-05-03 21:16:19 UTC
This affects more than just the classes.  The BeanInfo Editor is not accessible
because of this.  This tool is a must have.  This will kill productivity for
JavaBeans in the IDE.  This has nothing to do with using them but creating and
designing them.  I have moved it to a P1 as this should block a 6.0 release. 
This is a regression and breaks functionality.
Comment 2 Milan Kubec 2007-05-04 13:47:41 UTC
Adding UI kw since (I think) it was removed according to some HIE decision. If
you think it's blocker for 6.0 then make it DEFECT (but not P1).
Comment 3 Michel Graciano 2007-05-04 14:34:12 UTC
So, I consider this a defect, and a regression since this is present in 5.X and
now we can't use this features, mainly BeanInfo Editor. I consider this a P1,
since we can't use the BeanInfo Editor in any way, but as you say that this is
not a P1, I lower this to P2.
Comment 4 misterm 2007-05-04 15:46:06 UTC
You cannot be serious, guys. It is not the first time a very useful NB feature
is removed without asking the community first. Not only bring it back, but
please don't remove stuff just because some department think it nobody cares
about it; we do.
Comment 5 _ wadechandler 2007-05-04 18:47:45 UTC
UI specifications should not be an overriding and hindering concept.  If
functionality is used and is crucial to a concept such as BeanInfo and JavaBeans
then it should be reviewed better and not just removed.  It should be included
in a different way or be left alone, but this should happen only after careful
analysis and review not on a whim.  

<smallrant_nothingmajor>I see this from time to time in NetBeans, and frankly
this doesn't make any sense.  I understand a UI specification needs to be
created as it helps with multiple things, but anything can be followed too
strictly.  The same can be said for situations I have seen where different
developers say we don't have any good use cases.  Sometimes thinking outside the
box is more beneficial to the project and the community.</smallrant_nothingmajor>
Comment 6 _ wadechandler 2007-05-04 18:49:29 UTC
I should follow the last comment with: thanks "everybody" for all the hard work.
Comment 7 _ wadechandler 2007-05-05 03:59:49 UTC
This same issue affecting other files is really starting to limit A LOT of
functionality. It affects moving classes around NetBeans Module Development in
the Layer which affects Java file among other things.  Now the layer editor is
just not there...different issue really, but caused by the same lack of
reviewing needs before jumping in head first with a change.
Comment 8 _ wadechandler 2007-05-05 05:58:03 UTC
Reviewing further, this presents a far worse usability problem.  In the case of
the BeanInfo editor, if a NavigatorPanel is the "new" way of getting it into the
IDE,  the way Navigator currently works, I browse off a file and then back to it
then it reverts back to its default state with the first navigator panel being
selected and not the one I want to work with.  

In NB 5.5 I would have 2 or 3 beans I'm working on and I could have their "Bean
Pattern" nodes expanded and be working on all of them and not lose valuable time
just switching between them.  Now, were the Navigator to be used and it is not
modified from its current usability one would have to constantly change from
Bean to Bean, select the appropriate panel from a combo-box, then start working
on bean patterns.  I really don't see how we can get the same support from a UI
element such as the navigator which has to be reset every time an element or
file is selected.

This same thing would be true if the "Bean Pattern" node is moved to a dialog
tool of some sort as a context menu item on Java files.  I really do not see the
gains in this "fix" for consistency in the UI specification.  Who made this
determination and based on what?  I'm sorry for getting a little upset
flustered, but this is really irritating as there is no apparent good solution
moving forward for all this missing stuff, and there really doesn't appear to
have been given a fair amount of thought and study to this issue before
proceeding forward.

There is an old saying "If it ain't broke don't fix it."  It falls in line with
the KISS principle.  OK, so the navigator had some inconsistencies with the file
nodes in the explorer view.  From the look of things the Navigator needed more
changing or minimizing and the explorer nodes needed to be kept, or the
Navigator needed to replicate what it needed to do it's job of being a
navigator, but the main issue is the way the navigator works doesn't meld well
with the Nodes view of allowing users to work on multiple Nodes of multiple
files at the same time by keeping certain work session elements static as the
explorer tree view does.  It just isn't as efficient for the developer.

I use the IDE every day.  This issue has affected me in many many ways.  I felt
its impact immediately in different areas.  I thought the missing stuff was just
not back yet as part of the Java model overhaul, but now that I see this is part
of a UI change, I have to say something.  It is certainly affecting my day to
day working, and it is making my work in the IDE much less efficient.
Comment 9 Petr Hrebejk 2007-05-29 10:48:39 UTC

*** This issue has been marked as a duplicate of 96196 ***