We Keep Coding

How to organize larger Java projects - Projects vs. Namespacing?

I'm wondering if there is some recommended reading, best practice or opinion on how to organize larger Java projects.
I made the observations that there are folks who split up everything into projects (i.e. modules) and create many many projects that share a web of dependencies. This has the advantage that compilation is often super fast, but when the project gets large nobody knows anymore what depends on what and why. Not talking about dependent libraries, version conflicts & co.
The alternative is to have just a couple of projects such as frontend, backend, ... . The namespacing does the job.
Any opinion, further reading anyone could recommend?

As soon as you start splitting a big project up into smaller projects, you encounter a lot of dependency tracking that you generally didn't have to consider. You could manage this yourself or you could use software which already handles a lot of the core issues.
I would recommend Apache's Ivy. It integrates well with Apache's Ant, and has a separate configuration file (which gets checked in) to track what is required for each kind of build.
Apache's Maven is another good choice; however, it does a lot more than Apache's Ivy. Sometimes that "a lot more" means you doing less of what you would have done anyway, sometimes that "a lot more" means you are doing (and configuring) things that you didn't do before. Depending on the fit of your practice to Maven's, migrating to Maven might be easy or very hard.
In addition, using Ivy, you can set up your own private repository of "permitted" jar files to pull from, and that will make code auditing much easier. Basically, reconfigure ivy to not pull from the web, but to pull from your local repository only, and then control access to the repository to only allow jar files which were reviewed to have acceptable licensing.
Once you have software in place, you can afford to split projects up into smaller pieces. This will permit you to do the right thing (if your project favors small decomposition) instead of the expedient thing (a few big chunks which might not really buy you much in decomposition maintainability). As far as where to make the cuts, that depends heavily on the specifics of your application.
Many small pieces tend to be easier for a new person to digest one-by-one. They also get people thinking about where functionality is to be added to a project; however, it does cost time and effort to untangle and separate all of the components. The plus side is that it is generally easier to test and validate something smaller, the downside is that it is a longer road to decompose one monolithic collection of responsibilities into many small, well integrated yet functionally disparate units.
Good luck

A very large project will need to have some way of tracking all of the libraries and other dependencies that it uses. The defacto standard for doing this is Maven. It's definitely the best way to start keeping track of what is going into your application.
Then you can decide how to split your application up. Basically, what you're trying to do here is to split up your application up into complete functional pieces. For instance, if you had a website that had a contact form, a photo gallery, a shopping cart, and a forum, you would split the project up into pieces that contained each of those different modules.

Actually, you will want to utilize both projects and namespacing.
Namespacing is an important tool for differentiating what purpose a code has at the code level. Regardless of what project a class comes from, the package should give me some idea of its purpose.
At a higher level, it is easier to manage builds and your development environment by having your code separated into projects. For instance, if you are developing a UI, why do you need to have the database code loaded into you IDE? It is just extra clutter in your workspace. It also makes it simpler to share common functionality between different projects. This will of course lead to needing some form of dependency management, of which either of the mentioned tools such as Maven or Ivy will suffice.
An important note though. Do not use split packages between projects. This causes nightmares if you or anyone who will ever use your code wants to do so in an OSGi environment. So, your namespaces should be unique within a project, although they should share a common root with other related projects.

Should I be concerned with large number of dependencies?

I was just about to include the HtmlUnit library in a project. I unpacked the zip-file and realised that it had no less than 12 dependencies.
I've always been concerned when it comes to introducing dependencies. I suppose I have to ship all these dependencies together with the application (8.7 mb in this particular case). Should I bother checking for, say, security updates for these libraries? Finally (and most importantly, actually what I'm most concerned about): What if I want to include another library which depends on the same libraries as this library, but with different versions? That is, what if for instance HtmlUnit depends on one version of xalan and another library I need, depends on a different version of xalan?
The task HtmlUnit solves for me could be solved "manually" but that would probably not be as elegant.
Should I be concerned about this? What are the best practices in situations like these?
Edit: I'm interested in the general situation, not particularly involving HtmlUnit. I just used it here as an example as that was my current concern.

