我看到 ZipInputStream 是从 InflaterInputStream 继承的。后者有一个内部缓冲区。
我看到的大多数代码示例都通过以下方式构建了一个新的 ZipInputStream：
File f = new File("myfile");
FileInputStream fs = new FileInputStream(f);
BufferedInputStream bs = new BufferedInputStream(fs);
ZipInputStream zs = new ZipInputStream(bs);
我读到来自 InflaterInputStream 的子类不需要从 BufferedInputStream 构造，因为它们自己被缓冲。这样对吗？构建 ZipInputStream 的推荐方法是什么？
也许有点上下文，我正在阅读的 zip 文件大小从几 KB 到几 MB 不等。
我只找到了有关如何使用 git 子树拆分存储库的答案。但是，我明确想要子模块。
这是一个 Java Maven 项目。目前，一切都在一个 Maven 项目和一个存储库中。我的目标是实现这样的目标：
根存储库应该包含主要的 pom.xml、系统文档等。然后应该有几个子模块，一个用于实用程序库，一个用于主应用程序，等等。子模块是它们自己的 maven 项目，从根存储库中的主 maven 项目引用。根存储库将不包含任何源代码。
我可以从当前的 HEAD 创建所有新的东西，但对我来说重要的是提交历史尽可能完整。
我编写了一个小词法分析器，将字符缓冲区转换为标记流。一种类型的标记是标识符，它可以是“原始”或关键字。为了测试后者，我有一个填充了所有关键字的地图。
Map<String, MyType> lookup = new HashMap<>();
lookup.put("RETURN", KEYWORD_RETURN);
[...]
地图填充了所有大写字符串。
现在，我从输入 charbuffer 得到的只是一个偏移量和长度，我可以在其中找到我的标识符（不需要大写）。
显而易见的解决方案看起来有点像这样。
bool lookupIdentifier(CharBuffer buffer, int offset, int length, Map<String, MyType> lookupTable) {
int current = buffer.position();
buffer.rewind();
String toCheck = buffer.subSequence(offset, offset + length).toString().toUpperCase();
buffer.position(current);
return lookupTable.containsKey(toCheck);
}
地图中有大约 50 个条目。是TreeMap用不区分大小写的比较良好的替代O（1）HashMap查找？
我不喜欢我的方法是toCheck字符串的创建分配。有没有办法在CharBufferfor 查找中重用子字符串？