[jira] [Updated] (OFBIZ-10433) Fix accounting URL on OFBiz website
[ https://issues.apache.org/jira/browse/OFBIZ-10433?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Swapnil M Mane updated OFBIZ-10433: --- Attachment: OFBIZ-10433.patch > Fix accounting URL on OFBiz website > > > Key: OFBIZ-10433 > URL: https://issues.apache.org/jira/browse/OFBIZ-10433 > Project: OFBiz > Issue Type: Bug > Components: site >Reporter: Swapnil M Mane >Priority: Trivial > Attachments: OFBIZ-10433.patch > > > Change the url '//localhost:8443/accounting' to > [https://localhost:8443/accounting] at > [https://ofbiz.apache.org/developers.html] and > [https://ofbiz.apache.org/business-users.html] > Reference > [link|https://lists.apache.org/thread.html/8f57ee36bfd66b42faf5a3d8e7f562e7e9bb247c32e231d1e34e9529@%3Cdev.ofbiz.apache.org%3E] > to mailing list discussion. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (OFBIZ-10433) Fix accounting URL on OFBiz website
[ https://issues.apache.org/jira/browse/OFBIZ-10433?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16510656#comment-16510656 ] Swapnil M Mane commented on OFBIZ-10433: Added the patch with suggested changes. > Fix accounting URL on OFBiz website > > > Key: OFBIZ-10433 > URL: https://issues.apache.org/jira/browse/OFBIZ-10433 > Project: OFBiz > Issue Type: Bug > Components: site >Reporter: Swapnil M Mane >Priority: Trivial > Attachments: OFBIZ-10433.patch > > > Change the url '//localhost:8443/accounting' to > [https://localhost:8443/accounting] at > [https://ofbiz.apache.org/developers.html] and > [https://ofbiz.apache.org/business-users.html] > Reference > [link|https://lists.apache.org/thread.html/8f57ee36bfd66b42faf5a3d8e7f562e7e9bb247c32e231d1e34e9529@%3Cdev.ofbiz.apache.org%3E] > to mailing list discussion. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (OFBIZ-10433) Fix accounting URL on OFBiz website
Swapnil M Mane created OFBIZ-10433: -- Summary: Fix accounting URL on OFBiz website Key: OFBIZ-10433 URL: https://issues.apache.org/jira/browse/OFBIZ-10433 Project: OFBiz Issue Type: Bug Components: site Reporter: Swapnil M Mane Change the url '//localhost:8443/accounting' to [https://localhost:8443/accounting] at [https://ofbiz.apache.org/developers.html] and [https://ofbiz.apache.org/business-users.html] Reference [link|https://lists.apache.org/thread.html/8f57ee36bfd66b42faf5a3d8e7f562e7e9bb247c32e231d1e34e9529@%3Cdev.ofbiz.apache.org%3E] to mailing list discussion. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OFBIZ-6747) Replace ConcurrentLinkedHashMap by Caffeine
[ https://issues.apache.org/jira/browse/OFBIZ-6747?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Swapnil M Mane updated OFBIZ-6747: -- Description: Similar to OFBIZ-3779, please consider upgrading the library used by [UtilCache|https://github.com/apache/ofbiz/blob/trunk/framework/base/src/main/java/org/apache/ofbiz/base/util/cache/UtilCache.java] (v1.2). The current version is 1.4.2 and is the last major release planned. The preferable alternative would be to upgrade to [Caffeine|https://github.com/ben-manes/caffeine]. This is a Java 8 rewrite based on what I've learned since developing CLHM and Guava's cache. As expected it provides [superior performance|https://github.com/ben-manes/caffeine/wiki/Benchmarks]. It also provides a [near optimal|https://github.com/ben-manes/caffeine/wiki/Efficiency] eviction policy. was: Similar to OFBIZ-3779, please consider upgrading the library used by [UtilCache|https://github.com/apache/ofbiz/blob/trunk/framework/base/src/org/ofbiz/base/util/cache/UtilCache.java] (v1.2). The current version is 1.4.2 and is the last major release planned. The preferable alternative would be to upgrade to [Caffeine|https://github.com/ben-manes/caffeine]. This is a Java 8 rewrite based on what I've learned since developing CLHM and Guava's cache. As expected it provides [superior performance|https://github.com/ben-manes/caffeine/wiki/Benchmarks]. It also provides a [near optimal|https://github.com/ben-manes/caffeine/wiki/Efficiency] eviction policy. > Replace ConcurrentLinkedHashMap by Caffeine > --- > > Key: OFBIZ-6747 > URL: https://issues.apache.org/jira/browse/OFBIZ-6747 > Project: OFBiz > Issue Type: Task >Reporter: Ben Manes >Assignee: Jacques Le Roux >Priority: Minor > > Similar to OFBIZ-3779, please consider upgrading the library used by > [UtilCache|https://github.com/apache/ofbiz/blob/trunk/framework/base/src/main/java/org/apache/ofbiz/base/util/cache/UtilCache.java] > (v1.2). The current version is 1.4.2 and is the last major release planned. > The preferable alternative would be to upgrade to > [Caffeine|https://github.com/ben-manes/caffeine]. This is a Java 8 rewrite > based on what I've learned since developing CLHM and Guava's cache. As > expected it provides [superior > performance|https://github.com/ben-manes/caffeine/wiki/Benchmarks]. It also > provides a [near > optimal|https://github.com/ben-manes/caffeine/wiki/Efficiency] eviction > policy. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (OFBIZ-6747) Replace ConcurrentLinkedHashMap by Caffeine
[ https://issues.apache.org/jira/browse/OFBIZ-6747?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16510062#comment-16510062 ] Ben Manes commented on OFBIZ-6747: -- In regards to fun algorithms, some resources to look into are... * For general concurrency, the book [The Art of Multiprocessor Programming|https://www.amazon.com/Art-Multiprocessor-Programming-Revised-Reprint/dp/0123973376] is excellent. It covers lock-free algorithms and is written by researchers who authored many well known papers. * The concurrency scheme used by my caches is inspired by a database's write-ahead log. The classic approaches are to either thrash on a global lock to perform a tiny amount of work (usually pointer flipping) or avoid "movement" by using a CLOCK-based or random sampling policy. By instead recording into a ring buffer and replaying under a tryLock, the lock contention is replaced by a cheaper buffer CAS. This lets me uses non-threadsafe algorithms that are O(1) and more intelligent. The idea is simple and implementation just takes work to squeeze out performance. * For eviction, see the ACM paper on our policy. The pre-published is on the earlier link, while the peer reviewed version can be freely downloaded from the link on the README. I wrote an [overview|http://highscalability.com/blog/2016/1/25/design-of-a-modern-cache.html] ([slides|https://docs.google.com/presentation/d/1NlDxyXsUG1qlVHMl4vsUUBQfAJ2c2NsFPNPr2qymIBs/edit#slide=id.p]) for HighScalability. We have a followup paper under review that makes it adaptive. If interested, I can send that over private email due to submission restrictions (my email is on github). * For expiration, see this excellent article by the Kafka folks on [Hierarchical TimerWheel|https://www.confluent.io/blog/apache-kafka-purgatory-hierarchical-timing-wheels]. This is an amortized O(1) priority queue that leverages time to use hashing instead of tree-like comparisons. Caffeine is the only cache that I'm aware of to use this, but this data structure is fundamental in kernel subsystems. Its really elegant and fast! And the rest is all elbow grease! :) > Replace ConcurrentLinkedHashMap by Caffeine > --- > > Key: OFBIZ-6747 > URL: https://issues.apache.org/jira/browse/OFBIZ-6747 > Project: OFBiz > Issue Type: Task >Reporter: Ben Manes >Assignee: Jacques Le Roux >Priority: Minor > > Similar to OFBIZ-3779, please consider upgrading the library used by > [UtilCache|https://github.com/apache/ofbiz/blob/trunk/framework/base/src/org/ofbiz/base/util/cache/UtilCache.java] > (v1.2). The current version is 1.4.2 and is the last major release planned. > The preferable alternative would be to upgrade to > [Caffeine|https://github.com/ben-manes/caffeine]. This is a Java 8 rewrite > based on what I've learned since developing CLHM and Guava's cache. As > expected it provides [superior > performance|https://github.com/ben-manes/caffeine/wiki/Benchmarks]. It also > provides a [near > optimal|https://github.com/ben-manes/caffeine/wiki/Efficiency] eviction > policy. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (OFBIZ-6747) Replace ConcurrentLinkedHashMap by Caffeine
[ https://issues.apache.org/jira/browse/OFBIZ-6747?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16510004#comment-16510004 ] Taher Alkhateeb commented on OFBIZ-6747: Ahh I just noticed that Jacques is working on this issue which I should've figured from the ML exchange, anyway I'll leave it to you to come up with a PoC then and we can discuss it here. > Replace ConcurrentLinkedHashMap by Caffeine > --- > > Key: OFBIZ-6747 > URL: https://issues.apache.org/jira/browse/OFBIZ-6747 > Project: OFBiz > Issue Type: Task >Reporter: Ben Manes >Assignee: Jacques Le Roux >Priority: Minor > > Similar to OFBIZ-3779, please consider upgrading the library used by > [UtilCache|https://github.com/apache/ofbiz/blob/trunk/framework/base/src/org/ofbiz/base/util/cache/UtilCache.java] > (v1.2). The current version is 1.4.2 and is the last major release planned. > The preferable alternative would be to upgrade to > [Caffeine|https://github.com/ben-manes/caffeine]. This is a Java 8 rewrite > based on what I've learned since developing CLHM and Guava's cache. As > expected it provides [superior > performance|https://github.com/ben-manes/caffeine/wiki/Benchmarks]. It also > provides a [near > optimal|https://github.com/ben-manes/caffeine/wiki/Efficiency] eviction > policy. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (OFBIZ-10317) Allowing XML-RPC and SOAP to pass GenericValue objects to services as IN fields
[ https://issues.apache.org/jira/browse/OFBIZ-10317?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Taher Alkhateeb closed OFBIZ-10317. --- > Allowing XML-RPC and SOAP to pass GenericValue objects to services as IN > fields > --- > > Key: OFBIZ-10317 > URL: https://issues.apache.org/jira/browse/OFBIZ-10317 > Project: OFBiz > Issue Type: Improvement > Components: framework/webtools >Affects Versions: 16.11.04 >Reporter: Rajesh Kumar Mallah >Assignee: Taher Alkhateeb >Priority: Major > Attachments: not-working.xml, working.xml > > > > The existing framework allows invoking various services via XMLRPC or SOAP > as per their argument expectations. However only basic types are handled > like String , Boolean , Int etc. If a service is expecting a GenericValue eg: > 'calculateProductPrice' it is not possible to invoke it via SOAP or XMLRPC. > The reason being SOAP or XMLRPC can support Map and that is the closest > it can provide in lieu of any custom Object that a Service might be expecting. > A generic solution needs to be found so that the full potential of the > plethora of > exportable services can be utilized by external systems that looks for > integrating and > banking upon OfBiz via XMLRPC or SOAP. > h6. related Threads: > [How to pass org.apache.ofbiz.entity.GenericValue using XMLRPC] > [https://markmail.org/message/dwako4nsu4h3zgmu] [ dev ] > [https://markmail.org/message/iuffmakor3ru2yce] [user] > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (OFBIZ-10317) Allowing XML-RPC and SOAP to pass GenericValue objects to services as IN fields
[ https://issues.apache.org/jira/browse/OFBIZ-10317?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Taher Alkhateeb resolved OFBIZ-10317. - Resolution: Won't Fix Assignee: Taher Alkhateeb As per discussion, the issue cannot be implemented because a GenericValue is something that holds state to an existing entity in the system. Thus, passing a map through XML RPC cannot be translated to the correct GenericValue. Therefore, closing this task > Allowing XML-RPC and SOAP to pass GenericValue objects to services as IN > fields > --- > > Key: OFBIZ-10317 > URL: https://issues.apache.org/jira/browse/OFBIZ-10317 > Project: OFBiz > Issue Type: Improvement > Components: framework/webtools >Affects Versions: 16.11.04 >Reporter: Rajesh Kumar Mallah >Assignee: Taher Alkhateeb >Priority: Major > Attachments: not-working.xml, working.xml > > > > The existing framework allows invoking various services via XMLRPC or SOAP > as per their argument expectations. However only basic types are handled > like String , Boolean , Int etc. If a service is expecting a GenericValue eg: > 'calculateProductPrice' it is not possible to invoke it via SOAP or XMLRPC. > The reason being SOAP or XMLRPC can support Map and that is the closest > it can provide in lieu of any custom Object that a Service might be expecting. > A generic solution needs to be found so that the full potential of the > plethora of > exportable services can be utilized by external systems that looks for > integrating and > banking upon OfBiz via XMLRPC or SOAP. > h6. related Threads: > [How to pass org.apache.ofbiz.entity.GenericValue using XMLRPC] > [https://markmail.org/message/dwako4nsu4h3zgmu] [ dev ] > [https://markmail.org/message/iuffmakor3ru2yce] [user] > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (OFBIZ-10317) Allowing XML-RPC and SOAP to pass GenericValue objects to services as IN fields
[
https://issues.apache.org/jira/browse/OFBIZ-10317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16509993#comment-16509993
]
Rajesh Kumar Mallah commented on OFBIZ-10317:
-
Hi Taher,
Yeah it was a ambiguous term to use. can't help though owing to my limit
experience :) shall try to be more careful.
Even if we close this issue it shall bite us back when creating
inter-interoperability features like JSON based apis
etc.
{quote}The best solution that I can think for you is to design adapter services
in the middle that talk to the target services you want to use, if we create
some kind of hack (like passing the entity name in the XML-RPC call) then our
converters would _only_ work for XML-RPC, which is a pretty bad design anyway.
{quote}
would try to do the same. I already did so to keep the show running .
please feel free to take a call on this issue.
regds
mallah
> Allowing XML-RPC and SOAP to pass GenericValue objects to services as IN
> fields
> ---
>
> Key: OFBIZ-10317
> URL: https://issues.apache.org/jira/browse/OFBIZ-10317
> Project: OFBiz
> Issue Type: Improvement
> Components: framework/webtools
>Affects Versions: 16.11.04
>Reporter: Rajesh Kumar Mallah
>Priority: Major
> Attachments: not-working.xml, working.xml
>
>
>
> The existing framework allows invoking various services via XMLRPC or SOAP
> as per their argument expectations. However only basic types are handled
> like String , Boolean , Int etc. If a service is expecting a GenericValue eg:
> 'calculateProductPrice' it is not possible to invoke it via SOAP or XMLRPC.
> The reason being SOAP or XMLRPC can support Map and that is the closest
> it can provide in lieu of any custom Object that a Service might be expecting.
> A generic solution needs to be found so that the full potential of the
> plethora of
> exportable services can be utilized by external systems that looks for
> integrating and
> banking upon OfBiz via XMLRPC or SOAP.
> h6. related Threads:
> [How to pass org.apache.ofbiz.entity.GenericValue using XMLRPC]
> [https://markmail.org/message/dwako4nsu4h3zgmu] [ dev ]
> [https://markmail.org/message/iuffmakor3ru2yce] [user]
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (OFBIZ-10317) Allowing XML-RPC and SOAP to pass GenericValue objects to services as IN fields
[
https://issues.apache.org/jira/browse/OFBIZ-10317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16509887#comment-16509887
]
Taher Alkhateeb edited comment on OFBIZ-10317 at 6/12/18 5:06 PM:
--
Okay after thoroughly investigating this issue, I realized that the first step
to attempt is to create a converter from a Map to GenericValue.
So I went ahead and implemented the code, the important part of which is listed
below:
{code:java}
public static class MapToGenericValue extends AbstractConverter, GenericValue> {
public MapToGenericValue() {
super(Map.class, GenericValue.class);
}
public GenericValue convert(Map obj) throws
ConversionException {
GenericValue genericValue = new GenericValue();
genericValue.putAll(UtilGenerics.checkMap(obj));
return genericValue;
}
}{code}
The problem here of course is that the generic value is not linked to a
ModelEntity. Why? Because we don't know what is the entity. We just received
some data, we did not receive an actual Object. So if you run my above code,
you will get an error:
{code:java}
java.lang.IllegalStateException: [GenericEntity.getModelEntity] could not find
modelEntity for entityName null
{code}
So to convert XML-RPC data to a Java Object, we _must_ know what is the entity
name (at the very least). In our example, the entity name is "Product" whereas
the service parameter name is "product" which is not the same.
So, unless you have an idea for how to get the entity information for all
existing services that take a GenericValue, I think this issue cannot be
implemented successfully
was (Author: taher):
Okay after thoroughly investigating this issue, I realized that the first step
to attempt is to create a converter from a Map to GenericValue.
So I went ahead and implemented the code, the important part of which is listed
below:
{code:java}
public static class MapToGenericValue extends AbstractConverter, GenericValue> {
public MapToGenericValue() {
super(Map.class, GenericValue.class);
}
public GenericValue convert(Map obj) throws
ConversionException {
GenericValue genericValue = new GenericValue();
genericValue.putAll(UtilGenerics.checkMap(obj));
return genericValue;
}
}{code}
The problem here of course is that the generic value is not linked to a
ModelEntity. Why? Because we don't know what is the entity. We just received
some data, we did not receive an actual Object. So if you run my above code,
you will get an error:
{code:java}
java.lang.IllegalStateException: [GenericEntity.getModelEntity] could not find
modelEntity for entityName null
{code}
So to convert XML-RPC data to a Java Object, we _must_ know what is the entity
name (at the very least). In our example, the entity name is "Product" whereas
the service parameter name is "product" which is not the same.
So, unless you have an idea for how to get the entity information for all
existing services that take a GenericValue, I think this issue cannot be
implemented successfully
> Allowing XML-RPC and SOAP to pass GenericValue objects to services as IN
> fields
> ---
>
> Key: OFBIZ-10317
> URL: https://issues.apache.org/jira/browse/OFBIZ-10317
> Project: OFBiz
> Issue Type: Improvement
> Components: framework/webtools
>Affects Versions: 16.11.04
>Reporter: Rajesh Kumar Mallah
>Priority: Major
> Attachments: not-working.xml, working.xml
>
>
>
> The existing framework allows invoking various services via XMLRPC or SOAP
> as per their argument expectations. However only basic types are handled
> like String , Boolean , Int etc. If a service is expecting a GenericValue eg:
> 'calculateProductPrice' it is not possible to invoke it via SOAP or XMLRPC.
> The reason being SOAP or XMLRPC can support Map and that is the closest
> it can provide in lieu of any custom Object that a Service might be expecting.
> A generic solution needs to be found so that the full potential of the
> plethora of
> exportable services can be utilized by external systems that looks for
> integrating and
> banking upon OfBiz via XMLRPC or SOAP.
> h6. related Threads:
> [How to pass org.apache.ofbiz.entity.GenericValue using XMLRPC]
> [https://markmail.org/message/dwako4nsu4h3zgmu] [ dev ]
> [https://markmail.org/message/iuffmakor3ru2yce] [user]
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (OFBIZ-10317) Allowing XML-RPC and SOAP to pass GenericValue objects to services as IN fields
[
https://issues.apache.org/jira/browse/OFBIZ-10317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16509887#comment-16509887
]
Taher Alkhateeb commented on OFBIZ-10317:
-
Okay after thoroughly investigating this issue, I realized that the first step
to attempt is to create a converter from a Map to GenericValue.
So I went ahead and implemented the code, the important part of which is listed
below:
{code:java}
public static class MapToGenericValue extends AbstractConverter, GenericValue> {
public MapToGenericValue() {
super(Map.class, GenericValue.class);
}
public GenericValue convert(Map obj) throws
ConversionException {
GenericValue genericValue = new GenericValue();
genericValue.putAll(UtilGenerics.checkMap(obj));
return genericValue;
}
}{code}
The problem here of course is that the generic value is not linked to a
ModelEntity. Why? Because we don't know what is the entity. We just received
some data, we did not receive an actual Object. So if you run my above code,
you will get an error:
{code:java}
java.lang.IllegalStateException: [GenericEntity.getModelEntity] could not find
modelEntity for entityName null
{code}
So to convert XML-RPC data to a Java Object, we _must_ know what is the entity
name (at the very least). In our example, the entity name is "Product" whereas
the service parameter name is "product" which is not the same.
So, unless you have an idea for how to get the entity information for all
existing services that take a GenericValue, I think this issue cannot be
implemented successfully
> Allowing XML-RPC and SOAP to pass GenericValue objects to services as IN
> fields
> ---
>
> Key: OFBIZ-10317
> URL: https://issues.apache.org/jira/browse/OFBIZ-10317
> Project: OFBiz
> Issue Type: Improvement
> Components: framework/webtools
>Affects Versions: 16.11.04
>Reporter: Rajesh Kumar Mallah
>Priority: Major
> Attachments: not-working.xml, working.xml
>
>
>
> The existing framework allows invoking various services via XMLRPC or SOAP
> as per their argument expectations. However only basic types are handled
> like String , Boolean , Int etc. If a service is expecting a GenericValue eg:
> 'calculateProductPrice' it is not possible to invoke it via SOAP or XMLRPC.
> The reason being SOAP or XMLRPC can support Map and that is the closest
> it can provide in lieu of any custom Object that a Service might be expecting.
> A generic solution needs to be found so that the full potential of the
> plethora of
> exportable services can be utilized by external systems that looks for
> integrating and
> banking upon OfBiz via XMLRPC or SOAP.
> h6. related Threads:
> [How to pass org.apache.ofbiz.entity.GenericValue using XMLRPC]
> [https://markmail.org/message/dwako4nsu4h3zgmu] [ dev ]
> [https://markmail.org/message/iuffmakor3ru2yce] [user]
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (OFBIZ-6747) Replace ConcurrentLinkedHashMap by Caffeine
[ https://issues.apache.org/jira/browse/OFBIZ-6747?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16509486#comment-16509486 ] Taher Alkhateeb commented on OFBIZ-6747: Amazing Ben, in a few words you're opening my eyes to a whole bunch of ideas and I'm still reading on all the algorithms. Really fascinating stuff thank you for sharing. If you can also recommend any books that would be awesome. A problem we'll face is that our code base is rather old and pretty much spaghetti patterns are everywhere and most of our code is a concrete implementation without interfaces. I have to think of how to wire this Cache interface with the rest of the architecture cleanly. Perhaps one way is to to try and apply the ConcurrentMap signature on all methods, then create an adapter if / when needed with the UtilCache to keep everything working smoothly as we disentangle references to the Util class or others. Phew hurts my head just to say that :) > Replace ConcurrentLinkedHashMap by Caffeine > --- > > Key: OFBIZ-6747 > URL: https://issues.apache.org/jira/browse/OFBIZ-6747 > Project: OFBiz > Issue Type: Task >Reporter: Ben Manes >Assignee: Jacques Le Roux >Priority: Minor > > Similar to OFBIZ-3779, please consider upgrading the library used by > [UtilCache|https://github.com/apache/ofbiz/blob/trunk/framework/base/src/org/ofbiz/base/util/cache/UtilCache.java] > (v1.2). The current version is 1.4.2 and is the last major release planned. > The preferable alternative would be to upgrade to > [Caffeine|https://github.com/ben-manes/caffeine]. This is a Java 8 rewrite > based on what I've learned since developing CLHM and Guava's cache. As > expected it provides [superior > performance|https://github.com/ben-manes/caffeine/wiki/Benchmarks]. It also > provides a [near > optimal|https://github.com/ben-manes/caffeine/wiki/Efficiency] eviction > policy. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
