Netbeans 4.2 early access...

[Jeff]

Im playign with the development build which is available now.  So far looks promising and mgith even stop my from gripign abotu the things I've missed  from JBuilder adn Eclipse.

More info as I use it more...

[Herkules]

New CVS support is cool but has performance issues on rich directory structures

Enhanced typing in the editor

Matisse (GUI editor) just rulez but still shows some problems

Many more refactorings

Code completion in JavaDoc

Usability enhancements in Navigator

NetBeans module wizard!!!!

Collaboration (also available for 4.1). Cool stuff, but still a bit buggy and not widely community-used. It's hard to find someone online. Lookout for Herkules or a FlyingGuns conversation.

[swpalmer]

Matisse = useless.  STILL doesn't use a standard layout manager.  Remember SpringLayout - the layout manager that was designed specifically for layout tools that NetBeans still doesn't support AT ALL???
Matisse always anchors things to the wrong edge and is difficult to get to work properly.  Try making almost any UI that is resizeable and has more than 4 components that aren't jsut lined up in a row and you will see what a mess it makes.

It does show promise though.  They just need to ditch the layout manager they are using with it and use SpringLayout, and work out the bugs with components anchoring to the wrong things and resizing awkwardly.

Netbeans still takes forever to scan the classpath.  Something that Eclipse seems to take no time for at all - it just works.

Code-completion is still dog-slow compared to Eclipse. In general the whole IDE feels sluggish.

They are improving for sure... but they still aren't near Eclipse for performance and ease of use. Eclipse and the auto compile feature rules.  The code is always ready to run with no delays.  If you have save your source file then it's already compiled... at no perceived cost.  Just plain typing in Netbeans leads to awkward pausing.

I hope they continue though.  They are heading in the right direction.  I keep meaning to try out the profiler.. but it doesn't install on the last 4.2 dev version I tried, claims it MUST have 4.1.

Games published by our own members! Check 'em out!

[Bombadil]

Matisse

Remember that the Matisse Layout Manager will be part of a future J2SE.

Netbeans still takes forever to scan the classpath.  Something that Eclipse seems to take no time for at all - it just works.

NB should do this only once a new version is being "installed" (I just unzip the archive, ready). Then it's ready because of cash.

Or do you mean when you start a project? Well, I don't see any delay then.

Code-completion is still dog-slow compared to Eclipse.

NB 4.2 q-build should provide a fast code-completion. I can't and won't compare it to Eclipse, but the code completion is there when I press the key.

In general the whole IDE feels sluggish.

Not on my 1,8 GHz Winblows box. NB's as fast as any other editor, native or Java.
It may be different on Mac, or with different JDKs, I've no idea. I'm using standard J2SE 1.5_04.

[GKW]

You can adjust the length of time that it takes for the code completion box to appear.  On 4.1 it is set to 500ms by default.  A good number I guess.  It always seem like it takes for ever to appear when I need it but appears too quickly when I don't.

[swpalmer]

Remember that the Matisse Layout Manager will be part of a future J2SE.

But WHY?  Why won't they bloody use SpringLayout!!!???

Netbeans still takes forever to scan the classpath.  Something that Eclipse seems to take no time for at all - it just works.

NB should do this only once a new version is being "installed" (I just unzip the archive, ready). Then it's ready because of cash.

Or do you mean when you start a project? Well, I don't see any delay then.

It happens every time i load NetBeans with an existing project.  It is done on a background thread now, so really it just means most features aren't available for several minutes...

Code-completion is still dog-slow compared to Eclipse.

NB 4.2 q-build should provide a fast code-completion. I can't and won't compare it to Eclipse, but the code completion is there when I press the key.

It could have been because it hadn't finished scanning the classpath, but I think there is more to it than that.

In general the whole IDE feels sluggish.

Not on my 1,8 GHz Winblows box. NB's as fast as any other editor, native or Java.
It may be different on Mac, or with different JDKs, I've no idea. I'm using standard J2SE 1.5_04.

