commit | a8489ffa85dfab937dcc9e8d59904cefc4331f31 | [log] [tgz] |
---|---|---|
author | cpovirk <cpovirk@google.com> | Thu Oct 03 12:49:27 2019 -0700 |
committer | Chris Povirk <beigetangerine@gmail.com> | Fri Oct 04 12:12:19 2019 -0400 |
tree | 9e69a1543e2bae66e565a4f3a6f16e2b8653a29d | |
parent | d4339f8f3de2a2bb903d8b1149e7d27642fda833 [diff] |
Use AutoService as a proper annotation processor. I was going to say that this also paves the way for including the annotation as a non-optional dependency, should we wish to follow our Guava precedent for annotations: - https://github.com/google/guava/issues/2824 - https://github.com/google/guava/issues/2721 But I see that it's retention=SOURCE anyway, so there isn't much reason to do that -- except maybe consistency with other annotation packages someday. (Maybe it's still a negative then, as it might still let people rely on our transitive dependency?) I think the relationship of all this to Java 11 was that I might have to set an Automatic-Module-Name on AutoService, and it makes more sense to set it after we've done the processor-vs.-annotation artifact split. Once I was upgrading, it made sense to set up the annotation processor the Right Away, now that we're using a version in which that works. (Or maybe it always worked but now it's nice that it gets the processor off the classpath?) Or maybe there was some other reason for the change to the annotation-processor setup; once again, I forget. It looks like it might have been that AutoService stops running when I switch how we run Error Prone. Hopefully this was the solution :) But it's probably a good idea in any case. This CL is basically following the "alternatively" instructions in https://github.com/google/auto/blob/master/value/userguide/index.md#in-pomxml ...even though the AutoService instructions haven't been similarly updated yet: https://github.com/google/auto/tree/master/service#download ------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=272720556
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.