[
https://issues.apache.org/jira/browse/FELIX-6218?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17026112#comment-17026112
]
Tom Watson commented on FELIX-6218:
-----------------------------------
I think another reason was the speed of the kxml parser versus the builtin one
in the JVM. It would be good to at least keep an eye on the performance when
dropping this.
> Consider dropping SCR's requirement on kxml2
> --------------------------------------------
>
> Key: FELIX-6218
> URL: https://issues.apache.org/jira/browse/FELIX-6218
> Project: Felix
> Issue Type: Improvement
> Components: Declarative Services (SCR)
> Affects Versions: scr-2.1.16
> Reporter: Mat Booth
> Priority: Major
>
> Currently SCR requires kxml2 (and transitively xpp3) at build time and them
> embeds some classes from these two libraries in the resulting Felix SCR
> bundle. However these projects seem quite dead and have not seen any official
> activity in many years. [1]
> When I tried to investigate why Felix SCR uses kxml2, I hit a dead-end
> because the repository history does not go back far enough. SCR seems to have
> been imported already using kxml2/xpp3.
> Two possibilities spring to mind:
> * It was before Java 1.5, so there was no SAX implementation in the JDK yet
> * SCR used to target some constrained execution environment that it no
> longer supports.
> In either case, since Felix SCR now requires JavaSE-1.7 as its minimal
> execution environment I advocate switching to the SAX implementation provided
> by the JDK
>
> I will post a PR
>
> [1] http://www.xmlpull.org/
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