I am running on a dual processor Windows box of approximately the same speed (not in front of it now to double check, but it may be exactly a dual 1.8GHz if my memory is correct).  Using Java 6 b42, or Java 5 1.5.0_04.. not sure which.

I don't mean to be bashing it or anything.  I *want* to use it instead of Eclipse.  If only to avoid SWT for political reasons ;-).  But I can't suffer the drop in productivity that the switch would cause at this point.  One of the main things being the slow and cumbersome auto-complete, and the fact that I have to wait for Ant builds.  With Eclipse I never have to wait at all for code to compile, unless I do a clean build or refresh the workspace to pull in external changes.

I'm still waiting for a usable GUI layout tool as well.  I was hoping it would be Matisse, but it isn't, at least not yet.

[Bombadil]

But WHY?  Why won't they bloody use SpringLayout!!!???

The Netbeans developers should know the answer, several ones are on the NB mailing list.
There's been a lof of talk about Matisse. I've just looked at it for a short time, it looked nice, but since it's pre-beta I disabled it again.

The NB mailing list is viewable via Web, too, and fully accessible via e-mail or Usenet (NNTP). Please see: http://www.netbeans.org/community/lists/
More about the mailing list "nbusers@netbeans.org" is at: http://www.netbeans.org/community/lists/top.html

scan the classpath

It happens every time i load NetBeans with an existing project.  It is done on a background thread now, so really it just means most features aren't available for several minutes...

I then guess this isn't normal behaviour. For my small sized (hobby) projects it takes a few seconds and it's ready. Also, when I open the project I keep it open for the rest of the session. :-)
A while ago I've seen a corrupted cash container (from the classpath scan) and NB didn't like this. Can't remember the exact details, but deleting the cash folder in the NB config folder solved it.

I don't mean to be bashing it or anything.  I *want* to use it instead of Eclipse.  If only to avoid SWT for political reasons ;-).  But I can't suffer the drop in productivity that the switch would cause at this point.  One of the main things being the slow and cumbersome auto-complete, and the fact that I have to wait for Ant builds.  With Eclipse I never have to wait at all for code to compile, unless I do a clean build or refresh the workspace to pull in external changes.

Avoiding SWT is wise.
Please don't hesitate to ask on the NB mailing list what's concerning your problems with NB. I think it's worth a try. They'll help, if they can.
Good luck, and please don't give up yet.

This last sentence has got some irony in it: the first time I tried Netbeans (4.0?) I've been shocked because it just didn't do what I wanted it to do and was so different to Jbuilder (which I used to use). I finally wiped NB from my harddisc. Some weeks later I again downloaded the same version and tried it again. Don't know why. I configured many options (to get used to the options menu is a bit tedious once, but it's well worth it) and then: NB worked like a charm for my purposes. Since then we're "friends". :-) 

I don't use Eclipse so I can't compare NB to it. Jbuilder has been a responsive IDE for my/our taks, but NB does match it well. I also use Jedit as Java app and actually can't see any difference when typing concerning the responsiveness (sp?).

