• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Tim Cooke
  • paul wheaton
  • Jeanne Boyarsky
  • Ron McLeod
Sheriffs:
  • Paul Clapham
  • Liutauras Vilda
  • Devaka Cooray
Saloon Keepers:
  • Tim Holloway
  • Roland Mueller
Bartenders:

inner classes ???

 
Ranch Hand
Posts: 156
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi,
Was just wondering if using inner classes is a good idea in midlets with the memory restrictions..
Does everyone use inner classes when it makes sense or just try to avoid them???
 
ranger
Posts: 17347
11
Mac IntelliJ IDE Spring
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
The only time in my coding that I ever use an Inner class are anonymous inner classes for my controller to hook into the view. in Swing.
Why not make that a seperate plain Java class that your Midlet creates an instance and uses?
My 2 cents.
Mark
 
Ranch Hand
Posts: 45
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
One of the largest realities of programming J2ME applications in my experience is the MIDlet size restrictions that are imposed. There is an overhead to every Java class you have in your MIDlet. This applies to inner classes and normal classes. It doesn't make any difference to go normal class compared to inner-class. We noticed about a 600 byte overhead for a class (uncompressed). They add up very quickly.
We wrote a flash player in BREW and J2ME. Without function pointers in J2ME we used separate classes for our action and condition handling. It was great except that the MIDlet size was 300Kb. We eventually got it down to 50Kb (and were able to deploy) but this involved things that would make Mark freak out. With a tear in my eye, I washed my hands every night when I'd finished.
We gained a large benefit by reducing the number of classes we had. We also noticed that the classes seemed to hit a sweet spot with the JAR compression when they got above 32Kb (uncompressed). After working with a lot of PNGs I realised this was due to the 32Kb sliding window that the ZIP algorithm uses for compression. When you hit 32Kb for a class file (after obfuscation - we used DashO) you maximise the benefit from the sliding window. The benefit is linear thereafter.
Our technique we used for this is was to assimilate classes into a parent class for where there was a 1:1 ratio. They we just prefixed the method names with the old class names. You get very big java files but it's still vaguely manageable if you originated from an OO design. Also, we did some extremely nasty things by assimilating children classes (where there was a 1:m relationship) by moving the methods up to the parent, passing in the object to the method call and turning the fields for the children objects into Object arrays.
For example our linked list class was assimilated by the MIDlet class. A list was an Object[]. A List node was an Object[]. The lists enqueue method was implemented by the MIDlet by passing in the list "object" as a parameter. Very nasty - lots of casting - you've got to write down how each object breaks down.
I love writing J2SE and J2EE code. Writing J2ME code is a different kettle of fish in my opinion.
PK
 
author
Posts: 1436
6
Python TypeScript Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks for sharing this.

Originally posted by Paul Kelcey:
Our technique we used for this is was to assimilate classes into a parent class for where there was a 1:1 ratio. They we just prefixed the method names with the old class names. You get very big java files but it's still vaguely manageable if you originated from an OO design. Also, we did some extremely nasty things by assimilating children classes (where there was a 1:m relationship) by moving the methods up to the parent, passing in the object to the method call and turning the fields for the children objects into Object arrays.


That is called "refactoring". But seriously, I think the 30-50k memory restriction of Java phones will soon become a thing of the past, unless your program absolute need to reach the low end of the consumer market. In my opinon, the strength of Java is not WORA (can you call J2ME WORA?) but developer productivity. Given the right tool and execution environment, Java allows us to write better code more quickly. Moore's law is on our side.
 
Greenhorn
Posts: 4
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I think to reduce the size of wireless Java applications we shud avoid inner classes. Many programmers use inner classes, to implement event listeners for example. It is convenient, but behind the scenes the compiler generates special instructions to allow the inner class to access the outer class's private data.
Redefining the inner class to be a separate helper class would eliminate the extra overhead.
 
Ranch Hand
Posts: 114
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
well, I'm not sure how to check the size of the post-verified(?) class files on the phone, but I know for a fact there is no difference in size in a preverified class, if I (for example) implement CommandListener on the displayable ala:

or do an inner class:

Is this the use of inner classes to which you refer? Or am I misunderstanding something here?
 
Paul Kelcey
Ranch Hand
Posts: 45
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
That's not what I encountered.
When you use an anonymous inner class like that you get a PrimaryClass$1.class file as well. Did you include that second class in your calculations? I think it adds a few hundred bytes to JAR because of the class header and crap like that in the byte code.
I agree with Michael that eventually things will be better on the clients. However, if you want to get a head-start in the market you sometimes have to make compromises.
PK
 
Jason Fox
Ranch Hand
Posts: 114
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
wow, I was only looking at (Main).class, not at the seperate inner class files. I feel kinda silly.
 
Michael Yuan
author
Posts: 1436
6
Python TypeScript Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
The best way is to look at the size of the JAR file -- I suppose.
 
Space pants. Tiny ad:
Smokeless wood heat with a rocket mass heater
https://woodheat.net
reply
    Bookmark Topic Watch Topic
  • New Topic