Handle your dependencies with care. They can bring you much speed, but can be a pain to maintain down the road. Here are my thoughts:
Use some software to maintain your dependencies. Maven is what I would use for Java to do this. Without it you will very soon loose track of your dependencies.
Remember that the various libraries have different licenses. It is not granted that a given license works for your setting. I work for a software house and we cannot use GPL based libraries in any of the software we ship, as the software we sell are closed source. Similarly we should avoid LGPL as well if we can (This is due to some intricate lawyer reasoning, don't ask me why)
For unit testing I'd say go all out. It is not the end of the world if you have to rewrite your tests in the future. It might even be then that that part of the software is either extremely stable or maybe not even maintained no more. Loosing those is not that big of a deal as you already had a huge gain of gaining speed when you got it.
Some libraries are harder to replace later than others. Some are like a marriage that should last the life of the software, but some other are just tools that are easily replaceable. (Think Spring versus an xml library)
Check out how the community support older versions of the library. Are they supporting older versions? What happens when life continues and you are stuck at a version? Is there an active community or do you have the skill to maintain it yourself?
For how long are your software supposed to last? Is it one year, five year, ten year or beyond? If the software has short time span, then you can use more to get where you are going as it is not that important to be able to keep up with upgrading your libraries.

It could be a serious issue if there isn't a active community which does maintain the libraries on long term. It is ok to use libraries, but to be honest you should care to get the sources and put them into your VCS.

Should I bother checking for, say, security updates for these libraries?
In general, it is probably a good idea to do this. But then so should everyone upstream and downstream of you.
In your particular case, we are talking about test code. If potential security flaws in libraries used only in testing are significant, your downstream users are doing something strange ...
Finally (and most importantly, actually what I'm most concerned about): What if I want to include another library which depends on the same libraries as this library, but with different versions? That is, what if for instance HtmlUnit depends on one version of xalan and another library I need, depends on a different version of xalan?
Ah yes. Assuming that you are building your own classpaths, etc by hand, you need to make a decision about which version of the dependent libraries you should use. It is usually safe to just pick the most recent of the versions used. But if the older version is not backwards incompatible with the new (for your use case) then you've got a problem.
Should I be concerned about this?
IMO, for your particular example (where we are talking about test code), no.
What are the best practices in situations like these?
Use Maven! It explicitly exposes the dependencies to the folks who download your code, making it possible for them to deal with the issue. It also tells you when you've got dependency version conflicts and provides a simple "exclude" mechanism for dealing with it.
Maven also removes the need to create distributions. You publish just your artifacts with references to their dependents. The Maven command then downloads the dependent artifacts from wherever they have been published.
EDIT
Obviously, if you are using HtmlUnit for production code (rather than just tests), then you need to pay more attention to security issues.

A similar thing has happened to me actually.
Two of my dependencies had the same 'transitive' dependency but a different version.
My favorite solution is to avoid "dependency creep" by not including too many dependencies. So, the simplest solution would be to remove the one I need less, or the one I could replace with a simple Util class, etc.
Too bad, it's not always that simple. In unfortunate cases where you actually need both libraries, it is possible to try to sync their versions, i.e. downgrade one of them so that dependency versions match.
In my particular case, I manually edited one of the jars, deleted the older dependency from it, and hoped it would still work with new version loaded from other jar. Luckily, it did (i.e. maintainers of the transitive dependency didn't remove any classes or methods that library used).
Was it ugly - Yes (Yuck!), but it worked.

I try to avoid introducing frivolous dependencies, because it is possible to run into conflicts.
One interesting technique I have seen used to avoid conflicts: renaming a library's package (if its license allows you to -- most BSD-style licenses do.) My favorite example of this is what Sun did when they built Xerces into the JRE as the de-facto JAXP XML parser: they renamed the whole of Xerces from org.apache.xerces to com.sun.org.apache.xerces.internal. Is this technique drastic, time consuming, and hard to maintain? Yes. But it gets the job done, and I think it is an important possible alternative to keep in mind.
Another possibility is -- license terms abided -- copying/renaming single classes or even single methods out of a library.
HtmlUnit can do a lot, though. If you are really using a large portion of its functionality on a lot of varied input data, it would be hard to make a case for spending the large amount of time it would take to re-write the functionality from scratch, or repackage it.
As for the security concerns -- you might weigh the chances of a widely used library having problems, vs. the likelihood of your hand-written less-tested code having some security flaw. Ultimately you are responsible for the security of your programs, though -- so do what you feel you must.

How to refactor thousands of lines of Java code? Is there any tool available?

In our application we have two or three classes which contains the entire Java Swing application logic. These two or three classes contain around 7k lines of code.
Now I have been assigned the task to refactor this Java code.
How do I start? Is there any tool available that will do the refactoring or at least guide us?

I'd recommend Eclipse - the brilliant Java IDE for the editing and refactoring. It has several tools for refactoring. An excellent tutorial on how to do it with Eclipse is located at:
http://www.cs.umanitoba.ca/~eclipse/13-Refactoring.pdf
There's a brililant article on the power of refactoring with Eclipse, if you're not yet convinced, at:
http://www.eclipse.org/articles/article.php?file=Article-Unleashing-the-Power-of-Refactoring/index.html
And finally another article on how to refactor in Eclipse, including techniques and tools, is available at:
http://www.ibm.com/developerworks/opensource/library/os-ecref/
There's also another stackoverflow question on strategies for refactoring Java code that you may be interested in:
https://stackoverflow.com/questions/128498/what-are-the-best-code-refactoring-strategies
Hope that helps, good luck!

I assume that you are trying to break up these large classes into smaller ones. The most common way to do this is with the Extract Class refactoring. It just happens that this is a major topic in my PhD thesis work.
One of the hard parts is deciding what goes into the new classes. There are two publicly available tools that I know of that help - ExtC (my tool) and JDeodorant. Both are Eclipse plug-ins, and I would classify both as being prototypes. If you want to try to use my tool, I'll be glad to help.
Once you decide what should go into the new class, you have to do the actual work of separating the class into others. Eclipse's Extract Class refactoring is misnamed and isn't really helpful. IntelliJ's IDEA is much better, but still has some bugs. JDeodorant can also perform the split, but it also has some bugs.

IntelliJ has all the smarts for understanding Java code and provides excellent refactorings. And now there is a free and open source version.

Eclipse has some built-in refactoring tools. You could refactor method's signatures, extract interfaces and classes, pull methods up and down in the hierarchy tree, move packages ... and all that just by two clicks.
Also, you could start with a Martin Fowler book "Refactoring: Improving the Design of Existing Code".

As refactoring code relies primarily on the developer (assisted by tooling), your IDE is a very important tool when it comes to refactoring.
Both Eclipse and IntelliJ IDEA have plenty of refactoring support.
For an overview, checkout:
http://www.jetbrains.com/idea/features/refactoring.html
http://help.eclipse.org/galileo/index.jsp?topic=/org.eclipse.jdt.doc.user/concepts/concept-refactoring.htm

I have created my own refactoring tool that tries and group together methods that use the same set of variables. It is very much an early prototype. It is only available as a Windows Eclipse plugin.
Variable Usage Eclipse Plugin

Eclipse as an IDE - What do you find missing as a beginner in Java?

I am working on a solution that aims at solving problems that newbie programmers experience when they are "modifying code" while bug fixing / doing change requests, on code in production. Eclipse, as we all know is a great IDE. Features such as Code Completion, Open Declaration, Type Hierarchy, Package Explorer, Navigator, Finding References etc aids people in fixing things quicker compared to say using something like Textpad.
If you are a newbie java programmer and you are using Eclipse IDE, what areas of the Eclipse IDE do you think were less helpful/ less intuitive? If you are a seasoned programmer, what are the common issues that newbies look up to you to solve for them?
Please ignore issues related to : Domain Expertise (Business Knowledge), Infra( where to test your change etc), performance related (eclipse search being slow,etc), Skill level in a particular language (think of the developer as a noob) ... and think one language - Java
I did a local survey in my small team and here are some:
Newbies using Eclipse to handle code that is written to interfaces where the implementation is supplied at runtime. Doing a 'Open Declaration' will always show you an interface. This could be confusing at times.
Eclipse is not intuitive while developing EJBs. Sure, you know all you have to do to create a new bean is to right click and 'Create Bean', however, once created it shows no contextual help to what the next step should be. For instance, generating stubs.
When Data Source Mapping with entity beans, changing something screws up the entire flow of things and eclpise never complains / hints.
Developing applications that make use of Struts, eclipse doesn't tell you that when you change struts-config.xml, particular web flow would get affected.
At this point, to me, as someone who is interested in collecting opinions for my research, it appears as if Eclipse could use more 'contextual runtime hints'.
I am sure the community would have a lot more to add... Please add more of your negative experiences (just from the code change perspective).
EDIT:
I guess, my question was too lengthy and confusing. I am gonna rephrase it a bit and keep it short:
While "making a code change" (not analogous to code formatting, infra related activities, CVS etc... say something like refactoring), what feature(s) of eclipse IDE did you not like / hate the most? Here are the examples:
When modifying code that has been written to interfaces: 'Open Declaration /F3 on an object instance shows you the interface when the implementation is supplied at runtime'.
When changing apps using EJBs: No contextual help
When changing apps using MVCs(Spring / Struts) : No warnings about change impact.

Missing in Eclipse are:
Software visualization, as for example System Complexity View [Lanza 2003]
And also by Lanza, the Class Blueprint [Ducasse 2005]
Post Scriptum: Software visualization in Eclipse: X-Ray provides System Complexity View of Java projects, http://xray.inf.usi.ch/xray.php (via #anjaguzzi and Paul Lammertsma)
And then collaborative filtering "other developers that edited this method before also edited" [Zimmermann 2005]
And the collection of browsable examples, and autocompletion at the level of these examples. That is, for example if your write
ByteBuffer buf = file.
and hit autocompletion it should search the codebase and the interwebs for examples that convert files to bytebuffers and insert that 10-20 lines there.
Parseweb supports developers by recommending method invocation sequences that yield a required
destination data type from given input parameter types. http://doi.acm.org/10.1145/1453101.1453129
Prospector supports developers by recommending method invocation sequences that yield a required
destination data type from given input parameter types.http://doi.acm.org/10.1145/1064978.1065018
Strathcona provides source code examples and structural con-
text for the code fragment under development. http://lsmr.cpsc.ucalgary.ca/papers/holmes-icse-2005.pdf
Rascal recommends how and when to call the methods of objects from common libraries such as Java Swing, based on an analysis of existing classes. It uses collaborative filtering. http://dx.doi.org/10.1007/s10462-005-9012-8
And of course also the feature that I can write a Unit test and then the IDE searches the interwebs for classes that pass the test. Yes, this can be done!
CodeGenie is an Eclipse plugin that allows you to write unit tests and then uses the Sourcerer source code search engine to find passing classes. http://doi.acm.org/10.1145/1529282.1529384
CodeConjurer which is based on Merobase also offers that feature, see http://dx.doi.org/10.1109/MS.2008.110
This list could go on and on, good starting points for more work are the proceedings of past
Conference on Mining Software Repositories (MSR)
Workshop on Search-driven Software Engineering (SUITE)
Workshop on Recommendation Systems for Software Engineering (RSSE)
which are all under the umbrella of the ICSE conference.

"newbie issues" I've seen myself (I've used Eclipse for a good while, but it keeps "surprising" me occasionally) and helping colleagues just starting to use Eclipse:
It's large and complex enough to be very intimidating to some at first. Seems people consider netbeans easier to use initially. One colleague took refuge with the VI editor for a god while...
Installing plugins can be tricky (finding site URLs, awareness of plugins, why is "install"+"update" under the Help menu???)
Updates are still slow (but much better than before) with Eclipse 3.5/Galileo. It's difficult to understand which plugins to install just by their name sometimes.
Any platform besides Mac - preferences under the Window menu seems illogical?
Understanding how to set the project class path neatly. Setting the right project JDK version.
Lack of or unexpected interaction between ant/maven build tools' classpath and that of eclipse's (ant/maven clean causes Eclipse compiler errors when classpath is shared etc.).
Views and (large number of) perspectives are confusing/overwhelming at first. Which are useful when? How to drag views to the desired location or restoring closed ones?
Some JDK/Eclipse version combinations required too much PermGen space than available by default, took a while to diagnose.

For me, most of the newbie problems in Eclipse come from one of it's strengths, its configurability & plugin structure.
When I need to change a property in Eclipse, I always seem to have to spend a few minutes working out where to change it. Example: changing the Java editor to insert 4 spaces instead of a tab. The search bar in the properties is always welcome :-)
That and the lack of documentation for some of the plugins always makes for fun when I'm setting up a project.
EDIT: You can always show the classes that implement an interface using ctrl-T.
One thing I would add is that when I have a complex project, I tend to use Refresh & Project->Rebuild All *a lot". And I use TortoiseSVN to maniuplate stuff outside of Eclipse, because a lot of times this is easier (some refactoring for instance). However, if I'm modifying the project outside of Eclipse, I *always" quit Eclipse, and do a full refresh and build when I restart it. Otherwise Eclipse gets very confused sometimes.

I think the biggest problem I faced (and still face) with Eclipse is that it isn't particularly aware of standard technologies that surround modern Java development. If I'm developing an application, it might include the following:
Spring
Maven
JSF/Struts 2
Subversion
JUnit
I think Eclipse handles those technologies in increasing levels of awareness: (so JUnit will be fine, it works out of the box; Subversion requires Subclipse, and it's a little ropier than the CVS support; JSF needs some WTP tooling to be installed; Maven...you're probably best off setting up your own external tools commands rather than trust M2Eclipse, unless it's become dramatically better in recent times; and Spring, well, as you say, try ctrl-clicking on a method and you'll almost certainly get an interface, because the implementation is hidden away behind a Spring config file).
Getting all of that to play together and check out/compile, then later compile/run tests/check in is the difficult bit. The code change itself is probably easy :)

