Removal of JaxBUtil ?

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Removal of JaxBUtil ?

Fabian Lange
Hi,

i am looking into ways to trim down Karaf. I notices that Karaf uses JaxB
to parse features.xml - However this is the only application of JaxB.

Could somebody more involved help me to figure out if it is worth to
replace it with manual marshalling? I assume other xmls are parsed
differently?
Advantage would be that the whole jaxb infrastructure could be avoided,
including the contexts.

I know manual parsing is a pain, but anyway, just wanted to throw this out,
maybe somebody has a good suggestion.

Fabian
--
Fabian Lange | Performance Expert
mobil: +49 (0) 160.3673393

codecentric AG | Merscheider Straße 1 | 42699 Solingen | Deutschland

Sitz der Gesellschaft: Solingen | HRB 25917| Amtsgericht Wuppertal
Vorstand: Michael Hochgürtel . Mirko Novakovic . Rainer Vehns
Aufsichtsrat: Patric Fedlmeier (Vorsitzender) . Klaus Jäger . Jürgen Schütz
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Removal of JaxBUtil ?

jbonofre
Hi Fabian,

clearly, we adopted JAXB because we directly created the annotated POJO
and the marshalling/unmarshalling (as the feature parsing is also used
in the maven plugin MOJO) and it was easier than "manual" parsing.
Maintenance is also easier as just updated the POJOs work.

What would you propose as JAXB alternative ?

Regards
JB

On 07/14/2016 11:11 PM, Fabian Lange wrote:

> Hi,
>
> i am looking into ways to trim down Karaf. I notices that Karaf uses JaxB
> to parse features.xml - However this is the only application of JaxB.
>
> Could somebody more involved help me to figure out if it is worth to
> replace it with manual marshalling? I assume other xmls are parsed
> differently?
> Advantage would be that the whole jaxb infrastructure could be avoided,
> including the contexts.
>
> I know manual parsing is a pain, but anyway, just wanted to throw this out,
> maybe somebody has a good suggestion.
>
> Fabian
> --
> Fabian Lange | Performance Expert
> mobil: +49 (0) 160.3673393
>
> codecentric AG | Merscheider Straße 1 | 42699 Solingen | Deutschland
>
> Sitz der Gesellschaft: Solingen | HRB 25917| Amtsgericht Wuppertal
> Vorstand: Michael Hochgürtel . Mirko Novakovic . Rainer Vehns
> Aufsichtsrat: Patric Fedlmeier (Vorsitzender) . Klaus Jäger . Jürgen Schütz
>

--
Jean-Baptiste Onofré
[hidden email]
http://blog.nanthrax.net
Talend - http://www.talend.com
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Removal of JaxBUtil ?

Benson Margulies
In reply to this post by Fabian Lange
It's not a terribly complex data model, doing it with StAx by hand
wouldn't look so bad.

On Thu, Jul 14, 2016 at 5:11 PM, Fabian Lange
<[hidden email]> wrote:

> Hi,
>
> i am looking into ways to trim down Karaf. I notices that Karaf uses JaxB
> to parse features.xml - However this is the only application of JaxB.
>
> Could somebody more involved help me to figure out if it is worth to
> replace it with manual marshalling? I assume other xmls are parsed
> differently?
> Advantage would be that the whole jaxb infrastructure could be avoided,
> including the contexts.
>
> I know manual parsing is a pain, but anyway, just wanted to throw this out,
> maybe somebody has a good suggestion.
>
> Fabian
> --
> Fabian Lange | Performance Expert
> mobil: +49 (0) 160.3673393
>
> codecentric AG | Merscheider Straße 1 | 42699 Solingen | Deutschland
>
> Sitz der Gesellschaft: Solingen | HRB 25917| Amtsgericht Wuppertal
> Vorstand: Michael Hochgürtel . Mirko Novakovic . Rainer Vehns
> Aufsichtsrat: Patric Fedlmeier (Vorsitzender) . Klaus Jäger . Jürgen Schütz
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Removal of JaxBUtil ?

