High Performance data structures and utility methods for Java



Javadocs GitHub

Actions Status Total Alerts Code Quality: Java

Agrona provides a library of data structures and utility methods that are a common need when building high-performance applications in Java. Many of these utilities are used in the Aeron efficient reliable UDP unicast, multicast, and IPC message transport and provides high-performance buffer implementations to support the Simple Binary Encoding Message Codec.

For the latest version information and changes see the Change Log.

The latest release and downloads can be found in Maven Central.

Utilities Included:

  • Buffers - Thread safe direct and atomic buffers for working with on and off heap memory with memory ordering semantics.
  • Lists - Array backed lists of int/long primitives to avoid boxing.
  • Maps - Open addressing and linear probing with int/long primitive keys to object reference values.
  • Maps - Open addressing and linear probing with int/long primitive keys to int/long values.
  • Sets - Open addressing and linear probing for int/long primitives and object references.
  • Cache - Set Associative with int/long primitive keys to object reference values.
  • Clocks - Clock implementations to abstract system clocks, allow caching, and enable testing.
  • Queues - Lock-less implementations for low-latency applications.
  • Ring/Broadcast Buffers - implemented off-heap for IPC communication.
  • Simple Agent framework for concurrent services.
  • Signal handling to support "Ctrl + c" in a server application.
  • Scalable Timer Wheel - For scheduling timers at a given deadline with O(1) register and cancel time.
  • Code generation from annotated implementations specialised for primitive types.
  • Off-heap counters implementation for application telemetry, position tracking, and coordination.
  • Implementations of InputStream and OutputStream that can wrap direct buffers.
  • DistinctErrorLog - A log of distinct errors to avoid filling disks with existing logging approaches.


Java Build

The project is built with Gradle using this build.gradle file.

You require the following to build Agrona:

  • The Latest release of Java 8. Agrona is tested with Java 8, 11, 15 and 16-ea.

Full clean, build, and install into local maven repository

$ ./gradlew

