A Dockerfile needs to be created that:

• Copies all the source files into the working directory.
• Built atop Maven supporting JDK.
• Contributors with basic knowledge of Docker can try to contribute. Image validating the following would be considered as proof for resolution of the issue:
  • Correct running of any program inside a Docker container.
  • Correct running of all tests inside a Docker container upon running mvn test.

Modify the Dockerfile inside the .devcontainer to complete the task.

• The random number generator in caching section is required to give umbers from 0 to 19. It currently given numbers from 1 to 20. This needs to be fixed.
• Optional: A mechanism to ensure that the random number generated is not the same that was generated before in the cache data structure.

To understand more, take a close look at the cachingalgorithms section.

Describe the bug Currently, in RandomReplacementCache the below code is being used to randomly remove elements from the cache cache.remove(random.nextInt(CACHE_SIZE + 1));

The random.nextInt function here can end up generating 5 sometimes whereas the collection has the size=5 which would mean the indices are only from 0-4. This would then end up in an IndexOutOfBoundsException.

Expected behavior IndexOutOfBounds Exception should not be seen

Proposed solution The nextInt function should just be passed with CACHE_SIZE and not CACHE_SIZE+1

Please assign the issue to me. Will push the fix for this.

Description:

This fix aims at tackling the below two points as mentioned in #14 :

• Ensuring that the generation of numbers happens within the range 0-19 and not 1 to 20
• Ensuring that the numbers are unique and do not repeat themselves

This fix also addresses the issue mentioned in #16

Tested the same for all the different caching algorithms and they are working fine.

Description:

This PR is to ensure that the entire repository is built as a Docker Container as mentioned in #12

Summary of the changes:

• Have modified the Dockerfile to ensure that the project is built using maven and built into the docker image properly
• A docker image would have to have a main class specified which would be run once the container is up and hence added a Main class with a server started so that the container would not stop immediately and let us run the required commands inside it
• Added the necessary configuration to the pom.xml to generate the manifest file for docker to pick up the main class properly

Test Screenshots

The following things need to be resolved:

• All files (source and test) in the repository should be looked at.
• Any tools such as the Organize Imports on Eclipse may be used, if needed.
• If any third-party plugin is being used to order imports, the tool must be mentioned so that it may be incorporated in the workflow in the future.
• Check for help here: https://stackoverflow.com/a/7735738/14814153
• Since more test and source files would be added, this issue will be periodically reopened unless a suitable tool or plugin is found to automate the job.

• Within the furtherreading/java-ecosystem directory, create a java-memory-model.md file that documents the entirety of the research and information pertaining to the Java Memory Model in a clear manner.
• Any person perusing the documentation should not feel the need to refer to some other source of information over the internet or a book to resolve any further queries they have regarding this topic. Neither should they feel eluded, for whatever reason, as to understanding of the material that is provided here.
• Exploring low-level implementation details in the system is always appreciated.
• Contributors should have sufficient knowledge in the subject matter as well as proficiency in the English language.
• Follow-up questions, comments and remarks to this issue will be acknowledged and humored.
• Sources to refer to:
  • https://medium.com/platform-engineer/understanding-java-memory-model-1d0863f6d973
  • https://jenkov.com/tutorials/java-concurrency/java-memory-model.html
  • A research paper that can be a heavy read and is optional to refer to.

• Under furtherreading/java-ecosystem, create a file garbage-collection.md.
• The file should contain detailed and exhaustive information about the Java Garbage Collector and its relation with respect to the Java Ecosystem.
• Content should be made in such a way that after reading the documentation here, there should be no need for anyone to hop around the web to gain additional information or clarification on certain explanations put up here.
• Contributors are expected to have a firm grip over the concept as well as English language in general.
• Brief discussion over garbage collector tools, why we need them as well as their examples. Do not include tools that are not used anymore (CMS, for example). Describe the popular GC tools (G1, ZCG for example).
• Sources to learn more and get help:
  • https://www.oracle.com/webfolder/technetwork/tutorials/obe/java/gc01/index.html
  • https://medium.com/platform-engineer/understanding-java-garbage-collection-54fc9230659a

• A functional badge displaying the code coverage needs to be put beside the Maven Build badge.
• A functional badge displaying the lines of code needs to be put beside the Codecov badge.

• The conventions.md file in the directory of further reading is lacking as of now. Condense the whole manifest of the Google Java Style Guide into the file in the format that has already been laid down.
• Documenting the gradle.md file needs to be finished off so as to impart a thorough and solid understanding of the build system. Refer to the maven.md under the Further Reading section for better understanding on how to tackle the documentation.
• Elaborations and alterations in reasonable limits are acceptable.
• Contributors are expected to be thorough in the English language.

Write tests using JUnit5 for the following sections:

• Greedy Algorithms (3 test files)
• General Problems (2 test files)
• Divide and Conquer (2 test files)
• Dynamic Programming (1 test file)