[jira] [Closed] (BCEL-321) Refactor subclasses of ClassPathRepository for differences in underlying cache

["Gary Gregory (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/BCEL-321?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Gary Gregory closed BCEL-321.
-----------------------------
       Resolution: Fixed
    Fix Version/s: 6.4.0

In git master.

> Refactor subclasses of ClassPathRepository for differences in underlying cache
> ------------------------------------------------------------------------------
>
>                 Key: BCEL-321
>                 URL: https://issues.apache.org/jira/browse/BCEL-321
>             Project: Commons BCEL
>          Issue Type: Improvement
>            Reporter: Tomo Suzuki
>            Priority: Minor
>             Fix For: 6.4.0
>
>         Attachments: classpathrepository_code_duplicate.png
>
>          Time Spent: 20m
>  Remaining Estimate: 0h
>
> (After implementing [BCEL-320|https://issues.apache.org/jira/browse/BCEL-320])
> BCEL has different ClassPathRepository classes with slight modification in its underlying cache:
> * ClassPathRepository uses HashMap<String, JavaClass> for JavaClass cache
> * MemorySensitiveClassPathRepository uses HashMap<String, SoftReference<JavaClass>
> * New LruCacheClassPathRepository by BCEL-320 will use LinkedHashMap<String, JavaClass> for JavaClass cache
> The logic of loadClass, storeClass, and findClass methods are almost same (attached screenshot of ClassPathRepository and MemorySensitiveClassPathRepository as below). I think they can leverage an abstraction over the internal cache so that they will have less duplicate code.
> After BCEL-320, I'm thinking to create a PR for the abstraction.
>  !classpathrepository_code_duplicate.png!



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)