License (See LICENSE file for full license)


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


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.

  • Controlled poll from queue

    Controlled poll from queue

    More of a question than an issue...how would I go about using an Agrona queue's element's contents to control consumption ?

    The idea is to offer items to a queue to preserve their order, kick off async enrichment of the items and then only consume once enrichments have completed. I'd use a putOrderedObject to issue a store-store fence for the enrichments to ensure they were visible on the poll.

    I suspect there is a more elegant way to approach this problem, but the extension to OneToOne queue below seems to work. Thoughts/improvements/suggestions appreciated.

    public E poll(Predicate<E> predicate) {
            final Object[] buffer = this.buffer;
            final long currentHead = head;
            final long elementOffset = sequenceToBufferOffset(currentHead, capacity - 1);
            final Object e = UNSAFE.getObjectVolatile(buffer, elementOffset);
            if (null != e && predicate.test((E) e))
                UNSAFE.putOrderedObject(buffer, elementOffset, null);
                UNSAFE.putOrderedLong(this, HEAD_OFFSET, currentHead + 1);
                return (E)e;
            return null;
    opened by benwimpory 18
  • Long2LongHashMap.keySet().iterator().next() returns self

    Long2LongHashMap.keySet().iterator().next() returns self

    FindBugs has a dedicated check for this pattern because it was employed in OpenJDK and emulated in many other places (it has already been fixed in OpenJDK). The trick which saves from emitting garbage also breaks code such as new ArrayList<>(map.entrySet()). AFAIK Java 8 has significantly improved Escape Analysis so a safe implementation should still be garbage-free in most usages.



    opened by mtopolnik 15
  • Increase performance of OneToOneRingBuffer...

    Increase performance of OneToOneRingBuffer...

    … by eliminating setMemory during read.

    The call to setMemory was used by the reader to zero the bytes of all read messages so that subsequently written variable length messages are guaranteed to be followed by a zero length record header. The reader observes this zero length record header to efficiently detect when to stop reading.

    The responsibility for each message to be followed by a zero length record header is now shifted to the writer, which already knows the precise location of the end of each message record.

    The reader now no longer writes a block of zeros to the record buffer during read.

    The writer requires each message to be followed by a zero length record header, even when the ring buffer is full, so the total capacity is reduced by the size of a record header (8 bytes).

    opened by jfallows 14
  • Will IntArrayList be added in the future?

    Will IntArrayList be added in the future?

    I was wondering if primitive support for List is going to be added, it might not be very common and you could argue that a Set could do but sometimes you are just transferring a List of IDs and you know they are unique.

    I was using Agrona but because it was missing IntList support I had to switch to FastUtil v7.x though it is too big for my needs.

    opened by guidomedina 14
  • TimerWheel usually ignores Timers execution if tickDuration is more than 1ns

    TimerWheel usually ignores Timers execution if tickDuration is more than 1ns

    Looks like currently TimerWheel is effectively broken.


    int TICK_PERIOD_NS = 10;
    int TIMEOUT_NS = 12;
    controlTimestamp = 0;
    final AtomicLong firedTimestamp = new AtomicLong(-1);
    final TimerWheel wheel = new TimerWheel(this::getControlTimestamp, 12, TimeUnit.NANOSECONDS, 8);
    final Runnable task = () -> firedTimestamp.set(wheel.clock().nanoTime());
    final TimerWheel.Timer timer1 = wheel.newTimeout(TIMEOUT_NS, TimeUnit.NANOSECONDS, task);
    assertEquals("Nothing expired on 10 timestamp", 0, wheel.expireTimers()); //which is fine
    controlTimestamp = 10;
    assertEquals("Nothing expired on 10 timestamp", 0, wheel.expireTimers()); //mmm... 12 should be here
    controlTimestamp = 20;
    assertEquals("Nothing expired on 20 timestamp... it's already definitely an error", 0, wheel.expireTimers());

    This test pass. So... tick is 10ns. We schedule execution on 12ns timestamp. Nothing executed on 10ns, nothing executed on 20ns. You can put any value in TICK_PERIOD_NS which % TICK_PERIOD_NS != 0.



    if (0 >= timer.remainingRounds)
        timer.state = TimerState.EXPIRED;
        if (now >= timer.deadline)
        final long calculatedIndex = deadline / tickDurationInNs;

    So... we schedule Timer to tick number in the "floor" div mode and after that we usually get now <= timer.deadline() if now is around right tick time. As a result - we mark Timer as Expired and do nothing + remove it with timer.remove().


    1. Main one. Stop double check deadline value. In any inaccuracy of external scheduler that makes a call of expireTimers() a bit earlier - Timers execution will be postponed additionally for ticksPerWheel * tickDurationNs. So deadline should be used only to determine tickIndex and for nothing more.

    WheelTimer already depends on the external scheduler accuracy, because it fully depends on triggering ticks more or less on right intervals outside. So, it should be fine to check only remainingRounds on current tick.

    if (0 >= timer.remainingRounds)
        timer.state = TimerState.EXPIRED;
    1. Now we schedule to ticks by division in "floor" mode. For current implementation with deadline, scheduling would be safer in the "ceiling" mode. But, after implementing 1), we should assign the nearest tick as it should be done according to the idea of HashedWheelTimer.
    //IntMath is a guava class, just to reference what do I mean
    final long calculatedIndex = IntMath.divide(deadline, tickDurationInNs, RoundingMode.HALF_DOWN);

    *) Another approach to fix design - stop doing currentTick++; on each expireTimers() invocation and rework tick triggering logic. So, when we trigger expireTimers() outside - we calculate how much ticks passed since previous execution using clock and expire-run all Timers in passed ticks. This is even better, because we stop to be dependent on accuracy of external scheduler not in terms of frequency, but in terms of accuracy and things like STW pauses which could cause ticks loosing.

    And one more note about this code: now >= timer.deadline is fine if we work with milliseconds. But incorrect for nanoseconds because of long overflow. The only correct way to compare nanosecond timestamps is: now - timer.deadline >= 0

    opened by Spikhalskiy 13
  • Java 9 illegal reflective access warning

    Java 9 illegal reflective access warning

    I'm quite sure it can be ignored for a time, but reporting it anyway:

    WARNING: An illegal reflective access operation has occurred
    WARNING: Illegal reflective access by org.agrona.IoUtil (file:/home/signals/green-engine-runner/scripts/aeron/repo/agrona-0.9.7.jar) to method sun.nio.ch.FileChannelImpl.map0(int,long,long)
    WARNING: Please consider reporting this to the maintainers of org.agrona.IoUtil
    opened by guidomedina 12
  • javadoc issue

    javadoc issue

    [ /opt/Agrona ]# ./gradlew --stacktrace :clean :compileJava :processResources UP-TO-DATE :classes :generatePrimitiveExpansions Generated LongLongConsumer Generated LongArrayList Generated LongIterator Generated Long2LongHashMap Generated LongHashSet Generated LongLruCache Generated Long2ObjectCache Generated Long2ObjectHashMap :compileGeneratedJava :processGeneratedResources UP-TO-DATE :generatedClasses :jar :javadocjavadoc: error - invalid flag: -quıet

    Usage: javadoc [options] [packagenames] [sourcefiles] [@files] -overview Read overview documentation from HTML file -public Show only public classes and members -protected Show protected/public classes and members (default) -package Show package/protected/public classes and members -private Show all classes and members -help Display command line options and exit -doclet Generate output via alternate doclet -docletpath Specify where to find doclet class files -sourcepath Specify where to find source files -classpath Specify where to find user class files -cp Specify where to find user class files -exclude Specify a list of packages to exclude -subpackages Specify subpackages to recursively load -breakiterator Compute first sentence with BreakIterator -bootclasspath Override location of class files loaded by the bootstrap class loader -source Provide source compatibility with specified release -extdirs Override location of installed extensions -verbose Output messages about what Javadoc is doing -locale Locale to be used, e.g. en_US or en_US_WIN -encoding Source file encoding name -quiet Do not display status messages -J Pass directly to the runtime system -X Print a synopsis of nonstandard options and exit

    Provided by Standard doclet: -d Destination directory for output files -use Create class and package usage pages -version Include @version paragraphs -author Include @author paragraphs -docfilessubdirs Recursively copy doc-file subdirectories -splitindex Split index into one file per letter -windowtitle Browser window title for the documentation -doctitle Include title for the overview page -header Include header text for each page -footer Include footer text for each page -top Include top text for each page -bottom Include bottom text for each page -link Create links to javadoc output at -linkoffline Link to docs at using package list at -excludedocfilessubdir :.. Exclude any doc-files subdirectories with given name. -group :.. Group specified packages together in overview page -nocomment Suppress description and tags, generate only declarations. -nodeprecated Do not include @deprecated information -noqualifier ::... Exclude the list of qualifiers from the output. -nosince Do not include @since information -notimestamp Do not include hidden time stamp -nodeprecatedlist Do not generate deprecated list -notree Do not generate class hierarchy -noindex Do not generate index -nohelp Do not generate help link -nonavbar Do not generate navigation bar -serialwarn Generate warning about @serial tag -tag ::

    Specify single argument custom tags -taglet The fully qualified name of Taglet to register -tagletpath The path to Taglets -charset Charset for cross-platform viewing of generated documentation. -helpfile Include file that help link links to -linksource Generate source in HTML -sourcetab Specify the number of spaces each tab takes up in the source -keywords Include HTML meta tags with package, class and member info -stylesheetfile File to change style of the generated documentation -docencoding Specify the character encoding for the output 1 error :javadoc FAILED

    FAILURE: Build failed with an exception.

    • What went wrong: Execution failed for task ':javadoc'.

      Javadoc generation failed. Generated Javadoc options file (useful for troubleshooting): '/opt/Agrona/build/tmp/javadoc/javadoc.options'

    • Try: Run with --info or --debug option to get more log output.

    • Exception is: org.gradle.api.tasks.TaskExecutionException: Execution failed for task ':javadoc'. at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.executeActions(ExecuteActionsTaskExecuter.java:69) at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.execute(ExecuteActionsTaskExecuter.java:46) at org.gradle.api.internal.tasks.execution.PostExecutionAnalysisTaskExecuter.execute(PostExecutionAnalysisTaskExecuter.java:35) at org.gradle.api.internal.tasks.execution.SkipUpToDateTaskExecuter.execute(SkipUpToDateTaskExecuter.java:66) at org.gradle.api.internal.tasks.execution.ValidatingTaskExecuter.execute(ValidatingTaskExecuter.java:58) at org.gradle.api.internal.tasks.execution.SkipEmptySourceFilesTaskExecuter.execute(SkipEmptySourceFilesTaskExecuter.java:52) at org.gradle.api.internal.tasks.execution.SkipTaskWithNoActionsExecuter.execute(SkipTaskWithNoActionsExecuter.java:52) at org.gradle.api.internal.tasks.execution.SkipOnlyIfTaskExecuter.execute(SkipOnlyIfTaskExecuter.java:53) at org.gradle.api.internal.tasks.execution.ExecuteAtMostOnceTaskExecuter.execute(ExecuteAtMostOnceTaskExecuter.java:43) at org.gradle.execution.taskgraph.DefaultTaskGraphExecuter$EventFiringTaskWorker.execute(DefaultTaskGraphExecuter.java:203) at org.gradle.execution.taskgraph.DefaultTaskGraphExecuter$EventFiringTaskWorker.execute(DefaultTaskGraphExecuter.java:185) at org.gradle.execution.taskgraph.AbstractTaskPlanExecutor$TaskExecutorWorker.processTask(AbstractTaskPlanExecutor.java:66) at org.gradle.execution.taskgraph.AbstractTaskPlanExecutor$TaskExecutorWorker.run(AbstractTaskPlanExecutor.java:50) at org.gradle.execution.taskgraph.DefaultTaskPlanExecutor.process(DefaultTaskPlanExecutor.java:25) at org.gradle.execution.taskgraph.DefaultTaskGraphExecuter.execute(DefaultTaskGraphExecuter.java:110) at org.gradle.execution.SelectedTaskExecutionAction.execute(SelectedTaskExecutionAction.java:37) at org.gradle.execution.DefaultBuildExecuter.execute(DefaultBuildExecuter.java:37) at org.gradle.execution.DefaultBuildExecuter.access$000(DefaultBuildExecuter.java:23) at org.gradle.execution.DefaultBuildExecuter$1.proceed(DefaultBuildExecuter.java:43) at org.gradle.execution.DryRunBuildExecutionAction.execute(DryRunBuildExecutionAction.java:32) at org.gradle.execution.DefaultBuildExecuter.execute(DefaultBuildExecuter.java:37) at org.gradle.execution.DefaultBuildExecuter.execute(DefaultBuildExecuter.java:30) at org.gradle.initialization.DefaultGradleLauncher$4.run(DefaultGradleLauncher.java:153) at org.gradle.internal.Factories$1.create(Factories.java:22) at org.gradle.internal.progress.DefaultBuildOperationExecutor.run(DefaultBuildOperationExecutor.java:91) at org.gradle.internal.progress.DefaultBuildOperationExecutor.run(DefaultBuildOperationExecutor.java:53) at org.gradle.initialization.DefaultGradleLauncher.doBuildStages(DefaultGradleLauncher.java:150) at org.gradle.initialization.DefaultGradleLauncher.access$200(DefaultGradleLauncher.java:32) at org.gradle.initialization.DefaultGradleLauncher$1.create(DefaultGradleLauncher.java:98) at org.gradle.initialization.DefaultGradleLauncher$1.create(DefaultGradleLauncher.java:92) at org.gradle.internal.progress.DefaultBuildOperationExecutor.run(DefaultBuildOperationExecutor.java:91) at org.gradle.internal.progress.DefaultBuildOperationExecutor.run(DefaultBuildOperationExecutor.java:63) at org.gradle.initialization.DefaultGradleLauncher.doBuild(DefaultGradleLauncher.java:92) at org.gradle.initialization.DefaultGradleLauncher.run(DefaultGradleLauncher.java:83) at org.gradle.launcher.exec.InProcessBuildActionExecuter$DefaultBuildController.run(InProcessBuildActionExecuter.java:99) at org.gradle.tooling.internal.provider.ExecuteBuildActionRunner.run(ExecuteBuildActionRunner.java:28) at org.gradle.launcher.exec.ChainingBuildActionRunner.run(ChainingBuildActionRunner.java:35) at org.gradle.launcher.exec.InProcessBuildActionExecuter.execute(InProcessBuildActionExecuter.java:48) at org.gradle.launcher.exec.InProcessBuildActionExecuter.execute(InProcessBuildActionExecuter.java:30) at org.gradle.launcher.exec.ContinuousBuildActionExecuter.execute(ContinuousBuildActionExecuter.java:81) at org.gradle.launcher.exec.ContinuousBuildActionExecuter.execute(ContinuousBuildActionExecuter.java:46) at org.gradle.launcher.exec.DaemonUsageSuggestingBuildActionExecuter.execute(DaemonUsageSuggestingBuildActionExecuter.java:51) at org.gradle.launcher.exec.DaemonUsageSuggestingBuildActionExecuter.execute(DaemonUsageSuggestingBuildActionExecuter.java:28) at org.gradle.launcher.cli.RunBuildAction.run(RunBuildAction.java:43) at org.gradle.internal.Actions$RunnableActionAdapter.execute(Actions.java:173) at org.gradle.launcher.cli.CommandLineActionFactory$ParseAndBuildAction.execute(CommandLineActionFactory.java:239) at org.gradle.launcher.cli.CommandLineActionFactory$ParseAndBuildAction.execute(CommandLineActionFactory.java:212) at org.gradle.launcher.cli.JavaRuntimeValidationAction.execute(JavaRuntimeValidationAction.java:35) at org.gradle.launcher.cli.JavaRuntimeValidationAction.execute(JavaRuntimeValidationAction.java:24) at org.gradle.launcher.cli.ExceptionReportingAction.execute(ExceptionReportingAction.java:33) at org.gradle.launcher.cli.ExceptionReportingAction.execute(ExceptionReportingAction.java:22) at org.gradle.launcher.cli.CommandLineActionFactory$WithLogging.execute(CommandLineActionFactory.java:205) at org.gradle.launcher.cli.CommandLineActionFactory$WithLogging.execute(CommandLineActionFactory.java:169) at org.gradle.launcher.Main.doAction(Main.java:33) at org.gradle.launcher.bootstrap.EntryPoint.run(EntryPoint.java:45) at org.gradle.launcher.bootstrap.ProcessBootstrap.runNoExit(ProcessBootstrap.java:55) at org.gradle.launcher.bootstrap.ProcessBootstrap.run(ProcessBootstrap.java:36) at org.gradle.launcher.GradleMain.main(GradleMain.java:23) at org.gradle.wrapper.BootstrapMainStarter.start(BootstrapMainStarter.java:30) at org.gradle.wrapper.WrapperExecutor.execute(WrapperExecutor.java:129) at org.gradle.wrapper.GradleWrapperMain.main(GradleWrapperMain.java:61) Caused by: org.gradle.api.GradleException: Javadoc generation failed. Generated Javadoc options file (useful for troubleshooting): '/opt/Agrona/build/tmp/javadoc/javadoc.options' at org.gradle.api.tasks.javadoc.internal.JavadocGenerator.execute(JavadocGenerator.java:58) at org.gradle.api.tasks.javadoc.internal.JavadocGenerator.execute(JavadocGenerator.java:31) at org.gradle.api.tasks.javadoc.Javadoc.executeExternalJavadoc(Javadoc.java:143) at org.gradle.api.tasks.javadoc.Javadoc.generate(Javadoc.java:131) at org.gradle.internal.reflect.JavaMethod.invoke(JavaMethod.java:75) at org.gradle.api.internal.project.taskfactory.AnnotationProcessingTaskFactory$StandardTaskAction.doExecute(AnnotationProcessingTaskFactory.java:228) at org.gradle.api.internal.project.taskfactory.AnnotationProcessingTaskFactory$StandardTaskAction.execute(AnnotationProcessingTaskFactory.java:221) at org.gradle.api.internal.project.taskfactory.AnnotationProcessingTaskFactory$StandardTaskAction.execute(AnnotationProcessingTaskFactory.java:210) at org.gradle.api.internal.AbstractTask$TaskActionWrapper.execute(AbstractTask.java:621) at org.gradle.api.internal.AbstractTask$TaskActionWrapper.execute(AbstractTask.java:604) at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.executeAction(ExecuteActionsTaskExecuter.java:80) at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.executeActions(ExecuteActionsTaskExecuter.java:61) ... 60 more Caused by: org.gradle.process.internal.ExecException: Process 'command '/opt/OpenJDK-8u60-bin/bin/javadoc'' finished with non-zero exit value 1 at org.gradle.process.internal.DefaultExecHandle$ExecResultImpl.assertNormalExitValue(DefaultExecHandle.java:367) at org.gradle.process.internal.DefaultExecAction.execute(DefaultExecAction.java:31) at org.gradle.api.tasks.javadoc.internal.JavadocGenerator.execute(JavadocGenerator.java:53) ... 71 more


    Total time: 7.244 secs

    opened by milisarge 12
  • DynamicCompositeAgent remove can cause race between onClose and doWork

    DynamicCompositeAgent remove can cause race between onClose and doWork

    see relevant TODO here: https://github.com/real-logic/Agrona/blob/master/agrona/src/main/java/org/agrona/concurrent/DynamicCompositeAgent.java#L214

    Essentially, remove is threadsafe in it's list manipulation, but the old list may be iterated through by an AgentRunner which will call doWork after onClose has happened or as it is happening. A possible solution is to have a work counter (incremented by the doWork loop on execution) used to delay the close effect until a further iteration has run.

    opened by nitsanw 11
  • Non-linearizable behavior of concurrent queues

    Non-linearizable behavior of concurrent queues

    There is a bug in ManyToManyConcurrentArrayQueue, ManyToOneConcurrentArrayQueue and ManyToOneConcurrentLinkedQueue that leads to poll returning null even if there was an offer operation before in the same thread and there are no concurrent poll operations.

    I believe that this bug differs from the one mentioned in documentation, because it is not connected to isEmpty or size methods and queues are known to be not empty.

    The bug can be reproduced with Lincheck. The scenario that can produce non-linearizable results is the same for all mentioned queues:

    Parallel part:
    | offer(1): true | offer(5): true |
    |                | poll():   null |

    There are two parallel threads and the poll operation in the second thread returns null despite the fact that the queue definitely contains at least one element (the element that was added by the previous offer(5)).

    Here is an example of incorrect execution for ManyToOneConcurrentLinkedQueue (yet to be released feature in Lincheck):

    = Parallel part execution: =
    |                      | offer(5)                                                                                                          |
    |                      |   swapTail(@34bccdde): @60cd5f19 at ManyToOneConcurrentLinkedQueue.offer(ManyToOneConcurrentLinkedQueue.java:140) |
    |                      |   switch                                                                                                          |
    | offer(1): true       |                                                                                                                   |
    | poll(): null         |                                                                                                                   |
    |   thread is finished |                                                                                                                   |
    |                      |   putOrderedObject(@60cd5f19,16,@34bccdde) at Node.nextOrdered(ManyToOneConcurrentLinkedQueue.java:46)            |
    |                      |   result: true                                                                                                    |
    |                      |   thread is finished                                                                                              |   
    opened by alefedor 10
  • Infinite loop in IntHashSet when reached capacity

    Infinite loop in IntHashSet when reached capacity

    Whenever the IntHashSet/LongHashSet reaches the requested capacity, it will enter an infinite loop searching for an empty slot (confirmed for capacities of 1 and 2). I would propose the following:

    1. the set should keep operating correctly when it has reached the requested capacity;
    2. it should either document its unusual failure mode or change it to an exception.
    opened by mtopolnik 10
  • ManyToOneRingBuffer header is on the end of the buffer preventing use of constant offset counter fields

    ManyToOneRingBuffer header is on the end of the buffer preventing use of constant offset counter fields

    At the moment the header is put at the end of the buffer, so we have:

        tailCounterIndex = capacity + RingBufferDescriptor.TAIL_COUNTER_OFFSET;
        headCounterIndex = capacity + RingBufferDescriptor.HEAD_COUNTER_OFFSET;

    If the header was at the beginning of the buffer we could save ourselves all offset loads, E.g. instead of loading the tail counter like this:

    load this.tailCounterIndex
    load this.addressOffset
    offset = addressOffset + tailCounterIndex
    load offset

    we could use a constant and eliminate the first load.

    enhancement wontfix 
    opened by nitsanw 10
  • Add CodeQL workflow for GitHub code scanning

    Add CodeQL workflow for GitHub code scanning

    Hi real-logic/agrona!

    This is a one-off automatically generated pull request from LGTM.com :robot:. You might have heard that we’ve integrated LGTM’s underlying CodeQL analysis engine natively into GitHub. The result is GitHub code scanning!

    With LGTM fully integrated into code scanning, we are focused on improving CodeQL within the native GitHub code scanning experience. In order to take advantage of current and future improvements to our analysis capabilities, we suggest you enable code scanning on your repository. Please take a look at our blog post for more information.

    This pull request enables code scanning by adding an auto-generated codeql.yml workflow file for GitHub Actions to your repository — take a look! We tested it before opening this pull request, so all should be working :heavy_check_mark:. In fact, you might already have seen some alerts appear on this pull request!

    Where needed and if possible, we’ve adjusted the configuration to the needs of your particular repository. But of course, you should feel free to tweak it further! Check this page for detailed documentation.

    Questions? Check out the FAQ below!


    Click here to expand the FAQ section

    How often will the code scanning analysis run?

    By default, code scanning will trigger a scan with the CodeQL engine on the following events:

    • On every pull request — to flag up potential security problems for you to investigate before merging a PR.
    • On every push to your default branch and other protected branches — this keeps the analysis results on your repository’s Security tab up to date.
    • Once a week at a fixed time — to make sure you benefit from the latest updated security analysis even when no code was committed or PRs were opened.

    What will this cost?

    Nothing! The CodeQL engine will run inside GitHub Actions, making use of your unlimited free compute minutes for public repositories.

    What types of problems does CodeQL find?

    The CodeQL engine that powers GitHub code scanning is the exact same engine that powers LGTM.com. The exact set of rules has been tweaked slightly, but you should see almost exactly the same types of alerts as you were used to on LGTM.com: we’ve enabled the security-and-quality query suite for you.

    How do I upgrade my CodeQL engine?

    No need! New versions of the CodeQL analysis are constantly deployed on GitHub.com; your repository will automatically benefit from the most recently released version.

    The analysis doesn’t seem to be working

    If you get an error in GitHub Actions that indicates that CodeQL wasn’t able to analyze your code, please follow the instructions here to debug the analysis.

    How do I disable LGTM.com?

    If you have LGTM’s automatic pull request analysis enabled, then you can follow these steps to disable the LGTM pull request analysis. You don’t actually need to remove your repository from LGTM.com; it will automatically be removed in the next few months as part of the deprecation of LGTM.com (more info here).

    Which source code hosting platforms does code scanning support?

    GitHub code scanning is deeply integrated within GitHub itself. If you’d like to scan source code that is hosted elsewhere, we suggest that you create a mirror of that code on GitHub.

    How do I know this PR is legitimate?

    This PR is filed by the official LGTM.com GitHub App, in line with the deprecation timeline that was announced on the official GitHub Blog. The proposed GitHub Action workflow uses the official open source GitHub CodeQL Action. If you have any other questions or concerns, please join the discussion here in the official GitHub community!

    I have another question / how do I get in touch?

    Please join the discussion here to ask further questions and send us suggestions!

    opened by lgtm-com[bot] 0
  • 1.17.1(Sep 14, 2022)

  • 1.17.0(Sep 14, 2022)

    • Add DynamicPackageOutputManager so code generation can target multiple Java packages. PR #266.
    • Eliminate boxing operations on collections by providing non-boxing alternatives. PR #265.
    • Add getOrDefault non-boxing implementations to collections. PR #264.
    • Add Javadoc note about freeing of aligned buffers which have been split. Issue #263.
    • Fix for Int2ObjectCache.get can return unmatched value when full. Issue #262.
    • Upgrade to ByteBuddy 1.12.16.
    • Upgrade to Mockito 4.8.0.
    • Upgrade to JUnit 5.9.0.
    • Upgrade to Gradle 7.5.1.

    Binaries can be found here...

    Source code(tar.gz)
    Source code(zip)
  • 1.16.0(Jun 27, 2022)

    • Add optimised versions of compute on maps. PR #259.
    • Add Object2IntCounterMap. PR #257.
    • Fix Int2ObjectCache/Int2ObjectHashMap.containsValue() to perform equality based on the value stored in the map.
    • Ensure that Object2*HashMaps and ObjectHashSet always check equality using the value in the map and not vice versa. PR #253.
    • Add primitive unboxed for-each methods to primitive maps. PR #254.
    • Fix race on MarkFile.close with unmapping files.
    • Upgrade to BND 6.3.1.
    • Upgrade to ByteBuddy 1.10.12.
    • Upgrade to Mockito 4.6.1.

    Binaries can be found here...

    Source code(tar.gz)
    Source code(zip)
  • 1.15.2(May 16, 2022)

    • Improved error messages for Counters.
    • Perform equality checks using the keys/values stored in the map, i.e. add support for the asymmetric keys which can match on multiple types. For an example see the CharSequenceKey from the test package.
    • Fix MapEntry.getValue to return current value after setValue was called.
    • Various fixes for EntrySet/MapEntry across different map implementations.

    Binaries can be found here...

    Source code(tar.gz)
    Source code(zip)
  • 1.15.1(Apr 14, 2022)

    • Check error buffer has sufficient capacity before initial access.
    • Fill memory mapped file with zeros outside try-with-resources block for channel so allocation can be freed sooner.
    • Upgrade to JMH 1.35.
    • Upgrade to ByteBuddy 1.12.9.
    • Upgrade to Gradle 7.4.2.

    Binaries can be found here...

    Source code(tar.gz)
    Source code(zip)
  • 1.15.0(Mar 15, 2022)

    • Fix bug with buffer expansion with putAsciiInt / putAsciiLong methods. PR #252.
    • Add MemoryAccess for abstract access to memory fences.
    • Treat warnings as errors during build.
    • Hide JCStress output unless there is an error.
    • Upgrade to guava-testlib 31.1-jre.
    • Upgrade to BND 6.2.0.
    • Upgrade to Versions 0.42.0.
    • Upgrade to Shadow 7.1.2.
    • Upgrade to JMH 1.34.
    • Upgrade to Mockito 4.4.0.
    • Upgrade to ByteBuddy 1.12.7.
    • Upgrade to JCStress 0.15.
    • Upgrade to Checkstyle 9.3.
    • Upgrade to JUnit 5.8.2.
    • Upgrade to Gradle 7.4.1.

    Binaries can be found here...

    Source code(tar.gz)
    Source code(zip)
  • 1.14.0(Nov 23, 2021)

    • Check for thread being interrupted after calling ErrorHandler in AgentInvoker and AgentRunner so they can stop running.
    • Remove 'Serializable' from collections. It was never implemented correctly.
    • Upgrade to Mockito 4.1.0.
    • Upgrade to ByteBuddy 1.12.2.
    • Upgrade to BND 6.1.0.

    Binaries can be found here...

    Source code(tar.gz)
    Source code(zip)
  • 1.13.1(Nov 21, 2021)

    • Fix a bug in AsciiEncoding#digitCount(int) and AsciiEncoding#digitCount(long) methods which resulted in wrong value being returned for 0 input, i.e. both methods now return 1 when zero is the input value. PR #251.
    Source code(tar.gz)
    Source code(zip)
  • 1.13.0(Nov 17, 2021)

    • Check for numeric overflow when parsing numbers in ASCII.
    • Fix bounds checks when writing numbers in ASCII to buffers.
    • Improve performance for the parsing and serialisation of ints and longs in ASCII in buffer implementations.
    • Add methods to SBE message interfaces for tracking buffer position limit.
    • Rethrow subclasses of Error from Agents so the JVM can handle them after logging.
    • Avoid static fields on Unsafe to better support Android.
    • Remove final declaration from AsciiSequenceView. PR #242.
    • Upgrade to guava-testlib 31.0.1-jre.
    • Upgrade to Shadow 7.1.
    • Upgrade to BND 6.0.0.
    • Upgrade to Checkstyle 9.1.
    • Upgrade to JUnit 5.8.1.
    • Upgrade to JMH 1.33.
    • Upgrade to Mockito 4.0.0.
    • Upgrade ByteBuddy to 1.12.1.
    • Upgrade to Gradle 7.2.

    Binaries can be found here...

    Source code(tar.gz)
    Source code(zip)
  • 1.12.0(Aug 4, 2021)

    • Tidy up of spelling and grammar.
    • Fail the build if Gradle build file has warnings.
    • MutableDirectBuffer methods for putString accepting CharSequence. #240
    • jcstress added. #237
    • RingBuffer capacity validation and fixes. #239
    • Windows added to the build matrix.
    • Upgraded to Gradle 7.1.1.
    • Upgraded to Mockito 3.11.2.
    • Upgraded to ByteBuddy 1.11.9.

    Binaries can be found here...

    Source code(tar.gz)
    Source code(zip)
  • 1.11.0(Jun 11, 2021)

    • Allow for TransportPoller#ITERATION_THRESHOLD to be set from system property.
    • Relocate shadowed ByteBuddy classes in fat JAR.
    • Improve the performance of writing int and long values as ASCII in buffers.
    • Add support for @null property values when reading system properties.
    • Improve hash function for hash based collection.
    • Reduce callstack when unmapping buffers.
    • Move read of clock to inside lock when creating a new entry in the distinct error log.
    • Verify counter is in allocated state when being freed.
    • Add lock-less implementation for distributed and concurrent unique id generation based on Twitter Snowflake algorithm.
    • Upgrade to Mockito 3.11.1.
    • Upgrade to Versions 0.39.0.
    • Upgrade to JUnit 5.7.2.
    • Upgrade to JMH 1.32.
    • Upgrade to ByteBuddy 1.11.2.
    • Upgrade to Shadow 7.0.0.
    • Upgrade to Gradle 7.0.2.

    Binaries can be found here...

    Source code(tar.gz)
    Source code(zip)
  • 1.10.0(Apr 15, 2021)

    • Handle null error handler with CloseHelper.
    • Support NioSelectedKeySet.contains and NioSelectedKeySet.remove to be more efficient on Java 11+.
    • Add Java 17-ea to the build matrix.
    • Improve Javadoc.
    • Detect thread interrupt after an exception in Agent.doWork.
    • Fix race condition with OffsetEpochNanoClock used across threads. PR #220.
    • Provide the ability to thread dump to a StringBuilder.
    • Add ability to query for number of remaining available counters in a CountersManager.
    • Upgrade to Guava testlib 30.1.1-jre.
    • Upgrade to Versions 0.38.0.
    • Upgrade to JMH 1.29.
    • Upgrade to BND 5.3.0.
    • Upgrade to JUnit 5.7.1.
    • Upgrade to ByteBuddy 1.10.22.
    • Upgrade to Checkstyle 8.39.
    • Upgrade to Mockito 3.9.0.
    • Upgrade to Gradle 6.8.3.

    Binaries can be found here...

    Source code(tar.gz)
    Source code(zip)
  • 1.9.0(Dec 21, 2020)

    • Record errors as distinct in the DistinctErrorLog with unique messages.
    • Add controlled read methods to ring buffers. Issue #227.
    • Provide the ability to control the order of precedence when loading system properties. Issue #226.
    • Add Java 16 EA to build matrix.
    • Upgrade to Gauva tests 30.1-jre.
    • Upgrade to JUnit 4.13.1 for vintage engine.
    • Upgrade to Checkstyle 8.38.
    • Upgrade to ByteBuddy 1.10.18.
    • Upgrade to Versions 0.36.0.
    • Upgrade to Mockito 3.6.28.
    • Upgrade to JMH 1.27.
    • Upgrade to Checkstyle 8.36.2.
    • Upgrade to Gradle 6.7.1.

    Binaries can be found here...

    Source code(tar.gz)
    Source code(zip)
  • 1.8.0(Oct 7, 2020)

    • Resolved issues with collection classes which implement Serializable. Issue #223.
    • Improve javadoc and clean up warnings on Java 15 build.
    • Use ProcessHandle to get PID when Java 9+.
    • Add Java 15 to build matrix.
    • Add MessageDecoderFlyweight.appendTo(StringBuilder) to interface. PR #220.
    • Upgrade to Shadow 6.1.0.
    • Upgrade to ByteBuddy 1.10.17.
    • Upgrade to Mockito 3.5.13.

    Binaries can be found here...

    Source code(tar.gz)
    Source code(zip)
  • 1.7.2(Sep 18, 2020)

    • Fix issue with how direct buffers expand when initial length is set to be 0 or 1.
    • Improve javadoc for ArrayUtil and DeadlineTimerWheel.
    • Upgrade to JUnit 5.7.0.
    • Upgrade to Version 0.33.0.

    Binaries can be found here...

    Source code(tar.gz)
    Source code(zip)
  • 1.7.1(Sep 6, 2020)

    • Fix memory ordering semantics for late joining a broadcast buffer.
    • Catch Throwable rather than RuntimeException in composite Agents to be consistent with invokers and runners.
    • Upgrade to Versions 0.30.0.
    • Upgrade to Checkstyle 8.36.
    • Upgrade to JMH 1.25.2.
    • Upgrade to Mockito 3.5.10.

    Binaries can be found here...

    Source code(tar.gz)
    Source code(zip)
  • 1.7.0(Aug 28, 2020)

    • Improve validation and bounds-checking when using counters.
    • Add registration id and owner id to counters.
    • Add javadoc to explain relaxed memory order semantics on queues. Issue #216.
    • Return this for a fluent API with AtomicCounter.appendToLabel
    • Fix map capacity calculation. Issue #215.
    • Unmap MarkFile in case of an exception.
    • Improving boundary case checking when parsing numbers in direct buffers.
    • Throw exceptions for parsing numbers with AsciiEncoding so it behaves like Integer.parseInt. PR #214.
    • Change build script to help IDEA get the dependencies for generated code.
    • Upgrade to Gradle 6.6.1.
    • Upgrade to Mockito 3.5.7.
    • Upgrade to JMH 1.25.1.
    • Upgrade to ByteBuddy 1.10.14.
    • Upgrade to Checkstyle 8.35.
    • Upgrade to BND 5.1.2.
    • Upgrade to Versions 0.29.0.

    Binaries can be found here...

    Source code(tar.gz)
    Source code(zip)
  • 1.6.0(Jul 7, 2020)

    • Check for integer under and over flow when parsing numbers with AsciiEncoding.
    • Allow for wrapping zero length direct buffers at capacity. Issue #211.
    • Upgrade to Shadow 6.0.0.
    • Upgrade to BND 5.1.1.
    • Upgrade to ByteBuddy 1.10.13.
    • Upgrade to Checkstyle 8.34.
    • Upgrade to Gradle 6.5.1.

    Binaries can be found here...

    Source code(tar.gz)
    Source code(zip)
  • 1.5.1(May 27, 2020)

  • 1.5.0(May 21, 2020)

    • Fix warning message when closing AgentRunner.
    • Add ability to update counter metadata key. PR #209.
    • Add alias for each IdleStrategy.
    • Add CountersReader.getCounterTypeId(int).
    • Change false sharing protection to be forwards compatible with Java 15 class layout.
    • OffsetEpochNanoClock as an allocation free alternative EpochNanoClock. PR #206.
    • Improve performance of forEach and iterators on collections.
    • Have array backed direct buffer not print their content in toString() methods.
    • Upgrade to JUnit 5.6.2.
    • Upgrade to javadoc-links 5.1.0.
    • Upgrade to ByteBuddy 10.10.0.
    • Upgrade to Gradle 5.6.1.

    Binaries can be found here...

    Source code(tar.gz)
    Source code(zip)
  • 1.4.1(Mar 28, 2020)

    • Supporting building and running on Java 14.
    • Add decrement() and decrementOrdered() methods to AtomicCounter.
    • Add Thread.onSpinWait() when retrying in ManyToManyConcurrentArrayQueue offer and poll.
    • Upgrade to Gradle 6.3.
    • Upgrade to BND 5.0.1.
    • Upgrade to JUnit 5.6.1.
    • Upgrade to Mockito 3.3.3.

    Binaries can be found here...

    Source code(tar.gz)
    Source code(zip)
  • 1.4.0(Feb 26, 2020)

    • Check for thread interrupt in AgentRunner after idling so agent can be closed immediately.
    • Add the ability to close a CountedErrorHandler.
    • Add BufferUtil.free(ByteBuffer) to free direct ByteBuffers. PR #205.
    • Migrate from Gradle maven to maven-publish.
    • Allow Maps with a cached iterator to work when calling toArray on entries. PR #202.
    • Allow CloseHelper to work on expanded type range from List to Collection of Closable.
    • Upgrade to Gradle 6.2.1.
    • Upgrade to Versions 0.28.0.
    • Upgrade to Mockito 3.3.0.
    • Upgrade to BND 5.0.0.
    • Upgrade to JMH 1.23.

    Binaries can be found here...

    Source code(tar.gz)
    Source code(zip)
  • 1.3.0(Jan 21, 2020)

    • Add RingBuffer.tryClaim implementations for zero copy semantics when encoding into ring buffers. PR #199.
    • Allow for configurable Charset when encoding exceptions in DistinctErrorLog.
    • Don't read underlying buffer in AtomicCounter implementations for toString() when closed to help avoid segfaults.
    • Expand the methods in MutableInteger and MutableLong to be better single-threaded substitutes for AtomicInteger and AtomicLong. PR #198.
    • Filter dependencies from agent shadow POM.
    • Upgrade to JUnit 5.6.0.

    Binaries can be found here...

    Source code(tar.gz)
    Source code(zip)
  • 1.2.0(Jan 9, 2020)

    • Fix concurrency issue with enabling and disabling HighResolutionTimer.
    • Add isLinux and isWindows to SystemUtil.
    • Refinements to alignment checking agent.
    • Move CI to GitHub Actions.
    • Upgrade to JUnit 5.6.0-RC1.
    • Update to Guava TestLib 28.2-jre.
    • Upgrade to Checkstyle 8.28.
    • Upgrade to Mockito 3.2.4.
    • Upgrade Gradle 6.0.1.
    • Upgrade to ByteBuddy 1.10.5.
    • Upgrade to javadoc-links 4.1.6.

    Binaries can be found here...

    Source code(tar.gz)
    Source code(zip)
  • 1.1.0(Nov 18, 2019)

    • Allow for buffer reference being null in AsciiSequenceView. PR #190.
    • Add DelegatingErrorHandler.
    • Add method to advance a cached clock.
    • Provide the ability to add a suffix to a counter label after allocation.
    • Provide singleton versions of clocks.
    • Allow for better inlining on direct buffer implementations.
    • Upgrade to javadoc-links 4.1.4.
    • Upgrade to Hamcrest 2.2.
    • Upgrade to Checkstyle 8.26.
    • Upgrade to ByteBuddy 1.10.2.
    • Upgrade to Shadow 5.2.0.

    Binaries can be found here...

    Source code(tar.gz)
    Source code(zip)
  • 1.0.11(Nov 6, 2019)

    • Add the ability to update a counter label on the AtomicCounter API for the owning user.
    • Provide unboxed implementation of setValue on primitive map iterators.

    Binaries can be found here...

    Source code(tar.gz)
    Source code(zip)
  • 1.0.10(Oct 31, 2019)

  • 1.0.9(Oct 25, 2019)

    • Improve javadoc for HighPrecisionClock.
    • Reduce the amount of false sharing padding on concurrent data structures to save on memory footprint.
    • Implement AutoClosable for LoggingErrorHandler so it can be closed to help avoid seg faults with unmapped files.
    • Upgrade to javadoc-links 4.1.3.
    • Upgrade to Checkstyle 8.25.
    • Upgrade to Gradle 5.6.3.

    Binaries can be found here...

    Source code(tar.gz)
    Source code(zip)
  • 1.0.8(Oct 4, 2019)

    • Provide singleton instances for NoOpLock and stateless idle strategies to save on allocation.
    • Open files as read only when mapping as read only. PR #185.
    • Allow partial reset of NioSelectedKeySet so that some items may be later retried. PR #183.
    • Allow wrapping of arrays less then minimum default length for primitive array lists. Issue #182.
    • Zero out metadata for counters after use to avoid potential reuse issues.
    • Provide default constructors for idle strategies so they can be dynamically loaded more easily.
    • Upgrade to javadoc-links 4.1.2.
    • Upgrade to Mockito 3.1.0.
    • Upgrade to guava-testlib 28.1.
    • Upgrade to Gradle 5.6.2.

    Binaries can be found here...

    Source code(tar.gz)
    Source code(zip)
  • 1.0.7(Aug 12, 2019)

    • Add long variants of BitUtil.isPowerOfTwo() and BitUtil.findNextPositivePowerOfTwo().
    • Change tick resolution in DeadlineTimerWheel to be a long rather than int to allow for time unit to be in nanoseconds with tick resolution to be in seconds.
    • Correct implementation of CollectionUtil.validatePositivePowerOfTwo(). Issue #179.
    • Don't update error counters in agent runners and invokers when not running to closed to avoid segfaults.
    • Upgrade to javadoc-links 3.8.2.

    Binaries can be found here...

    Source code(tar.gz)
    Source code(zip)