Guillaume Nodet-2
In reply to this post by Fabian Lange
Note that on older branches, the feature repositories are still parsed
using DOM
https://github.com/apache/karaf/blob/karaf-2.x/features/core/src/main/java/org/apache/karaf/features/internal/RepositoryImpl.java

The xml is now also written, that may be the reason why we switched.

2016-07-14 23:11 GMT+02:00 Fabian Lange <[hidden email]>:

> Hi,
>
> i am looking into ways to trim down Karaf. I notices that Karaf uses JaxB
> to parse features.xml - However this is the only application of JaxB.
>
> Could somebody more involved help me to figure out if it is worth to
> replace it with manual marshalling? I assume other xmls are parsed
> differently?
> Advantage would be that the whole jaxb infrastructure could be avoided,
> including the contexts.
>
> I know manual parsing is a pain, but anyway, just wanted to throw this out,
> maybe somebody has a good suggestion.
>
> Fabian
> --
> Fabian Lange | Performance Expert
> mobil: +49 (0) 160.3673393
>
> codecentric AG | Merscheider Straße 1 | 42699 Solingen | Deutschland
>
> Sitz der Gesellschaft: Solingen | HRB 25917| Amtsgericht Wuppertal
> Vorstand: Michael Hochgürtel . Mirko Novakovic . Rainer Vehns
> Aufsichtsrat: Patric Fedlmeier (Vorsitzender) . Klaus Jäger . Jürgen Schütz
>



--
------------------------
Guillaume Nodet
------------------------
Red Hat, Open Source Integration

Email: [hidden email]
Web: http://fusesource.com
Blog: http://gnodet.blogspot.com/
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Removal of JaxBUtil ?

Fabian Lange
Thanks, good hint.
For those inclined to understand my request, attached is the output of -XX:+TraceClassLoading

Using the xml binding feature approximately loads 800 classes (which represent about 5MB memory)

I haven't checked alternatives to the jaxb. And I am aware that this is a more esoteric requirement to reduce footprint.

However, I am sure if this would not be from the JDK, nobody would pull in a 5MB dependency to parse a single xml file.

Fabian


On Fri, Jul 22, 2016 at 9:25 AM, Guillaume Nodet <[hidden email]> wrote:
Note that on older branches, the feature repositories are still parsed
using DOM
https://github.com/apache/karaf/blob/karaf-2.x/features/core/src/main/java/org/apache/karaf/features/internal/RepositoryImpl.java

The xml is now also written, that may be the reason why we switched.

2016-07-14 23:11 GMT+02:00 Fabian Lange <[hidden email]>:

> Hi,
>
> i am looking into ways to trim down Karaf. I notices that Karaf uses JaxB
> to parse features.xml - However this is the only application of JaxB.
>
> Could somebody more involved help me to figure out if it is worth to
> replace it with manual marshalling? I assume other xmls are parsed
> differently?
> Advantage would be that the whole jaxb infrastructure could be avoided,
> including the contexts.
>
> I know manual parsing is a pain, but anyway, just wanted to throw this out,
> maybe somebody has a good suggestion.
>
> Fabian
> --
> Fabian Lange | Performance Expert
> mobil: <a href="tel:%2B49%20%280%29%20160.3673393" value="+491603673393">+49 (0) 160.3673393
>
> codecentric AG | Merscheider Straße 1 | 42699 Solingen | Deutschland
>
> Sitz der Gesellschaft: Solingen | HRB 25917| Amtsgericht Wuppertal
> Vorstand: Michael Hochgürtel . Mirko Novakovic . Rainer Vehns
> Aufsichtsrat: Patric Fedlmeier (Vorsitzender) . Klaus Jäger . Jürgen Schütz
>



--
------------------------
Guillaume Nodet
------------------------
Red Hat, Open Source Integration

Email: [hidden email]
Web: http://fusesource.com
Blog: http://gnodet.blogspot.com/