For me, the biggest hurdle to learning to use eclipse effectively was understanding where to set the classpath and also how to figure out exactly what is included on the classpath for various stages of development (compile, build, test). I was confused for a long time about the difference between compile time, debug configurations, and run configurations classpaths. Then if you throw ant into the mix (which automatically creates a run configuration ) it makes it even more confusing for newbies.

As a beginner, I didn't do EJB or Struts stuff. Or even data source mapping. So I think the question's title may be a little misleading.
I would have appreciated having something like JadClipse built in to "look at" library code when I hit it in debugging or such. But it should be made VERY clear that this is "reconstituted code" and not meant to be hacked around in.
Second, noobs need to be made much more aware that Shift-F2 will get them the API documentation for whatever class/method they're looking at. I know too many novice Java programmers who explore their APIs with nothing more than code completion; they're missing many valuable hints provided by the library authors.

A mindreader which generates code on the fly, so that a single click is sufficient to complete a project.

I found Visual Studio easy to pick up, I tried clicking on each button at least once, and figured out what the whole thing does. It's thought out by a single design team at the highest level, and everything follows the standards top to bottom, more or less.
Then, I play with Eclipse. In technical terms, it's janky at best. Look at the preferences dialog; it's an overwhelming trainwreck, unless you already know exactly what you're looking for, and what the developer working on that feature decided to call it.
Eclipse's configurability relies on the fact you already know how to configure it. The learning curve there is awful, and the only saving grace is that most of the defaults are okay to begin with.