Real Logic
Commercial support and development for Aeron & SBE
Real Logic
Eclipse Collections is a collections framework for Java with optimized data structures and a rich, functional and fluent API.

English | 中文 | Deutsch | Español | Ελληνικά | Français | 日本語 | Norsk (bokmål) | Português-Brasil | Русский | हिंदी Eclipse Collections is a comprehens

Eclipse Foundation 2.1k Dec 8, 2022
The Java collections framework provides a set of interfaces and classes to implement various data structures and algorithms.

Homework #14 Table of Contents General Info Technologies Used Project Status Contact General Information Homework contains topics: Sorting an ArrayLis

Mykhailo 1 Feb 12, 2022
Clojure's data structures modified for use outside of Clojure

This library has been extracted from the master branch of Clojure (http://clojure.org) version 1.5.1 (as of October 2013) http://github.com/richhick

Karl Krukow 221 Oct 6, 2022
Hollow is a java library and toolset for disseminating in-memory datasets from a single producer to many consumers for high performance read-only access.

Hollow Hollow is a java library and toolset for disseminating in-memory datasets from a single producer to many consumers for high performance read-on

Netflix, Inc. 1.1k Nov 30, 2022
A high performance caching library for Java

Caffeine is a high performance, near optimal caching library. For more details, see our user's guide and browse the API docs for the latest release. C

Ben Manes 12.8k Dec 2, 2022
High performance Java implementation of a Cuckoo filter - Apache Licensed

Cuckoo Filter For Java This library offers a similar interface to Guava's Bloom filters. In most cases it can be used interchangeably and has addition

Mark Gunlogson 160 Oct 20, 2022
High Performance Primitive Collections for Java

HPPC: High Performance Primitive Collections Collections of primitive types (maps, sets, stacks, lists) with open internals and an API twist (no java.

Carrot Search 889 Dec 4, 2022
Simple Binary Encoding (SBE) - High Performance Message Codec

Simple Binary Encoding (SBE) SBE is an OSI layer 6 presentation for encoding and decoding binary application messages for low-latency financial applic

Real Logic 2.7k Nov 30, 2022
A 1.16.5 utility mod oriented towards anarchy servers

FrostBurn A 1.16.5 utility mod oriented towards anarchy servers Progress Command System Module System Friends Settings ClickGUI Render Modules Chams F

Evan 43 Sep 10, 2022
Java Collections till the last breadcrumb of memory and performance

Koloboke A family of projects around collections in Java (so far). The Koloboke Collections API A carefully designed extension of the Java Collections

Roman Leventov 967 Nov 14, 2022
A fork of Cliff Click's High Scale Library. Improved with bug fixes and a real build system.

High Scale Lib This is Boundary's fork of Cliff Click's high scale lib. We will be maintaining this fork with bug fixes, improvements and versioned bu

BMC TrueSight Pulse (formerly Boundary) 402 Nov 20, 2022
Replicate your Key Value Store across your network, with consistency, persistance and performance.

Chronicle Map Version Overview Chronicle Map is a super-fast, in-memory, non-blocking, key-value store, designed for low-latency, and/or multi-process

Chronicle Software : Open Source 2.5k Dec 6, 2022
A Primitive Collection library that reduces memory usage and improves performance

Primitive-Collections This is a Simple Primitive Collections Library i started as a hobby Project. It is based on Java's Collection Library and FastUt

Speiger 25 Sep 19, 2022
Jalgorithm is an open-source Java library which has implemented various algorithms and data structure

We loved Java and algorithms, so We made Jalgorithm ❤ Jalgorithm is an open-source Java library which has implemented various algorithms and data stru

Muhammad Karbalaee 35 Nov 18, 2022
An embedded database implemented in pure java based on bitcask which is a log-structured hash table for K/V Data.

Baka Db An embedded database implemented in pure java based on bitcask which is a log-structured hash table for K/V Data. Usage import cn.ryoii.baka.B

ryoii 3 Dec 20, 2021
BioJava is an open-source project dedicated to providing a Java framework for processing biological data.

Welcome to BioJava is an open-source project dedicated to providing a Java framework for processing biological data. It provides analytical and statis

BioJava 512 Nov 21, 2022
Reading Dalta Lake data from Beam

Reading Delta Lake Data from Beam General Info: All files, except org.apache.beam.sdk.io.DeltaFileIO are from Daltalake Standalone Reader. I was not a

Michael 6 Nov 21, 2022
Dremio - the missing link in modern data

Dremio Dremio enables organizations to unlock the value of their data. Documentation Documentation is available at https://docs.dremio.com. Quickstart

Dremio 1.1k Dec 1, 2022