features-bundle-classloading.txt (164K) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Removal of JaxBUtil ?

Fabian Lange
Hey,
I have new intel on this. A colleague generated a flame graph.
I cannot share the raw svg unfortunately, but I cropped the Feature JAXB parsing.

It is about 25% of the overall startup time just to boot up the jaxb infrastructure.

Fabian


On Fri, Jul 22, 2016 at 10:06 AM, Fabian Lange <[hidden email]> wrote:
Thanks, good hint.
For those inclined to understand my request, attached is the output of -XX:+TraceClassLoading

Using the xml binding feature approximately loads 800 classes (which represent about 5MB memory)

I haven't checked alternatives to the jaxb. And I am aware that this is a more esoteric requirement to reduce footprint.

However, I am sure if this would not be from the JDK, nobody would pull in a 5MB dependency to parse a single xml file.

Fabian


On Fri, Jul 22, 2016 at 9:25 AM, Guillaume Nodet <[hidden email]> wrote:
Note that on older branches, the feature repositories are still parsed
using DOM
https://github.com/apache/karaf/blob/karaf-2.x/features/core/src/main/java/org/apache/karaf/features/internal/RepositoryImpl.java

The xml is now also written, that may be the reason why we switched.

2016-07-14 23:11 GMT+02:00 Fabian Lange <[hidden email]>:

> Hi,
>
> i am looking into ways to trim down Karaf. I notices that Karaf uses JaxB
> to parse features.xml - However this is the only application of JaxB.
>
> Could somebody more involved help me to figure out if it is worth to
> replace it with manual marshalling? I assume other xmls are parsed
> differently?
> Advantage would be that the whole jaxb infrastructure could be avoided,
> including the contexts.
>
> I know manual parsing is a pain, but anyway, just wanted to throw this out,
> maybe somebody has a good suggestion.
>
> Fabian
> --
> Fabian Lange | Performance Expert
> mobil: <a href="tel:%2B49%20%280%29%20160.3673393" value="+491603673393" target="_blank">+49 (0) 160.3673393
>
> codecentric AG | Merscheider Straße 1 | 42699 Solingen | Deutschland
>
> Sitz der Gesellschaft: Solingen | HRB 25917| Amtsgericht Wuppertal
> Vorstand: Michael Hochgürtel . Mirko Novakovic . Rainer Vehns
> Aufsichtsrat: Patric Fedlmeier (Vorsitzender) . Klaus Jäger . Jürgen Schütz
>



--
------------------------
Guillaume Nodet
------------------------
Red Hat, Open Source Integration

Email: [hidden email]
Web: http://fusesource.com
Blog: http://gnodet.blogspot.com/


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Removal of JaxBUtil ?

jbonofre
Hi Fabian,

interesting fact indeed. What alternate do you propose ?

Regards
JB

On 08/09/2017 10:46 AM, Fabian Lange wrote:

> Hey,
> I have new intel on this. A colleague generated a flame graph.
> I cannot share the raw svg unfortunately, but I cropped the Feature JAXB parsing.
>
> It is about 25% of the overall startup time just to boot up the jaxb infrastructure.
>
> Fabian
>
>
> On Fri, Jul 22, 2016 at 10:06 AM, Fabian Lange <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>     Thanks, good hint.
>     For those inclined to understand my request, attached is the output of
>     -XX:+TraceClassLoading
>
>     Using the xml binding feature approximately loads 800 classes (which
>     represent about 5MB memory)
>
>     I haven't checked alternatives to the jaxb. And I am aware that this is a
>     more esoteric requirement to reduce footprint.
>
>     However, I am sure if this would not be from the JDK, nobody would pull in a
>     5MB dependency to parse a single xml file.
>
>     Fabian
>
>
>     On Fri, Jul 22, 2016 at 9:25 AM, Guillaume Nodet <[hidden email]
>     <mailto:[hidden email]>> wrote:
>
>         Note that on older branches, the feature repositories are still parsed
>         using DOM
>         https://github.com/apache/karaf/blob/karaf-2.x/features/core/src/main/java/org/apache/karaf/features/internal/RepositoryImpl.java
>         <https://github.com/apache/karaf/blob/karaf-2.x/features/core/src/main/java/org/apache/karaf/features/internal/RepositoryImpl.java>
>
>         The xml is now also written, that may be the reason why we switched.
>
>         2016-07-14 23:11 GMT+02:00 Fabian Lange <[hidden email]
>         <mailto:[hidden email]>>:
>
>          > Hi,
>          >
>          > i am looking into ways to trim down Karaf. I notices that Karaf uses JaxB
>          > to parse features.xml - However this is the only application of JaxB.
>          >
>          > Could somebody more involved help me to figure out if it is worth to
>          > replace it with manual marshalling? I assume other xmls are parsed
>          > differently?
>          > Advantage would be that the whole jaxb infrastructure could be avoided,
>          > including the contexts.
>          >
>          > I know manual parsing is a pain, but anyway, just wanted to throw
>         this out,
>          > maybe somebody has a good suggestion.
>          >
>          > Fabian
>          > --
>          > Fabian Lange | Performance Expert
>          > mobil: +49 (0) 160.3673393 <tel:%2B49%20%280%29%20160.3673393>
>          >
>          > codecentric AG | Merscheider Straße 1 | 42699 Solingen | Deutschland
>          >
>          > Sitz der Gesellschaft: Solingen | HRB 25917| Amtsgericht Wuppertal
>          > Vorstand: Michael Hochgürtel . Mirko Novakovic . Rainer Vehns
>          > Aufsichtsrat: Patric Fedlmeier (Vorsitzender) . Klaus Jäger . Jürgen
>         Schütz
>          >
>
>
>
>         --
>         ------------------------
>         Guillaume Nodet
>         ------------------------
>         Red Hat, Open Source Integration
>
>         Email: [hidden email] <mailto:[hidden email]>
>         Web: http://fusesource.com
>         Blog: http://gnodet.blogspot.com/
>
>
>

--
Jean-Baptiste Onofré
[hidden email]
http://blog.nanthrax.net
Talend - http://www.talend.com
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Removal of JaxBUtil ?

Fabian Lange
I cannot really tell.
Whatever XML stream or Document parser we would use, it also would load new
classes and require some time to initialize.

JAXB is however known to be the most inefficient in that regard. On the
other hand it offers the most convenience because you get these nice mapped
POJOs.

Felix SCR does it manually as far as I can see:
https://github.com/apache/felix/blob/trunk/osgi-r7/scr/src/main/java/org/apache/felix/scr/impl/xml/XmlHandler.java
Felix IPojo uses sax:
https://github.com/apache/felix/blob/a4755e768329a29252b1d7d8e52537941768606d/ipojo/manipulator/manipulator/src/main/java/org/apache/felix/ipojo/xml/parser/XMLMetadataParser.java
Felix metatype uses xmlpullparser:
https://github.com/apache/felix/blob/a4755e768329a29252b1d7d8e52537941768606d/metatype/src/main/java/org/apache/felix/metatype/MetaDataReader.java

None of Felix uses jaxb.

Maybe its worth giving xmlpullparser a shot. The code of metatype looks
straigtforward, and the embedded classes are minimal.

Fabian


On Wed, Aug 9, 2017 at 10:53 AM, Jean-Baptiste Onofré <[hidden email]>
wrote:

> Hi Fabian,
>
> interesting fact indeed. What alternate do you propose ?
>
> Regards
> JB
>
> On 08/09/2017 10:46 AM, Fabian Lange wrote:
>
>> Hey,
>> I have new intel on this. A colleague generated a flame graph.
>> I cannot share the raw svg unfortunately, but I cropped the Feature JAXB
>> parsing.
>>
>> It is about 25% of the overall startup time just to boot up the jaxb
>> infrastructure.
>>
>> Fabian
>>
>>
>> On Fri, Jul 22, 2016 at 10:06 AM, Fabian Lange <
>> [hidden email] <mailto:[hidden email]>> wrote:
>>
>>     Thanks, good hint.
>>     For those inclined to understand my request, attached is the output of
>>     -XX:+TraceClassLoading
>>
>>     Using the xml binding feature approximately loads 800 classes (which
>>     represent about 5MB memory)
>>
>>     I haven't checked alternatives to the jaxb. And I am aware that this
>> is a
>>     more esoteric requirement to reduce footprint.
>>
>>     However, I am sure if this would not be from the JDK, nobody would
>> pull in a
>>     5MB dependency to parse a single xml file.
>>
>>     Fabian
>>
>>
>>     On Fri, Jul 22, 2016 at 9:25 AM, Guillaume Nodet <[hidden email]
>>     <mailto:[hidden email]>> wrote:
>>
>>         Note that on older branches, the feature repositories are still
>> parsed
>>         using DOM
>>         https://github.com/apache/karaf/blob/karaf-2.x/features/core
>> /src/main/java/org/apache/karaf/features/internal/RepositoryImpl.java
>>         <https://github.com/apache/karaf/blob/karaf-2.x/features/cor
>> e/src/main/java/org/apache/karaf/features/internal/RepositoryImpl.java>
>>
>>         The xml is now also written, that may be the reason why we
>> switched.
>>
>>         2016-07-14 23:11 GMT+02:00 Fabian Lange <
>> [hidden email]
>>         <mailto:[hidden email]>>:
>>
>>          > Hi,
>>          >
>>          > i am looking into ways to trim down Karaf. I notices that
>> Karaf uses JaxB
>>          > to parse features.xml - However this is the only application
>> of JaxB.
>>          >
>>          > Could somebody more involved help me to figure out if it is
>> worth to
>>          > replace it with manual marshalling? I assume other xmls are
>> parsed
>>          > differently?
>>          > Advantage would be that the whole jaxb infrastructure could be
>> avoided,
>>          > including the contexts.
>>          >
>>          > I know manual parsing is a pain, but anyway, just wanted to
>> throw
>>         this out,
>>          > maybe somebody has a good suggestion.
>>          >
>>          > Fabian
>>          > --
>>          > Fabian Lange | Performance Expert
>>          > mobil: +49 (0) 160.3673393 <tel:%2B49%20%280%29%20160.3673393>
>>          >
>>          > codecentric AG | Merscheider Straße 1 | 42699 Solingen |
>> Deutschland
>>          >
>>          > Sitz der Gesellschaft: Solingen | HRB 25917| Amtsgericht
>> Wuppertal
>>          > Vorstand: Michael Hochgürtel . Mirko Novakovic . Rainer Vehns
>>          > Aufsichtsrat: Patric Fedlmeier (Vorsitzender) . Klaus Jäger .
>> Jürgen
>>         Schütz
>>          >
>>
>>
>>
>>         --
>>         ------------------------
>>         Guillaume Nodet
>>         ------------------------
>>         Red Hat, Open Source Integration
>>
>>         Email: [hidden email] <mailto:[hidden email]>
>>         Web: http://fusesource.com
>>         Blog: http://gnodet.blogspot.com/
>>
>>
>>
>>
> --
> Jean-Baptiste Onofré
> [hidden email]
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Removal of JaxBUtil ?

jbonofre
Fair enough. Agree, worth to evaluate xmlpullparser.

Regards
JB

On 08/09/2017 11:04 AM, Fabian Lange wrote:

> I cannot really tell.
> Whatever XML stream or Document parser we would use, it also would load new
> classes and require some time to initialize.
>
> JAXB is however known to be the most inefficient in that regard. On the
> other hand it offers the most convenience because you get these nice mapped
> POJOs.
>
> Felix SCR does it manually as far as I can see:
> https://github.com/apache/felix/blob/trunk/osgi-r7/scr/src/main/java/org/apache/felix/scr/impl/xml/XmlHandler.java
> Felix IPojo uses sax:
> https://github.com/apache/felix/blob/a4755e768329a29252b1d7d8e52537941768606d/ipojo/manipulator/manipulator/src/main/java/org/apache/felix/ipojo/xml/parser/XMLMetadataParser.java
> Felix metatype uses xmlpullparser:
> https://github.com/apache/felix/blob/a4755e768329a29252b1d7d8e52537941768606d/metatype/src/main/java/org/apache/felix/metatype/MetaDataReader.java
>
> None of Felix uses jaxb.
>
> Maybe its worth giving xmlpullparser a shot. The code of metatype looks
> straigtforward, and the embedded classes are minimal.
>
> Fabian
>
>
> On Wed, Aug 9, 2017 at 10:53 AM, Jean-Baptiste Onofré <[hidden email]>
> wrote:
>
>> Hi Fabian,
>>
>> interesting fact indeed. What alternate do you propose ?
>>
>> Regards
>> JB
>>
>> On 08/09/2017 10:46 AM, Fabian Lange wrote:
>>
>>> Hey,
>>> I have new intel on this. A colleague generated a flame graph.
>>> I cannot share the raw svg unfortunately, but I cropped the Feature JAXB
>>> parsing.
>>>
>>> It is about 25% of the overall startup time just to boot up the jaxb
>>> infrastructure.
>>>
>>> Fabian
>>>
>>>
>>> On Fri, Jul 22, 2016 at 10:06 AM, Fabian Lange <
>>> [hidden email] <mailto:[hidden email]>> wrote:
>>>
>>>      Thanks, good hint.
>>>      For those inclined to understand my request, attached is the output of
>>>      -XX:+TraceClassLoading
>>>
>>>      Using the xml binding feature approximately loads 800 classes (which
>>>      represent about 5MB memory)
>>>
>>>      I haven't checked alternatives to the jaxb. And I am aware that this
>>> is a
>>>      more esoteric requirement to reduce footprint.
>>>
>>>      However, I am sure if this would not be from the JDK, nobody would
>>> pull in a
>>>      5MB dependency to parse a single xml file.
>>>
>>>      Fabian
>>>
>>>
>>>      On Fri, Jul 22, 2016 at 9:25 AM, Guillaume Nodet <[hidden email]
>>>      <mailto:[hidden email]>> wrote:
>>>
>>>          Note that on older branches, the feature repositories are still
>>> parsed
>>>          using DOM
>>>          https://github.com/apache/karaf/blob/karaf-2.x/features/core
>>> /src/main/java/org/apache/karaf/features/internal/RepositoryImpl.java
>>>          <https://github.com/apache/karaf/blob/karaf-2.x/features/cor
>>> e/src/main/java/org/apache/karaf/features/internal/RepositoryImpl.java>
>>>
>>>          The xml is now also written, that may be the reason why we
>>> switched.
>>>
>>>          2016-07-14 23:11 GMT+02:00 Fabian Lange <
>>> [hidden email]
>>>          <mailto:[hidden email]>>:
>>>
>>>           > Hi,
>>>           >
>>>           > i am looking into ways to trim down Karaf. I notices that
>>> Karaf uses JaxB
>>>           > to parse features.xml - However this is the only application
>>> of JaxB.
>>>           >
>>>           > Could somebody more involved help me to figure out if it is
>>> worth to
>>>           > replace it with manual marshalling? I assume other xmls are
>>> parsed
>>>           > differently?
>>>           > Advantage would be that the whole jaxb infrastructure could be
>>> avoided,
>>>           > including the contexts.
>>>           >
>>>           > I know manual parsing is a pain, but anyway, just wanted to
>>> throw
>>>          this out,
>>>           > maybe somebody has a good suggestion.
>>>           >
>>>           > Fabian
>>>           > --
>>>           > Fabian Lange | Performance Expert
>>>           > mobil: +49 (0) 160.3673393 <tel:%2B49%20%280%29%20160.3673393>
>>>           >
>>>           > codecentric AG | Merscheider Straße 1 | 42699 Solingen |
>>> Deutschland
>>>           >
>>>           > Sitz der Gesellschaft: Solingen | HRB 25917| Amtsgericht
>>> Wuppertal
>>>           > Vorstand: Michael Hochgürtel . Mirko Novakovic . Rainer Vehns
>>>           > Aufsichtsrat: Patric Fedlmeier (Vorsitzender) . Klaus Jäger .
>>> Jürgen
>>>          Schütz
>>>           >
>>>
>>>
>>>
>>>          --
>>>          ------------------------
>>>          Guillaume Nodet
>>>          ------------------------
>>>          Red Hat, Open Source Integration
>>>
>>>          Email: [hidden email] <mailto:[hidden email]>
>>>          Web: http://fusesource.com
>>>          Blog: http://gnodet.blogspot.com/
>>>
>>>
>>>
>>>
>> --
>> Jean-Baptiste Onofré
>> [hidden email]
>> http://blog.nanthrax.net
>> Talend - http://www.talend.com
>>
>