I was a noob to eclipse recently, mostly doing Android and BlackBerry stuff. And one thing that eludes me to this day is the massive multitude of options and settings and various places they can be found in. For instance, if you have a plugin installed (say BlackBerry plugin), the setting might be found in the general prefs or BlackBerry prefs or the project prefs.
It's always a hunt.

Here are basic missing features as far as I know :
Show the beginning '{' when you are at the end '}' where beginning '{' is out of the view
Automatically synchronize the editor with package explorer
Go to different view (package explorer, outline, etc) with keyboard
Inline find, which does not open a dialog.
Go to next error location with keyboard
Go to next/previous structure with keyboard
More stability in general.
These features work great in IntelliJ. Especially #1 and #5 are really useful.

VCS integration - typically the developer is also new to merging changes, keeping working copies in sync, resolving conflicts and so on. There are often several ways of achieving the same thing in Eclipse and I've seen this cause confusion on several occasions (actually, I've seen this with experienced developers too; they know Subversion but not Eclipse, and the latter tries to 'hide' the underlying repository operations).

I think the issue with all IDEs for beginners is the disconnection from the tool chain: how the compiler takes some source and compiles it to bytecode which I then run using the VM with a correctly configured classpath.
As a dev I love the fact I don't need to deal with this - and I've never found myself unable to do what I want concerning more complex build configurations - but it's too important for beginners to understand what's happening when you press that Play button to be ignored.

