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.
Product Version: NetBeans IDE Dev (Build 200803190008) Java: 1.6.0_04; Java HotSpot(TM) Client VM 10.0-b19 System: Linux version 2.6.24-12-generic running on i386; UTF-8; en_US (nb) Click File > New Project, select Java > Java Desktop Application, click Next. Fill in a project name "*" and click Finish. You have just created a project with a name "*". You can also create a project called "////" - so you cannot enter an empty project name, but you can emulate entering an empty name easily this way. If you enter "\\*..\..\.." as a project name, you get an exception (see stack trace). I think this incorrect naming must not be possible, as well as TS_61_JDA test specification thinks. I raise the priority of this issue to P2, decrease it if needed, but I think this should be fixed (users do not like when they are allowed to do stupid things).
Created attachment 58681 [details] stack trace
Hmm, this is strange. I'm not able to use "\", "\\*..\..\.." or "*" in project name textfield. Validation works and I'm not able to press Finish button. Maybe this is linux specific issue? Lowering to P3, maybe P4 will be better. ;) Product Version: NetBeans IDE Dev (Build 200803200007) Java: 1.6.0_10-beta; Java HotSpot(TM) Client VM 11.0-b11 System: Windows XP version 5.1 running on x86; Cp1250; cs_CZ (nb)
Well, you are right that a project creation is rather a rare event. I do not know if it is a Linux specific issue, but it is still reproducible in build 200803210006, I have just tested it. Project name can contain slashes, back-slashes, stars and dots... (Why the hell should it be an OS specific issue? ;-)) I can agree with P3, but P4 would be little too much (even for the 5 users who use netbeans on Linux;)).
> (Why the hell should it be an OS specific issue? ;-)) Because it seems to work correctly on Windows. > I can agree with P3, but P4 would be little too much (even for the 5 users who use netbeans on Linux;)). I doubt there is (at least) one external user worried by this issue because the described use-case does not have a sense. This is a typical issue encountered by QA folks only. Hence, lowering the priority to P4 (as jvagner suggested correctly).
> This is a typical issue encountered by QA folks only. Well, no news. We were just discussing the same stuff here. How many projects do you create when you really work with Java? One.. maybe two a year? Anything related to project creation might be just thrown away as a P4 then... > Because it seems to work correctly on Windows. Yes, but this is not what was my remark about. I do not see the point: why the real implementation of a project name validation should be OS specific? If you write some function returning a bool, why don't you implement it the same way for all OS? Pseudocode: bool validate(string S) { foreach (char C in S) { if (!addmisible(C)) return FALSE; } return TRUE; } You probably just use some OS dependent mechanism that returns you bool according to the validity of the path in the particular OS (dependent on the way OS works with files). But THIS HAS NO LOGIC, as you are setting up the PROJECT!!! name, not a PATH where to save files (of course, you implement the name of the project in means of the path). Therefore I think that the admissible string should be the same for any OS, it should be restricted to [a-zA-Z0-9-_]*. Not only because I know the attitude of dev-guys to P4 issues, I still think the issue should have a P3 priority so that it gets fixed one day (is the fix really so hard??? Does it take more than 10 minutes of your time? Why do we need developers with this attitude to submitted issues? :o)). There is incorrect validation of a users input, the current implementation does not pass the test specification -> I would suggest P3. I will leave a P4 though. Furthermore, I don't see the reason why I should not write for example "../../MyProject" if the validation passes??? The extreme examples I gave in the first desc are QA folks specific, but this one?
Closing an old bug related to Swing Application Framework, no longer supported.