Code completion, well, there's a big difference between 4.1 and 4.2. For example for my classes using JOGL with all the GL_ definitions, this difference is very noticeable when hitting the code completion keys (it changed in 4.2_beta). In 4.1 it takes a long time for the classes using JOGL, in 4.2_beta it's just there.
Also there are several options to adjust its behaviour (like GKW said, I'm not even sure which ones I disabled and enabled exactly, I tend to always take the option files over from version to version. Some Javadoc popup I disabled definitely.

[Herkules]

But WHY?  Why won't they bloody use SpringLayout!!!???

Are you blaming them for using a new, opensource layoutmanager and at the same time advocating an IDE that uses a propreitary UI toolkit and own compiler? This doesn't go together very well.

I cannot see any objections against a new layout when its cool.

[swpalmer]

But WHY?  Why won't they bloody use SpringLayout!!!???

Are you blaming them for using a new, opensource layoutmanager and at the same time advocating an IDE that uses a propreitary UI toolkit and own compiler? This doesn't go together very well.

I cannot see any objections against a new layout when its cool.

What does my choice of IDE or the UI toolkit that IT uses have to do with it?  I don't use SWT and have never suggested to anyone to use it.  The compiler in my IDE is irrelevant since it has nothing to do with what I need to code and ship my application. I don't use new layout managers just for fun when I use my IDE.  I just ask Sun to support the layout manager they already have.  I'm blaming them for adding more bloat to the JRE or classes I must ship.  Im blaming them for NOT allowing use of SpringLayout.

Have you looked at the new layout manager?  Based on the code generated for it, I see that it is very similar to SpringLayout, but much harder to "read".  It seems silly to invent yet another layout manager, when the existing ones, particularly SpringLayout, can work perfectly.  Is there some great failure of SpringLayout?  If not, why haven't they coded the tool to use it like it was intended.  The main reason for SpringLayout's existence was for layout tools, and Sun's layout tool doesn't support it! I think that is just plain dumb.

If I use the NetBeans layout tool I don't get to have my choice of Layout Manager because it isn't supported.  I want to use components that are standard to the JRE, because they are always installed so I don't have to distribute them, they are exposed to more developers so they should get more testing, more documentation, more examples, etc...   Note that I did not complain when SpringLayout was created because I saw that it had a purpose and it seemed to do a good job at filling a hole left by the existing layout managers.  But the new layout manager included with Matisse doesn't seem to offer anything significant.  It is new for the sake of being new.  It will clutter the JRE with what appears to be redundant code.  We already have SpringLayout - but Sun won't support it.  Why?  What is the new and wonderful feature of this new stuff?  If it is there I will shut up.  I don't see it.  I see a cute layout tool  that for practical purposes still doesn't work. I have tried to layout real UIs with it and it is still *easier* to do the layout manually coding to SpringLayout than it is to use Matisse.   I hope that isn't the case when Matisse is released - if it worked it will be very cool.  So far "Bob" is ahead in some areas.  I think if you combine Matisse and Bob you could make a really great UI layout tool.

err... I'll stop ranting now :-)

[Herkules]

Ok, got your point concerning Eclipse and you are right.

Concering SpringLayout, I'm sure there is something missing (e.g baseline support?), so the new one is really needed. I can imagine 1000 reasons. A support for SpringLayout would be nice of course for it is part of the JRE.

Games published by our own members! Check 'em out!

[swpalmer]

Concering SpringLayout, I'm sure there is something missing (e.g baseline support?), so the new one is really needed. I can imagine 1000 reasons.

Baseline support (new to Java 6 anyway) can be added to SpringLayout.  I really can't imagine any good reasons for the new layout manager.  At least not off the top of my head.  But like I say, if the reasons are there, fine, let me know what they are and how the new layout manager was justified.  At this point it just seems absurd that NB still doesn't support the one layout manager specifically designed for use with layout tools.. and then they go off and add a new layout manager which seems to have pretty much identical capablities to SpringLayout.

I must find time to try out the NB profiler... it's crunch time at work though, so playing with other IDEs isn't on the schedule.

[arne]

In NB 4.1 were a bug with using nfs. In Linux NB simply didn't run. As a bugfix for mac (where there was a similar problem) you could simply exchange a jar with a jar from a previous version. (don't know wich ones anymore - would have to look that up) This also worked for Linux. In Windows, NB also got real slow when having projects saved on a server and not on your local hard-disc. If this bugfix would also work there, I don't know.

This is the main reason, why I previosly a NB-user switched to Eclipse, so does anybody know if this will be fixed for NB 4.2 ?

Arne

[Herkules]

New conversation on the SpringLayout topic. Scott, I hope you don't mind me quoting your mails here

http://www.netbeans.org/servlets/ReadMsg?list=nbusers&msgNo=59563

http://www.netbeans.org/servlets/ReadMsg?list=nbusers&msgNo=59589