Sure and I don't argue that. But it also wasn't fully there. This past couple of weeks Codename One introduced some big missing pieces:
* Level builder/game designer
* Proper 3d that works natively everywhere (direct 3d on windows, metal on iOS/Mac)
* Support for native win32, Linux and mac - real native with no JVM, 5mb binary
* Native performance for some edge cases (low level SIMD API etc.)
You're right that mindshare is a huge part, but there were also many important missing pieces especially on the deployment front. I think that with good tooling and a royalty free pitch this might open some doors that were previously closed to Java.
Getting to major studios would be an uphill battle but since they acquire indie studios the path goes through there.
They give us Dell Linux machines from work. They suck so bad and we have so many problems. Overheating, camera is terrible, performance is bad relatively to the huge weight of the device. Everything is a huge step down from Macs.
Whenever I see Linux people comparing Linux and Mac I'm amazed at the audacity. They are not in the same league. Not by a mile. Even the CLI is more convenient on the Mac which is truly amazing to me.
As a maintainer of a medium size OSS project I agree. We've been running the produce for over a decade and a few years back Google came out with a competitor that pretty much sucked the air out of our field. It didn't matter that our product was better, we didn't have the resources to compete with a google hobby project.
As a result our work on the project got reduced to maintenance until coding agents got better. Over the past year I've rewritten a spectacular amount of the code using AI agents. More importantly, I was able to construct enterprise level testing which was a herculean task I just couldn't take up on my own.
The way I see it, AI brought back my OSS project that was heading to purgatory.
EDIT: Also about OPs post. It's really f*ing bug bounties that are the problem. These things are horrible and should die in fire...
Predicting the future is futile, but I would guess this would be exactly the opposite. LLMs make it remarkably easy to generate a lot of code so they can easily generate a lot of Rust code that looks good. It probably wouldn't be, and for us it would be unreadable when something goes wrong. We would end up in LLM debugging hell.
The solution is to use a higher level safer, strict language (e.g. Java) that would be easy for us to debug and deeply familiar to all LLMs. Yes, we will generate more code, but if you spend the LLM time focusing on nitpicking performance rather than productivity you would end up in the same problem you have with humans. LLMs also have capacity limits and the engineers that operate them have capacity limits, neither one is going away.
Well... 64kb isn't exactly enormous for the type of functionality it offered. It did support copy and paste you just had to enter editing mode. The underlying APIs didn't offer access to copy and paste directly.
Having said that, it doesn't really matter if you didn't like it. It was a pretty big part of the J2ME ecosystem at the time and it's a huge omission.
3) They released a binary and included the GPL license as part of the binary release licenses thus committing to the GPL in that release while not making the code available.
The core concept hasn't changed. We have a lot more data about what works and what doesn't. Back in 2002 funding for development tool companies and open source companies was non-existent. Git or github didn't exist. Things changed.
Selling consulting is hard... You need a whole sales org and if not, a salesperson personality. This often clashes with the hacker mentality and requires different disciplines. I would say this doesn't sell "easily" like a SaaS would.
RoboVM tried to close the source but they made a release of a version that still had the GPL license attached to it. They didn't commit those sources to the public git.
They had to release those sources after the fact because they didn't change the license in the general release.
Despite all the hype. Very few people use Crypto. It doesn't matter if it's "just" 0.1% what matters is how much do all the banking and credit card systems in the world consume by comparison. I would bet it's less than that.
So it's not tenable as a currency.
It's also not very valuable as a commodity since it fluctuates too much and has no intrinsic value.
It has no value to "disconnect from the banks/government" since you need to convert it to "real currency" for usage.
There's the claim that green is possible with Crypto but I don't see how. Without turning it into a centralized system. The wastefulness is the system designed to discourage bad actors from taking over. Without it, what will stop the hacks? (not that it helps with all the robberies anyway).
* Level builder/game designer * Proper 3d that works natively everywhere (direct 3d on windows, metal on iOS/Mac) * Support for native win32, Linux and mac - real native with no JVM, 5mb binary * Native performance for some edge cases (low level SIMD API etc.)
You're right that mindshare is a huge part, but there were also many important missing pieces especially on the deployment front. I think that with good tooling and a royalty free pitch this might open some doors that were previously closed to Java.
Getting to major studios would be an uphill battle but since they acquire indie studios the path goes through there.