I've been working on removing a lot of the cruft from the code. Things that aren't needed like the entire huge RT class, a lot dead code in the implementation.

While I am at it, I've been moving towards an api NOT designed by a compiler writer ;)

Please take a look and let me know what you think!

https://github.com/grignaak/clj-ds/tree/java-api

I'd like to be able to use this library more conveniently from other libraries, but that means (in practice) putting it in maven central.

I'd be happy to do one of the following:

1. Convert the build to maven

or

2. Maintain a package in maven central (which I'll do by maintaining a mavenized version, same code, slightly diff roject layout and add a pom)

hi karl,

i did merge clojure 1.5.1 in clj-ds. it is quite "raw". i have change the snapshot version to 0.0.2-SNAPSHOT.

some remark:

• they added a new iterator for PersitentVector. I have named the method iterator151() and let your own version be the used version.
• I did not add the diverse new interfaces like IHashEq to the TRIES classes that you have written.
• not a lot changed. some 'throws Exception' are away and some tuning was done in PersistentVector.

what do you think?

cheers! stan.

Hi,

what's the idiomatic way of creating a set of some elements, checking if the set contains something and iterating over it? I've run into a couple issues there:

1. IPersistenSet.cons returns IPersistentCollection, and it's impossible to call contains without casting.
2. IPersistentSet doesn't implement Iterable, explicit casting required here as well.

Is it by design, or something to fix? The first issue would be fixed very easily, the second one is trickier as APersistentSet and APersistentTrie (both implementing IPersistentSet) would have to have different Iterable type parameters.

I am not able to use

PersistentList empty = PersistentList.emptyList()

as it gives following error

required: PersistentList found: IPersistentList where T is a type-variable: T extends Object declared in method emptyList()

I am not able to fix this in the source. Can you please fix this?

A number of the public collection modification methods were returning the type of their interface, rather than their concrete type.

For example, PersistentTreeSet.cons returned IPersistentSet, even though it always returns a PersistentTreeSet. This property makes these data structures a lot harder to work with in Java, as users must continually cast return values of these methods.

Attached commits strengthen the return types of such methods.

Change converts the build to maven and adds the incantations to the pom to allow pushing snapshots and releases into the sonatype open source repo, which syncs to maven central.

Hi Karl,

I had to make a bit annoying change in ITransientVector in order to create the TransientVector interface. But I think it is unavoidable.

cheers! stan.

Fix dissoccing colliding values in a transient hashmap (CLJ-829)

This bug, detailed in http://dev.clojure.org/jira/browse/CLJ-829, causes behavior wherein dissoc'ing a value with a colliding hashcode from a transient map causes the persistent map from which it was based to be modified as well.

Bumps junit from 4.8.2 to 4.13.1.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

• Want to take over the Java ecosystem? All you need is a MITM!
• Update: Want to take over the Java ecosystem? All you need is a MITM!

This is a security fix for a vulnerability in your Apache Maven pom.xml file(s).

The build files indicate that this project is resolving dependencies over HTTP instead of HTTPS. This leaves your build vulnerable to allowing a Man in the Middle (MITM) attackers to execute arbitrary code on your or your computer or CI/CD system.

This vulnerability has a CVSS v3.0 Base Score of 8.1/10.

POC code has existed since 2014 to maliciously compromise a JAR file in-flight. MITM attacks against HTTP are increasingly common, for example Comcast is known to have done it to their own users.

This contribution is a part of a submission to the GitHub Security Lab Bug Bounty program.

Detecting this and Future Vulnerabilities

This vulnerability was automatically detected by LGTM.com using this CodeQL Query.

As of September 2019 LGTM.com and Semmle are officially a part of GitHub.

You can automatically detect future vulnerabilities like this by enabling the free (for open-source) LGTM App.

I'm not an employee of GitHub nor of Semmle, I'm simply a user of LGTM.com and an open-source security researcher.

Source

Yes, this contribution was automatically generated, however, the code to generate this PR was lovingly hand crafted to bring this security fix to your repository.

The source code that generated and submitted this PR can be found here: JLLeitschuh/bulk-security-pr-generator

Opting-Out

If you'd like to opt-out of future automated security vulnerability fixes like this, please consider adding a file called .github/GH-ROBOTS.txt to your repository with the line:

User-agent: JLLeitschuh/bulk-security-pr-generator
Disallow: *

This bot will respect the ROBOTS.txt format for future contributions.

Alternatively, if this project is no longer actively maintained, consider archiving the repository.

CLA Requirements

This section is only relevant if your project requires contributors to sign a Contributor License Agreement (CLA) for external contributions.

It is unlikely that I'll be able to directly sign CLAs. However, all contributed commits are already automatically signed-off.

The meaning of a signoff depends on the project, but it typically certifies that committer has the rights to submit this work under the same license and agrees to a Developer Certificate of Origin (see https://developercertificate.org/ for more information).

- Git Commit Signoff documentation

If signing your organization's CLA is a strict-requirement for merging this contribution, please feel free to close this PR.

Tracking

All PR's generated as part of this fix are tracked here: https://github.com/JLLeitschuh/bulk-security-pr-generator/issues/2

Hi, I've come across a bug involving iterators for PersistentVectors. The test follows. It happens when you iterate over a vector of length >= 33, but without calling the iterator's "hasNext()" method. (There is no requirement that the hasNext be called if you are sure there is a next element, as far as I know.) If you call the hasNext() method in each iteration the problem goes away.

package edu.udel.cis.vsl.sarl.collections;

import java.util.Iterator; import org.junit.Test; import com.github.krukow.clj_ds.PersistentVector; import com.github.krukow.clj_ds.Persistents;

public class PersistentVectorTest {

private PersistentVector<Integer> makeVec(int n) {
    PersistentVector<Integer> pv = Persistents.vector();

    for (int i = 0; i < n; i++)
        pv = pv.plus(i);
    return pv;
}

private void check(int n) {
    PersistentVector<Integer> pv = makeVec(n);
    Iterator<Integer> iter = pv.iterator();

    for (int i = 0; i < n; i++)
        System.out.println(iter.next());
}

@Test
public void test() {
    check(33);
}

}

java.lang.ArrayIndexOutOfBoundsException: 32 at com.github.krukow.clj_lang.PersistentVector$PersistentVectorIterator.next(PersistentVector.java:370) at edu.udel.cis.vsl.sarl.collections.PersistentVectorTest.check(PersistentVectorTest.java:25) at edu.udel.cis.vsl.sarl.collections.PersistentVectorTest.test(PersistentVectorTest.java:30) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:601) at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47) at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44) at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17) at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50) at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238) at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63) at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236) at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53) at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229) at org.junit.runners.ParentRunner.run(ParentRunner.java:309) at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:50) at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:197)

Occasionally, PersistentHashMap's entry iterator will return an entry whose key and value are both null.

Running my test case in the debugger, I can see that the map's hasNull value is set to false. Additionally, my code never assocs a null key or value into the map. Running the same test case with PersistentHashMap.iterator2 (the original recursive Seq implementation from Clojure) does not produce entries with null keys or values.

Unfortunately, I don't have a minimal test case at this time. I'm starting this issue as a placeholder, in case you have or someone else has a good idea of what's going wrong.

Thoughts?