--
Jean-Baptiste Onofré
[hidden email]
http://blog.nanthrax.net
Talend - http://www.talend.com
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Removal of JaxBUtil ?

Daniel Kulp
Why not just use the StAX API’s built into the JDK to avoid another dependency?  That said, it’s likely using StAX might/should bring in woodstox.

Dan




> On Aug 9, 2017, at 5:11 AM, Jean-Baptiste Onofré <[hidden email]> wrote:
>
> Fair enough. Agree, worth to evaluate xmlpullparser.
>
> Regards
> JB
>
> On 08/09/2017 11:04 AM, Fabian Lange wrote:
>> I cannot really tell.
>> Whatever XML stream or Document parser we would use, it also would load new
>> classes and require some time to initialize.
>> JAXB is however known to be the most inefficient in that regard. On the
>> other hand it offers the most convenience because you get these nice mapped
>> POJOs.
>> Felix SCR does it manually as far as I can see:
>> https://github.com/apache/felix/blob/trunk/osgi-r7/scr/src/main/java/org/apache/felix/scr/impl/xml/XmlHandler.java
>> Felix IPojo uses sax:
>> https://github.com/apache/felix/blob/a4755e768329a29252b1d7d8e52537941768606d/ipojo/manipulator/manipulator/src/main/java/org/apache/felix/ipojo/xml/parser/XMLMetadataParser.java
>> Felix metatype uses xmlpullparser:
>> https://github.com/apache/felix/blob/a4755e768329a29252b1d7d8e52537941768606d/metatype/src/main/java/org/apache/felix/metatype/MetaDataReader.java
>> None of Felix uses jaxb.
>> Maybe its worth giving xmlpullparser a shot. The code of metatype looks
>> straigtforward, and the embedded classes are minimal.
>> Fabian
>> On Wed, Aug 9, 2017 at 10:53 AM, Jean-Baptiste Onofré <[hidden email]>
>> wrote:
>>> Hi Fabian,
>>>
>>> interesting fact indeed. What alternate do you propose ?
>>>
>>> Regards
>>> JB
>>>
>>> On 08/09/2017 10:46 AM, Fabian Lange wrote:
>>>
>>>> Hey,
>>>> I have new intel on this. A colleague generated a flame graph.
>>>> I cannot share the raw svg unfortunately, but I cropped the Feature JAXB
>>>> parsing.
>>>>
>>>> It is about 25% of the overall startup time just to boot up the jaxb
>>>> infrastructure.
>>>>
>>>> Fabian
>>>>
>>>>
>>>> On Fri, Jul 22, 2016 at 10:06 AM, Fabian Lange <
>>>> [hidden email] <mailto:[hidden email]>> wrote:
>>>>
>>>>     Thanks, good hint.
>>>>     For those inclined to understand my request, attached is the output of
>>>>     -XX:+TraceClassLoading
>>>>
>>>>     Using the xml binding feature approximately loads 800 classes (which
>>>>     represent about 5MB memory)
>>>>
>>>>     I haven't checked alternatives to the jaxb. And I am aware that this
>>>> is a
>>>>     more esoteric requirement to reduce footprint.
>>>>
>>>>     However, I am sure if this would not be from the JDK, nobody would
>>>> pull in a
>>>>     5MB dependency to parse a single xml file.
>>>>
>>>>     Fabian
>>>>
>>>>
>>>>     On Fri, Jul 22, 2016 at 9:25 AM, Guillaume Nodet <[hidden email]
>>>>     <mailto:[hidden email]>> wrote:
>>>>
>>>>         Note that on older branches, the feature repositories are still
>>>> parsed
>>>>         using DOM
>>>>         https://github.com/apache/karaf/blob/karaf-2.x/features/core
>>>> /src/main/java/org/apache/karaf/features/internal/RepositoryImpl.java
>>>>         <https://github.com/apache/karaf/blob/karaf-2.x/features/cor
>>>> e/src/main/java/org/apache/karaf/features/internal/RepositoryImpl.java>
>>>>
>>>>         The xml is now also written, that may be the reason why we
>>>> switched.
>>>>
>>>>         2016-07-14 23:11 GMT+02:00 Fabian Lange <
>>>> [hidden email]
>>>>         <mailto:[hidden email]>>:
>>>>
>>>>          > Hi,
>>>>          >
>>>>          > i am looking into ways to trim down Karaf. I notices that
>>>> Karaf uses JaxB
>>>>          > to parse features.xml - However this is the only application
>>>> of JaxB.
>>>>          >
>>>>          > Could somebody more involved help me to figure out if it is
>>>> worth to
>>>>          > replace it with manual marshalling? I assume other xmls are
>>>> parsed
>>>>          > differently?
>>>>          > Advantage would be that the whole jaxb infrastructure could be
>>>> avoided,
>>>>          > including the contexts.
>>>>          >
>>>>          > I know manual parsing is a pain, but anyway, just wanted to
>>>> throw
>>>>         this out,
>>>>          > maybe somebody has a good suggestion.
>>>>          >
>>>>          > Fabian
>>>>          > --
>>>>          > Fabian Lange | Performance Expert
>>>>          > mobil: +49 (0) 160.3673393 <tel:%2B49%20%280%29%20160.3673393>
>>>>          >
>>>>          > codecentric AG | Merscheider Straße 1 | 42699 Solingen |
>>>> Deutschland
>>>>          >
>>>>          > Sitz der Gesellschaft: Solingen | HRB 25917| Amtsgericht
>>>> Wuppertal
>>>>          > Vorstand: Michael Hochgürtel . Mirko Novakovic . Rainer Vehns
>>>>          > Aufsichtsrat: Patric Fedlmeier (Vorsitzender) . Klaus Jäger .
>>>> Jürgen
>>>>         Schütz
>>>>          >
>>>>
>>>>
>>>>
>>>>         --
>>>>         ------------------------
>>>>         Guillaume Nodet
>>>>         ------------------------
>>>>         Red Hat, Open Source Integration
>>>>
>>>>         Email: [hidden email] <mailto:[hidden email]>
>>>>         Web: http://fusesource.com
>>>>         Blog: http://gnodet.blogspot.com/
>>>>
>>>>
>>>>
>>>>
>>> --
>>> Jean-Baptiste Onofré
>>> [hidden email]
>>> http://blog.nanthrax.net
>>> Talend - http://www.talend.com
>>>
>
> --
> Jean-Baptiste Onofré
> [hidden email]
> http://blog.nanthrax.net
> Talend - http://www.talend.com

--
Daniel Kulp
[hidden email] - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com

Loading...