when i first tried using eclipse i absolutely hated it's coplexity.. you had to do a whole bunch of things befor you were able to start working. furthermore you have way to many options to check and it's not always selfexplaining what each button does.
instead i started using netbeans. way more intuitive and easier to handle. check there gui.. not to much buttons and most of the time you know what the button does even if you have no clue of java (as i had at that time).
when i changed back to eclipse (due to some features not supported in netbeans) it seemed far easier to work with it. so some part of the gui might just be added in a not intuitive way and beginners will definitly have a hard time with it.

simplicity
clearness
consistency
I might write it much more in detail, but i think, that eclipse is overweight and much too much oriented on features - instead of ease of use. IMO, this concerns beginners as well as professionals.

Eclipse has no visual designer for Swing components.
Compare that to Visual Studio, where:
click 'new form'
drag buttons and text boxes onto the form, move them around, add some labels
double click on a button, add some code
done, one quick application, show it to the boss, get paid/promotion/coffee break
In Eclipse you either have to use Netbeans instead (ie not Eclipse...), or use IBM's SWT, or code the Swing forms by hand.
I feel it would be very nice to have a great wysiwyg forms designer in Eclipse for Swing forms.

The other confusing part is that for web development there is a separate version that needs to be used! Well I didn't like this at all and I know that a lot of people just don't about this.

