[
https://issues.apache.org/jira/browse/FELIX-3202?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13146070#comment-13146070
]
Richard S. Hall edited comment on FELIX-3202 at 11/8/11 4:14 AM:
-----------------------------------------------------------------
(3) Java basically encourages people to create classes all over the place for
listeners, tasks, etc. At the Java source file level these classes are hidden
and appear cost free since they are in the same source file, but once compiled
(as you probably know) they are expanded out into tons of separate classes,
resulting in major class loading storms when starting an application. Granted,
the framework has already grown beyond what I am happy with since the spec
continues to bloat, but I still worry about these issues. The framework is
intended to run on everything from small devices to servers, so everyone
benefits if we can keep it tight. I'd be happier with patches that removed
large pieces of unnecessary junk to make it smaller, rather than adding tons of
stuff to make it more readable. Clearly, this is a losing battle over time (if
not lost already) and there is tension because sometimes abstractions are
useful even though they may bloat the implementation. It's a balancing act and
there is no clear right or wrong answer, it just depends.
(4) I believe the numbers you are seeing, I questioned whether you were
comparing your matching against SimpleFilter matching with indexing in
CapabilitySet or with just straight matching. Looking at the patch, I see that
indices don't really come into play. Still, if there are improvements that can
be made to how matching is currently performed in the non-indexed case, let's
figure out how we can improve the current matching algorithm without throwing
everything completely away.
Even though it may not seem like it, I do appreciate you looking into this. :-)
was (Author: rickhall):
(3) Java basically encourages people to create classes all over the place
for listeners, tasks, etc. At the .java these classes are hidden and appear
cost free since they are in the same source file, but once compiled (as you
probably know) they are expanded out into tons of separate classes, resulting
into major class loading storms when starting an application. Granted, the
framework has already grown beyond what I am happy with since the spec
continues to bloat, but I still worry about these issues. The framework is
intended to run on everything from small devices to servers, so everything
benefits if we can keep it tight. I'd be happier with patches that removed
large pieces of unnecessary junk to make it smaller, rather than adding tons of
stuff to make it more readable. Clearly, this is a losing battle over time (if
not lost already) and there is tension because sometimes abstractions are
useful even though they may bloat the implementation. It's a balancing act and
there is no clear right or wrong answer, it just depends.
(4) I believe the numbers you are seeing, I questioned whether you were
comparing your matching against SimpleFilter matching with indexing in
CapabilitySet or with just straight matching. Looking at the patch, I see that
indices don't really come into play. Still, if there are improvements that can
be made to how matching is currently performed in the non-indexed case, let's
figure out how we can improve the current matching algorithm without throwing
everything completely away.
Even though it may not seem like it, I do appreciate you looking into this. :-)
> Add generic type information to SimpleFilter
> --------------------------------------------
>
> Key: FELIX-3202
> URL: https://issues.apache.org/jira/browse/FELIX-3202
> Project: Felix
> Issue Type: Improvement
> Components: Framework
> Reporter: Lucas Galfaso
> Priority: Minor
> Attachments: felix_java5_filter.diff
>
>
> SimpleFilter does not have Java 5 generic type information and it is very
> hard to add this to the current implementation.
> Devise a way to add generate type information to SimpleFilter while keeping
> in mind that this is a critical component and any performance degradation
> would slow down the entire framework
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
