Java me 对J2ME友好的IoC容器的搜索正在进行！

我正处于Blackberry/J2ME项目的开始阶段——加上这个出色的平台带来的其他限制，缺乏对反射和1.3语言级别的支持意味着绝大多数现有的IoC容器无法使用。（谷歌的Android Guice没有AOP，但即便如此，也需要对注释的支持）

因此，J2ME上IoC容器的空间非常有限。引起我注意的一个框架叫做，它看起来很有前途。它试图在概念上接近Spring框架的IoC，实现其功能的一小部分，并且不依赖字节码修改或导致运行时xml解析。相反，它在构建时处理配置XML以生成实现此IoC功能的java代码

一般来说，在构建时生成代码对于移动应用程序来说似乎是一种非常明智的方法——如果我的应用程序必须在用户设备上少做XML解析，那也太好了

---

那么，您在J2ME/CLDC上实现IoC的经验是什么？您是如何消除口腔中的苦味的

在J2ME中，您需要尽可能减少使用的类的数量，以减少jar文件的大小。这导致了许多设计上的折衷，尤其是灵活性

当你不得不把你所学到的（并高度重视）关于面向对象的知识扔出窗外时，适应J2ME开发并不容易。事实是，如果你想让应用程序能够在大量手机上运行，你就需要对设备的限制非常敏感

因此，我认为IoC框架无法满足许多人对J2ME开发的需求。

的确如此

---

更新：不幸的是，Signal现在还没有完全煮熟，所以我会选择定制的附加功能。

您可能有兴趣退房。尽管我没有亲自使用过它，但它似乎是一个专门为J2ME平台构建的无意义框架。

我在一次荷兰JAG会议上遇到过（对它没有任何经验）。

我们在TomTom使用过它。结果很好

Danke shön感谢您的洞察力，Grouchal:）我同意您关于必须在J2ME上搁置一些应用程序设计偏好的想法。然而，我认为我能负担得起使用IoC框架的原因是，我正在开发的应用程序将针对更强大的基于CLDC的设备，如S60上的黑莓和J2ME（以及Android，带有一些MOD）。CLDC 1.0施加的限制背后的想法在CLDC 1.0构思时非常棒；然而，今天看来，大多数感兴趣的设备功能更强大，存储空间也更多。因此，我们是否可以将良好的开发实践（如使用IoC）转移到移动java开发中，这是一个很自然的问题。而且，正如我所说，如果这可以通过构建时代码生成而不是在运行时完成，并且它在代码组织的清晰性方面实现了显著的改进——为什么不使用它呢？