| commit | 1370e8f34be27a66c4560e23c17bf7c87fba7229 | [log] [tgz] |
|---|---|---|
| author | cpovirk <cpovirk@google.com> | Fri Oct 04 12:44:16 2019 -0700 |
| committer | Chris Povirk <beigetangerine@gmail.com> | Fri Oct 04 16:22:56 2019 -0400 |
| tree | 75c3d44de40585e4010865c6d3926b71f0fb4c92 | |
| parent | e8a24aa250bd49d1744753929e49e1cd10f816cf [diff] |
Prepare Javadoc for Java 11, and make other improvements: - Move nearly all Javadoc configuration to the parent POM. - Update Guava and ICU4J link locations. The current links resolve to the Javadoc -- but only after a redirect, which Javadoc doesn't like: https://bugs.openjdk.java.net/browse/JDK-8190312 - Update maven-javadoc-plugin to 3.1.1. (This version knows how to work around the aforementioned redirect problem, should it happen again.) - Add links to Checker Framework. For some reason, this isn't working under Java 11. I haven't investigated. - Disable detectJavaApiLink, and fill in https://docs.oracle.com/javase/9/docs/api/ for Java 8 and https://docs.oracle.com/en/java/javase/11/docs/api/ for newer versions. (I've tested only with Java 8 and 11, so hopefully the "newer versions" behavior is OK for 9 and 10.) It does look like it may be necessary to duplicate all the links in 3 places :\ This is all in service of preventing: [ERROR] Exit code: 1 - javadoc: error - The code being documented uses modules but the packages defined in https://docs.oracle.com/javase/9/docs/api/ are in the unnamed module. Traditionally we solve this problem by setting <source>8</source> on Javadoc (CL 235241314, CL 236159968). That would probably work here, but I've been experimenting with <source>9</source> (for proper modules support in jimfs), so that might not be an option soon. Or maybe it still would be, but I'd have to exclude module-info.java, but then I wonder if that will trigger modules problems? In any case, it seems more future-proof to solve this the right(?) way. ------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=272937179
Jimfs is an in-memory file system for Java 7 and above, implementing the java.nio.file abstract file system APIs.
The latest release is 1.1.
It is available in Maven Central as com.google.jimfs:jimfs:1.1:
<dependency> <groupId>com.google.jimfs</groupId> <artifactId>jimfs</artifactId> <version>1.1</version> </dependency>
The simplest way to use Jimfs is to just get a new FileSystem instance from the Jimfs class and start using it:
import com.google.common.jimfs.Configuration; import com.google.common.jimfs.Jimfs; ... // For a simple file system with Unix-style paths and behavior: FileSystem fs = Jimfs.newFileSystem(Configuration.unix()); Path foo = fs.getPath("/foo"); Files.createDirectory(foo); Path hello = foo.resolve("hello.txt"); // /foo/hello.txt Files.write(hello, ImmutableList.of("hello world"), StandardCharsets.UTF_8);
Jimfs supports almost all the APIs under java.nio.file. It supports:
FileChannel or SeekableByteChannel, InputStream, OutputStream, etc.SecureDirectoryStream, for operations relative to an open directory.PathMatcher.WatchService.Jimfs also supports creating file systems that, for example, use Windows-style paths and (to an extent) behavior. In general, however, file system behavior is modeled after UNIX and may not exactly match any particular real file system or platform.
Copyright 2013 Google Inc.
Licensed under the Apache License, Version 2.0 (the "License");
you may not use this file except in compliance with the License.
You may obtain a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.