google / mug Goto Github PK

Is there an equivalent to findFirst() that can return an Optional<Entry<K,V>> or a reason that such a method is not included? The workaround I'm using is limit(1).toMap() followed by an Iterables.getOnlyElement(map.entrySet()) but it'd be nice if this was built in!

Thanks for a great library.

Hi, and thanks for this library - I've had a lot of use out of BiStream in particular.

There seem to be quite a few changes (I'm most interested in BiCollectors) which aren't in 2.2, and there don't seem to be any 2.3-SNAPSHOT versions in any snapshot repository, so just wondering whether this will change soon? Thanks, and apologies if I'm missing something here.

Seems beneficial.

The javadoc linked in the readme is currently 404: https://google.github.io/mug/apidocs/index.html

We have identified 1 possible instance of outdated documentation:

• collect(toBiStream(Substring.first('=') was deleted but the change has not been reflected in the current version of the BiStream Explained wiki page

About

This is part of a research project that aims to automatically detect outdated documentation in GitHub repositories. We are evaluating the validity of our approach by identifying instances of outdated documentation in real-world projects.

We hope that this research will be a step towards keeping documentation up-to-date. If this has been helpful, consider updating the documentation to keep it in sync with the source code. If this has not been helpful, consider updating this issue with an explanation, so that we can improve our approach. Thanks!

I got a red cross while working with eclipse 2019 09

Where ? module mug, src/test/java, com.google.mu.util.stream.BiCollectorsTest.java

@Test public void testFlatMapping_toBiStream() {
    BiStream<String, Integer> salaries = BiStream.of("Joe", 1, "Tom", 2);
    ImmutableListMultimap<String, Integer> result = salaries.collect(
        BiCollectors.flatMapping(
            (k, c) -> BiStream.from(nCopies(c, k), identity(), unused -> c),
            ImmutableListMultimap::toImmutableListMultimap));
    assertThat(result)
        .containsExactly("Joe", 1, "Tom", 2, "Tom", 2)
        .inOrder();
  }

Message : The type of toImmutableListMultimap(Function<? super E,? extends Object>, Function<? super E,? extends Object>) from the type ImmutableListMultimap is Collector<E,?,ImmutableListMultimap<Object,Object>>, this is incompatible with the descriptor's return type: Collector<E,?,Object>

But the build is successful.

Do you get the same error ?

Issue Description:
In the Maybe.java class located within the com.google.mu.util package, several methods exhibit type mismatch errors, which result in red lines appearing in the IntelliJ IDEA editor. This issue affects code readability and could lead to potential runtime errors.

Affected Functions:

public final <X extends Throwable> Stream<T> catching(

The catching method has type-related issues that cause the IntelliJ IDEA editor to display red lines. It appears that the expected type of the returned Stream<T> may not match the actual type inferred by the IDE.

public static <T, E extends Throwable> Stream<Maybe<T, E>> maybeStream(

The maybeStream method also exhibits type mismatch errors. The inferred type of the returned Stream<Maybe<T, E>> may not align with the expected type.

Steps to Reproduce:

Open the Maybe.java class located in the com.google.mu.util package in IntelliJ IDEA.
Navigate to the mentioned functions: catching and maybeStream.
Observe the red lines that indicate type mismatch errors.

Expected Behavior:

The code in the Maybe.java class should have correct type annotations and declarations to ensure that the types inferred by the IDE match the expected types. This will improve code readability and prevent potential runtime issues.

ReadMe says : "A small Java 8 utilities library (javadoc), with 0 deps.", unfortunately compilation with Java 8 gives this error:
"java.lang.UnsupportedClassVersionError: com/google/mu/util/stream/BiStream has been compiled by a more recent version of the Java Runtime (class file version 53.0), this version of the Java Runtime only recognizes class file versions up to 52.0"
In Java 9 or later it works well. Can you get Java 8 support?

Hello,

I'm trying to create a BiStream<byte[], byte[]> from a RocksIterator (RocksDB).

It can be done with two RocksIterators and the BiStream.zip(...) method. But this feels insecure because you have 2 iterator states, which can vary.

Another way is to create a Iterator<Map.Entry<byte[], byte[]>> and wrap it in a Stream<Map.Entry<byte[], byte[]>>. Inside the BiStream class is a constructor and a method (BiStream.form()) for this kind of stream, but both of them are not public.

Leaving us with BiStream.biStream(entryStream).mapKeys(Map.Entry::getKey).mapValues(Map.Entry::getValue) (a short version of this would also be nice). This creates additional intermediate Map.Entry objects, which are unnecessary in this case.

Are there other ways to create a new BiStream?

Since the 3-arg version of from is deprecated, we are left with doing this:

Map<K,V> foo;
biStream(Map.Entry::getKey, foo.entrySet().parallelStream())
  .mapValues(Map.Entry::getValue)
...

which doesn't have the immediate translation of code to intent that one might like.

Some options:

1. Bring back BiStream.from(stream, toKey, toValue) (not sure why this was ever deprecated in the first place)
2. Create parallel versions of from; eg. BiStream.parallelFrom(Map)
3. Add a parallelize flag to the existing methods

Internally, we haven't seen any legit use case for it.

Hello,

Sorting a BiStream seems to be giving odd output that looks like a bug. Here is a test case that exhibits the issue:

  @Test
  public void test() {
    BiStream.from(
        ImmutableMap.of(
            "key-a", 1,
            "key-b", 1))
    .mapValues((k, v) -> v * 10)
    .sortedByValues(Integer::compare)
    .forEach((k, v) -> System.out.println(k + " " + v));
  }

I would expect output:

key-a 10
key-b 10

but the printed output is:

key-b 10
key-b 10

Both the sort and the map call are necessary for this to manifest. The same behavior occurs if I use sortedByKeys(String::compareTo). Do you have any suggestions about where things are going wrong?

Thanks!

Example:

// A.java
StringFormat format = new StringFormat("{foo}/{bar}-{baz}");

// B.java
format.parse(input, (foo, bar) -> ...);

// C.java
format.format("x", "y");

Seems easy to mess up?

CVE-2020-8908

Recommended upgrade version：30.0-jre

@fluentfuture Currently, the tests use a combination of JUnit 4 and JUnit 5 annotations which don't seem to follow the advice laid out in the JUnit 5 User Guide. I fear that this may make the tests, as they stand, prone to bugs and difficult to maintain over time.

The following sections from the JUnit 5 User Guide look like good starting points for resolving this issue:

• http://junit.org/junit5/docs/current/user-guide/#running-tests-junit-platform-runner
• http://junit.org/junit5/docs/current/user-guide/#migrating-from-junit4

It would be beneficial for OSGi users to have this library installed directly in the OSGi runtimes if the OSGi metadata is provided in its MANIFEST.MF.

The readme links to https://google.github.io/mug/mug-protobuf/apidocs and https://google.github.io/mug/mug-guava/apidocs/index.html, both of which are broken.

Hello,

I have a question, why does MoreStreams.dice limits the chunk size if the stream is infinite? What is the reasoning behind limiting only for infinite streams and not for all streams?