• Post Reply Bookmark Topic Watch Topic
  • New Topic

Is there a quick way to make an API light weight  RSS feed

 
Ranch Hand
Posts: 3404
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi ,
Would I be able to make say the Swing API lightweight by just extracting the classes used in my application ?
Obviously, while still preserving polymorphism (interfaces) and inheritance .
Just for deployment purposes ?
regards
[ June 16, 2003: Message edited by: HS Thomas ]
 
HS Thomas
Ranch Hand
Posts: 3404
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I'd like to use the Swing API but I'm told that it is too heavyweight for the applications they have in mind.
By this they usually mean size, don't they ,
not performance ?
While my application isn't quite for J2ME , I'd still like to keep an eye on the total size.
regards
 
Ranch Hand
Posts: 192
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Swing components needs more memory.
Swing is Lightweight.
AWT is Heavyweight.
If you mix Swing and AWT components AWT will be drawn on top of Swing components.
If you want to know more about the topic of Lightweight vs Heavyweight, read about z-ordering.
Thank you
Garandi
 
HS Thomas
Ranch Hand
Posts: 3404
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks Garandi.
So its not just size. You have to consider performance to deem it lightweight.
It is
  • how the component interacts with the local window manager.
  • how it interacts with the AWT event queue.


  • So just extracting the classes I need isn't going to make it lightweight.
    regards
    [ June 17, 2003: Message edited by: HS Thomas ]
     
    HS Thomas
    Ranch Hand
    Posts: 3404
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    It occured to me that perhaps I should consider the memory footprint of Swing rather than its lightweight..
    And I have here a paper to help.
    System checkpointing using Reflection and Program Analysis
    If anyone can add anything else I'd be much obliged.

    regards
    [ June 17, 2003: Message edited by: HS Thomas ]
    The Java programming language has gained a significant following due to a
    number of reasons, including its clean, object-oriented design and automatic
    storage management. It is a very popular choice for server-side applications;
    however, on the client side, Java has yet to make significant headway against
    more established languages like C and C++.
    There are currently two major problems that must be overcome before Java
    can become prevalent on the client side. The first is application startup time [5].
    Applications using the Swing GUI interface can take on the order of minutes
    to start up. This is due to a number of factors, including large amounts of
    inecient initialization code in the class libraries and the fact that (in most
    virtual machines) the code is recompiled from class files on every execution.
    The second major stumbling block in the adoption of Java on the client side
    is memory footprint. Even simple GUI applications can regularly consume 20
    megabytes or more of memory [8]. What is more, in most systems this memory
    is not shared among applications, which means that 20 megabytes per running
    instance are consumed. Again, this is due to a number of factors, including the
    liberalism of virtual machine garbage collectors in allocating memory and the
    dynamic and object-oriented nature of the Java language. Because of dynamic
    features such as reflection and dynamic class loading, the system cannot perform
    whole-program analysis to eliminate the (as-of-yet) unused fields, methods, and
    other runtime data structures.
    To attack these problems, we developed a general technique of checkpointing
    the state of the system using reflection. Checkpointing is the act of saving the
    state of a running system such that it can be recreated later in time. Checkpointing
    has many applications, including system recovery, debugging, bootstrapping,
    and process migration. We use checkpointing for a dierent purpose. By running
    the system up to a certain point and then checkpointing it, we can use the checkpointed
    version to avoid startup time costs; in essence, application startup time
    becomes bounded only by disk latency. Furthermore, we can perform analysis
    during the checkpointing process to optimize the system, reducing the memory
    footprint by eliminating unnecessary code, objects, fields, classes, and runtime
    data structures.
    Using reflection makes our technique very flexible. Because we use reflection,
    we can precisely control the checkpointing process, deciding what data to ignore
    and what data needs to be reinitialized on virtual machine startup. Furthermore,
    the technique is entirely virtual machine and architecture independent;
    we actually use this technique to bootstrap the joeq virtual machine across
    platforms

    [ June 17, 2003: Message edited by: HS Thomas ]
     
    • Post Reply Bookmark Topic Watch Topic
    • New Topic
    Boost this thread!