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.
Many people complain about complexity of reading content of file in Java. I've even dedicated to this problem one section in the Practical API Design book: http://wiki.apidesign.org/wiki/Extreme_Advice_Considered_Harmful Everyone is waiting for the JDK guys to finally realize the problem and fix it. However NetBeans do not need to wait! We have our FileObjects and we can and we shall fix the problem ourselves.
Created attachment 76183 [details] Three new methods in FileObject
a couple nits... vbk01: The link in the apichange doc for asLines looks like it points to asText. vbk02: having versions of these methods that use the default encoding might be nice... but that is because I am lazy.
JS01: Method asLines() is questionable. It may happen that InputStream will not be closed. You can use Scanner class instead: Scanner scanner = new Scanner(fo.getInputStream()); // or Scanner scanner = new Scanner(fo.asText("UTF-8")); while (scanner.hasNext()) { String line = scanner.nextLine(); ... } scanner.close();
[JG01] Consider removing TestFileUtils.read and replace existing usages with the new method. At the least, deprecate the old method. [JG02] Consider looking for code which could use the new methods and updating it to do so. I'm sure there is plenty. [JG03] asLines seems to ignore the encoding.
Created attachment 76455 [details] Improved patch (no arg methods, buffering of small files, using encoding)
Unless I hear objections, I'd like to integrate the new patch tomorrow.
PH01: I would rather see Charset than String (as a parameter of getText and asLines).
[JG04] Consider making asLines return List<String>, which would be more convenient in certain situations. Otherwise you need to List<String> lines = new ArrayList<String>(); for (String line : file.asLines("UTF-8")) { lines.add(line) } which is a bit annoying. The iterator could still be lazy, of course, but any other List methods would force the whole file to be read if it was not already.
PH01 seems unnecessary to me: - the cases where you would need a live Charset (e.g. loading an XML file of unknown encoding, but not using an XML parser) seem rare, and in such a case you could easily write the file loading code the old way: new String(f.asBytes(), ...) or create a BufferedReader and loop - java.io.* APIs dealing with character sets (e.g. new InputStreamReader(...)) always took a String, only adding Charset as an option in 1.4 - for the common case that you want to load in UTF-8 or ISO-8859-1, you would need an extra call to Charset.forName, making the convenience API less convenient
Created attachment 76542 [details] List<String> asLines() as Jesse requested
New patch addresses almost all comments: JS01: For small files the stream is always read at once and closed. Content is cached. JG01&02: I'll fix something at the time of integration. JG03: Fixed. PH01: I guess that most users want to just read in "UTF-8" formating. For them the current state is simpler. If we need Charset argument, we can add it later. JG04: Changed to return List<String>. It only fast operation is to get an iterator and call next on it, through. Tests ensure the behaviour is at least correct, so there is room for making things faster in the future, if necessary. Let's start next 24h objection period now.
Looks good to me.
core-main#af5ee74674fa
Integrated into 'main-golden', will be available in build *200902060201* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main/rev/af5ee74674fa User: Jaroslav Tulach <jtulach@netbeans.org> Log: #157362: Simplify reading of FileObject's content