Eclipse is missing Maven Embedded in standard distribution , Maven would help any user in getting their program all the jars and better library management .
Netbeans already has this tools.
Also eclipse misses integrated tools for hibernate , spring , xfire and tomcat deployment using maven.
Check this site http://maven.apache.org/

All of my other problems with Eclipse have already been mentioned except one: It's slooooooooow. Was their goal to prove the "Java is slow" people right? I'm guessing this is related to the "Eclipse does everything", but I stopped using it because it lags every time I click on anything. Change tabs? Lag. Open preferences? Lag. Change tabs in preferences? Lag. It's like using Photoshop with 32 Mb of memory.
Oh and it's incredibly ugly. I wish I could get it with real GTK+ integration.

The android SDK integration is full of jank. xml layouts don't render correctly. Code completion doesn't work well. IBM needs to fix the jank for sure.

Any good ORM tools for Android development? [closed]

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
Anyone working on the Android ('gPhone') have or know of a place where I can find a good ORM tool for it? The code is written in Java, and the database is SQLite. What I would like to find is a tool that given the object definition, can auto-generate the tables and the CRUD functions (that would be awesome), or, barring that, a tool that can take the table definition, the object definition, and auto-generate the CRUD functionality. The rub is that all of this must happen within the Android framework, which has its own conventions as to how database access works.

Thought I'd just add my $0.02 here about my ORMLite package.
It is a lightweight replacement to Hibernate and uses native Android OS database calls to support SQLite on Android. It also supports many other database types using JDBC on other architectures. We have an Android mailing list for ORMLite questions.

