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.
I was asked this question from project owner of nbopenlaszlosupport.dev.java.net. When new project is created, warning dialog that "The file xxxx seems to be too large (1 Mb) to safely open ... Opening the file could cause OutOfMemoryError, which would make the IDE unusable. Do you really want to open it?" is invoked. Actually some JavaScript files in the project are large. He wants to avoid the warning because users may not open them because these files are used as just runtime library. It seems that it's called at project scanning for task list at 6.5. Is it possible to change the behavior that invoking the warning just when users try to open it to NetBeans editor?
The dialog is shown only when someone opens the file.
Thank you Jaroslav for evaluation. Which build are you using? I'm trying 200811071401 trunk but it looks the warning is invoked by just opening the project. I'll attach a sample project which contains a large JavaScript file. Could you evaluate it and if there is a way to avoid such warning until opening the file, please let me know.
Created attachment 73605 [details] sample PHP project
This is the stacktrace that leads to the document opening. Looks like the problem is in GSF: org.openide.text.CloneableEditorSupport.prepareDocument(CloneableEditorSupport.java:582) org.openide.text.CloneableEditorSupport.openDocumentImpl(CloneableEditorSupport.java:792) org.openide.text.CloneableEditorSupport.openDocumentCheckIOE(CloneableEditorSupport.java:774) org.openide.text.CloneableEditorSupport.openDocument(CloneableEditorSupport.java:759) org.openide.text.DataEditorSupport.openDocument(DataEditorSupport.java:402) org.netbeans.modules.gsf.spi.GsfUtilities.getDocument(GsfUtilities.java:203) org.netbeans.napi.gsfret.source.ParserTaskImpl.parse(ParserTaskImpl.java:133) org.netbeans.modules.gsfret.source.usages.RepositoryUpdater.batchCompile(RepositoryUpdater.java:2028) org.netbeans.modules.gsfret.source.usages.RepositoryUpdater$CompileWorker.updateFolder(RepositoryUpdater.java:1404) org.netbeans.modules.gsfret.source.usages.RepositoryUpdater$CompileWorker.scanRoots(RepositoryUpdater.java:1129) org.netbeans.modules.gsfret.source.usages.RepositoryUpdater$CompileWorker.access$1900(RepositoryUpdater.java:651) org.netbeans.modules.gsfret.source.usages.RepositoryUpdater$CompileWorker$1.run(RepositoryUpdater.java:789) org.netbeans.modules.gsfret.source.usages.RepositoryUpdater$CompileWorker$1.run(RepositoryUpdater.java:676) org.netbeans.modules.gsfret.source.usages.ClassIndexManager.writeLock(ClassIndexManager.java:107) org.netbeans.modules.gsfret.source.usages.RepositoryUpdater$CompileWorker.run(RepositoryUpdater.java:676) org.netbeans.modules.gsfret.source.usages.RepositoryUpdater$CompileWorker.run(RepositoryUpdater.java:651) org.netbeans.napi.gsfret.source.Source$CompilationJob.run(Source.java:1347) java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441) java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) java.util.concurrent.FutureTask.run(FutureTask.java:138) java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:885) java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:907) java.lang.Thread.run(Thread.java:619)