[
https://issues.apache.org/jira/browse/LUCENE-6239?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14316368#comment-14316368
]
Robert Muir commented on LUCENE-6239:
-------------------------------------
{quote}
Which motivating element you think is specifically important other than the one
resulting from potentially smaller memory load/ load time? Because I fail to
see anything worthy mentioning other than that. With jigsaw already shipping
you get most of the benefits of profiles anyway (these stem from the fact that
there's no monolithic rt.jar to parse/ map into memory).
{quote}
I think mike's response on that issue already explains my perspective on it.
and to boot, by doing this i found a test bug as well (use of
javax.management.Query when it should have been
org.apache.lucene.search.Query). To me its just proper java 8 adoption, to
define what portions of the JDK we are using. If there is really some feature
we want in lucene-core that requires compact3 or whatever, i mean this is like
a warning sign, why do we need such an advanced API to implement search?
But please, this should really be discussed on LUCENE-6069.
And I think your reasoning is slightly biased, we all know the only thing
standing in the way of this stuff is RamUsageEstimator.
> Remove RAMUsageEstimator Unsafe calls
> -------------------------------------
>
> Key: LUCENE-6239
> URL: https://issues.apache.org/jira/browse/LUCENE-6239
> Project: Lucene - Core
> Issue Type: Bug
> Reporter: Robert Muir
>
> This is unnecessary risk. We should remove this stuff, it is not needed here.
> We are a search engine, not a ram calculator.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