This question cannot age but the suggested frameworks can. So, here is first a list of what I find important in such frameworks for comparison:
Is there a Maven or Gradle artifact? (that's a big plus depending on whether you use maven or gradle, obviously)
Is the code accessible in an easy way including a fast overview on commits to judge the activity? (code hosted on github is a definite plus for me, in that matter)
Release management: are there releases/release tags and artifacts for it? (there are some that are hosted on github and require either git clone or offer the master tarball for download - for me a big minus if not even release tags are set and addressed in the README)
as size matters I put up some hints where it was easy to get by (I did not download anything, so from those projects that offer no release artifacts there are no sizes)
And here is a list of frameworks with notes on the points above. I looked up some more like aBatis and Hadi but I added only those that had some activity after 2011.
http://ormlite.com, Maven artifact, 52 kB, SVN, the website is... difficult but there seem to be a lot of examples, according to http://ormlite.com/changelog.txt the last version is 4.48 from 2013,
https://github.com/j256/ormlite-core (release tags), last activity March 2015
http://greendao-orm.com, good maintenance, Maven artifact, focus: fast performance, small size, little RAM consumption. Github: https://github.com/greenrobot/greenDAO/ (release tags, > 2300 stars), last activity November 2014
https://github.com/roscopeco/ormdroid, small size, last activity August 2014
http://www.activeandroid.com, https://github.com/pardom/ActiveAndroid (> 2300 stars), good maintenance, community, no release tags (download points to master tarball), Maven artifact, last activity October 2014
http://droidparts.org, https://github.com/yanchenko/droidparts (release tags, > 600 stars), also dependency injection, Maven artifact, actively maintained
http://www.androrm.com , https://github.com/androrm/androrm (release tags), last activity Jan 02, 2014 (github)
https://github.com/emilsjolander/sprinkles (release tags, > 600 stars), last activity May 2014, Maven artifact (thanks #AndroidGecko)
http://realm.io, https://github.com/realm/realm-java replaces not only ORM but also SQLite, also for iOS (release tags, > 1600 stars), actively maintained, own Maven repository
I have not tried any of those but maybe I can spare current readers a bit of time by listing the nowadays active projects. Please add a comment if you know of other projects that satisfy some of the above points and have some serious development (over some time) going on.
EDIT (2013 Nov): updated the list to the current status of the projects. Some of these have added release tags to their github repos as well as Maven/Gradle support. Good work!
EDIT (2015 Apr): updated the list, added Sprinkles (as per comment by #AndroidGecko) and Realm.io.

If performance and code size matter, check out greenDAO. I'm the author of it, and my motivation to create another ORM was to avoid reflection in the hotspots. It turned out that greenDAO can be up to 4 times faster than ORMLite. Checkout the feature page for details.

I don't know of anything that is exactly what you are asking for, but there is an alternative to SQLite that you may find useful if your architecture requirements are flexible. It may be worth checking out db4o:
Android db4o
Code comparison examples

ActiveAndroid ($20) looks like it may be exactly what you need.

I liked ActiveAndroid. It's written specifically for Android it seems. That's feels like a plus to me.
I have some Ruby on Rails experience and if you like the Rails way of ActiveRecord you can very quickly get moving with this library.
https://www.activeandroid.com/

https://github.com/ahmetalpbalkan/orman
Orman framework might help you. It is especially designed for that and very small and useful.

I'm also looking for an ORM on Android. I tested ActiveAndroid, NeoDatis and db4o, and I think that I'll use one of the two last.
NeoDatis and db4o are really similar, so I would like some advice to choose the best one. Is someone using one of them on his project ? I'll use it for free and paid app, but it seems that the two haven't any license limitation for Android.
There is a benchmark here that seems to say that NeoDatis is faster than db4o, but I don't know if we can base my opinion on this.

One more newcomer: android-active-record.
It's very lightweight and easy for use persistence framework for Android backed by SQLite
http://code.google.com/p/android-active-record/

ActiveRecordJS from Aptana is a Javascript ORM that should run on the gPhone. It is designed to work with Jaxer and Gears. When you user the Jaxer Adapters, you can connect to SQLLite.
UPDATE: I don't think I made it clear, but ActiveRecordJS is an ORM that runs client side, which could be an advantage to you on the gPhone.

http://hadi.sourceforge.net
This tool is very simple and easy to use.

I have developed my own implementation of the JPA ORM for Android. It is not yet fully feature complete, but you can annotate class with the #Entity, #Id, #Column annotations and you get JPA entities that can be stored and retrieved from the SQLite database. It needs some more features & cleanup before I'll post it to the public, but if there is enough interest it might accelerate my effort.

Even though this is an old post, the topic is still relevant. Hence, I want to share an interesting article and nice approach to solving most of the issues mentioned in the question:
http://blog.codecentric.de/en/2011/04/android-persistence-accelerated-small-inhouse-orm/
Hope anyone finds this as useful as myself!

My own DroidParts /http://droidparts.org/ just reached v0.5. It's a DI/ORM library & more.
Not much documentation, but includes a sample app.

Had negative experience with db4o (v. 8): indexing didn't work properly (exception etc.). So I didn't managed how to avoid creating duplicates in foreign tables when having object in object structure. More detailed explanation in my question. Hope one day it would be better.