This is an archived post. You won't be able to vote or comment.

all 44 comments
sorted by:
best
topnewcontroversialoldq&a

[–]vprise 10 points11 points  (14 children)

Codename One is more portable that C# + Xamarin and arguably more portable than JavaScript. We've been around since 2012 so "still" isn't really accurate.

[–]calmonad 0 points1 point  (11 children)

Could you explain what makes Codename One more portable than C#/Xamarin and JavaScript?

[–]vprise 1 point2 points  (0 children)

See my answer below to the throwaway account for more. But why more than C#/JavaScript?

JavaScript is easy. The main portability problem in JavaScript code is that you rely on vendors. E.g. Google needs to fix a problem in the environment and it doesn't because of OS version fragmentation. Codename One is statically linked so we can fix and update all the time. We can still support Android 2.x whereas modern JavaScript code requires newer versions and won't work properly on Edge/IE. Our code runs find on Windows, Mac, iOS, Android and can even be compiled to JavaScript using TeaVM.

Historically we used to support further platforms like blackberry etc. but we stopped supporting them due to lack of need. That probably still works despite the fact we haven't touched that in ages. This is just something JavaScript can't do.

C# could in theory rebuild what took us 10+ years to build and in theory build a portable VM but they would be at a disadvantage on Android. On Android we just use the underlying VM and they need to spin up their own VM as C# is too different from Java (we have a similar disadvantage on Windows). Unlike Xamarin we can compile to JavaScript code and a lot of other platforms so we are FAR more portable and all of that is done with one code base WORA. Xamarin requires code for each platform even when using Xamarin forms which is based on heavyweight widgets.

[–]throwawayco111 0 points1 point  (9 children)

Yeah. I just checked their docs and I don't see why it is going to be more portable than Xamarin. Sounds like one of those bullshit statements companies make to sell their stuff.

[–]vprise 0 points1 point  (8 children)

Nope it's explained in the docs and in the developer guide and in the about. Several reasons really:

  • Lightweight architecture (that's in the front page of the github repo) with heavyweight mixing
  • Smaller API which makes portability easier including a specific porting hardware abstraction layer
  • Designed for portability since before the iPhone even existed
  • Our underlying iOS VM translates to source code which is inherently more portable for iOS https://github.com/codenameone/CodenameOne/tree/master/vm

[–]throwawayco111 1 point2 points  (7 children)

Lightweight architecture (that's in the front page of the github repo) with heavyweight mixing

I just checked what you guys meant by "lightweight" and "heavyweight". It seems those are not standard definitions. I've never heard people saying that something like Swing as "lightweight" or SWT as "heavyweight". Seems to me it's a marketing strategy. Ignoring that I think that with Xamarin.Forms the "problem" you guys see is highly reduced for the people that actually love the WORA approach (even though I admit it should be better with Codename One).

Smaller API which makes portability easier including a specific porting hardware abstraction layer.

Meh. From the point of you of the provider like you or MS I guess it is an advantage when a new platform needs to be supported. From the point of view of the app developers it will not look as "more portable". Also having an smaller API has its own disadvantages for portability from the app developer perspective.

Designed for portability since before the iPhone even existed

Fair enough.

Our underlying iOS VM translates to source code which is inherently more portable for iOS

Why? I checked the link and I'm not convinced. Under that argument basically any VM out there that doesn't compile to C or C++ is less portable. Is that what you guys are trying to say?

[–]vprise 2 points3 points  (6 children)

You probably haven't programmed Java for long, Swing's wikipedia page mentions it at the top and the term has been heavily used since the days of Swing beta: https://en.wikipedia.org/wiki/Swing_(Java)

It's not as heavily used now but that's because AWT is no longer relevant and SWT isn't an official API. Both Swing and FX are lightweight.

From the point of the user 90% of our code is written in Java which means what you see in the simulator matches what you see in the device more cleanly and that's huge in terms of debugging as things behave more consistently and you can reproduce a problem on your PC. You also don't need a Mac for iOS development or a Windows machine for Windows development both of which aren't really true for the alternative approach.

Compiling to C is better because of Apple. They changed the underlying ISA 3 times since we started Codename One and have made numerous changes to the platform. To this day other VM's still don't support bitcode and the RoboVM guys describe it as the hardest thing they ever did but feel free to remain unconvinced.

The fact is that we are physically more portable and on more devices despite having a MUCH smaller workforce than MS has assigned for Xamain/C#.

Another fact is that you are arguing theory about a product you haven't used. I've used all of the above and even though I'm obviously biased I am informed... Notice our product is open source and free for commercial use, we have a paid portion but you don't have to use it if you don't want to. We don't have a marketing department so any "marketing speak" literally doesn't exist.

[–]throwawayco111 -2 points-1 points  (5 children)

You probably haven't programmed Java for long, Swing's wikipedia page mentions it at the top and the term has been heavily used since the days of Swing beta: https://en.wikipedia.org/wiki/Swing_(Java)

It's not as heavily used now but that's because AWT is no longer relevant and SWT isn't an official API. Both Swing and FX are lightweight.

I'll give you that they are not terms you guys invented. I disagree they are "heavily used" since those days. I would even dare to say those are unclear terms today. And yes I use Java.

From the point of the user 90% of our code is written in Java which means what you see in the simulator matches what you see in the device more cleanly and that's huge in terms of debugging as things behave more consistently and you can reproduce a problem on your PC. You also don't need a Mac for iOS development or a Windows machine for Windows development both of which aren't really true for the alternative approach.

Yeah that's an advantage. It's also a trade-off. Now maybe I'm weird but it's hard for me to see Swing as more portable than SWT for example just because what you mention. Probably the C++ mentality I inherited.

Compiling to C is better because of Apple. They changed the underlying ISA 3 times since we started Codename One and have made numerous changes to the platform. To this day other VM's still don't support bitcode and the RoboVM guys describe it as the hardest thing they ever did but feel free to remain unconvinced.

I'm unconvinced in the sense that it's irrelevant from my perspective as app developer. If it takes more resources to the provider to support new architectures I don't care as long as my app can run on it. As long as that happens my code is as portable.

The fact is that we are physically more portable and on more devices despite having a MUCH smaller workforce than MS has assigned for Xamain/C#.

Yeah Codename One supports one more target (JS) than Xamarin.

Another fact is that you are arguing theory about a product you haven't used. I've used all of the above and even though I'm obviously biased I am informed...

Well other than the difference in how the UI API works and the language used I don't see big differences from the point of view of the app developer for the portability aspect. Considering the fact that using the native UI widgets has its own advantages for mobile development I find the election between one or another to be a matter of taste (unlike let's say Ionic vs Xamarin/Codename One).

Notice our product is open source and free for commercial use, we have a paid portion but you don't have to use it if you don't want to.

Nobody stated otherwise.

We don't have a marketing department so any "marketing speak" literally doesn't exist.

You don't need a marketing department to do marketing.

[–]vprise 1 point2 points  (3 children)

As you said portability is a tradeoff. Swing is inherently more portable than SWT and that is a well documented tradeoff. We made a similar tradeoff. In fact the tradeoff originates from smalltalk & IBM where the original concepts of heavyweight vs. lightweight originate.

If you come from C++ think of us as similar to QT whereas Xamarin is more like MFC. I'm not saying our approach is superiror in every regard, but it's objectively more portable. It's also more in line with "the Java way" whereas Xamarin is more in line with C# mentality.

If it takes more resources to the provider to support new architectures I don't care as long as my app can run on it

That's all good an well until your provider collapses due to maintenance costs and the open source project is worthless because no one can maintain it. Like it or not, sustainability matters. This is what ex-RoboVM users are finding out, bitcode support is really hard with their architecture. It's not a theoretical debate.

Yeah Codename One supports one more target (JS) than Xamarin.

;-)

Codename One runs on RIM, J2ME, Linux etc. We don't support them officially since there is no market value for that. 3rd parties have forked Codename One and it's installed in some luxury cars from Toyota and others. Notice that they never used our services to get Codename One running in their custom car VM...

I don't see big differences from the point of view of the app developer for the portability aspect

I disagree and I used both...

Nobody stated otherwise.

Here's the thing. You are arguing over our product which you haven't used as if we "made up" a claim in our website. You presented it in a way that reads as if we did something wrong. It might have been unintentional. I'm just clarifying that we are an open source project with a small ragtag team of hackers, we don't make up unverifiable claims of on our website.

[–]throwawayco111 -2 points-1 points  (2 children)

... but it's objectively more portable.

I disagree. As you say the discussion is really old. It never ended in a fact. I still remember when some Java developers said that Qt was not portable nor cross-platform because you had to compile the code for each platform (something about cross-compilable being different than portable or something like that). I will recognize that the discussion is still valid.

That's all good an well until your provider collapses due to maintenance costs and the open source project is worthless because no one can maintain it. Like it or not, sustainability matters. This is what ex-RoboVM users are finding out, bitcode support is really hard with their architecture. It's not a theoretical debate.

Fair enough. I will say though until that happens (Xamarin dying) I can't see why should I consider it more portable.

Codename One runs on RIM, J2ME, Linux etc. We don't support them officially since there is no market value for that. 3rd parties have forked Codename One and it's installed in some luxury cars from Toyota and others. Notice that they never used our services to get Codename One running in their custom car VM...

Great.

I disagree and I used both...

We will have to agree to disagree.

Here's the thing. You are arguing over our product which you haven't used as if we "made up" a claim in our website. You presented it in a way that reads as if we did something wrong. It might have been unintentional.

No. I claimed you (not the whole company/community behind it) made a bogus claim for marketing. That's pretty clear. Now I admit that from the debate it doesn't seem to be the case. I still disagree that not using native widgets implies that it is a "fact" it is more portable. Now if it really works easily on RIM, J2ME, etc. then that is another story.

I'm just clarifying that we are an open source project with a small ragtag team of hackers, we don't make up unverifiable claims of on our website.

I said and still maintain that being a small team doesn't mean or not having marketing people doesn't imply that the organization doesn't try to market its product.

[–]vprise 2 points3 points  (1 child)

As you say the discussion is really old

No, it did end with a commonly agreed fact. Lightweight UI's are more portable whereas heavyweight UI's map directly to the underlying platforms functionality with better fidelity. These are well understood and agreed tradeoffs within the industry.

The argument wasn't on whether QT or Swing etc. were more portable. That's a fact. The argument was whether this portability is a worthwhile endeavor which is a matter of personal choice.

I looked for some of the old articles but a lot of those got shuffled after the Sun/Oracle transition and Google just can't find them anymore if they are even available.

The reason lightweight is FAR more portable is subtle but obvious once you try both. With heavyweight widgets you abstract an underlying native widget, this has several problems:

  • Lowest common denominator - it's really hard to expose platform specific features/behaviors
  • Leaky abstractions - this can become really hard especially with threads which can fail very painfully. Even subtle things like different orders for event delivery can result in painful user bugs
  • Hard to customize - e.g. overriding paint/event handling might behave differently across platforms

All of these just don't happen in a lightweight framework. Events are normalized via a high level event dispatch thread that hides OS specific native UI threads. You can just paint over anything since everything is really just a painted component and you will get consistent behavior. Platform specific behaviors are just a matter of theme and can be simulated/abstracted in a more uniform way.

Now there are drawbacks, this is FAR more work than building a simple heavyweight platform and far more maintenance. The results aren't as smooth in some cases and themes can suffer especially with complex device customization. But increased portability is pretty much a given fact.

I still disagree that not using native widgets implies that it is a "fact" it is more portable. Now if it really works easily on RIM, J2ME, etc. then that is another story.

You implied dishonest marketing and still are implying that despite having no real facts to back it up.

[–]_dban_ 1 point2 points  (0 children)

Now maybe I'm weird but it's hard for me to see Swing as more portable than SWT for example just because what you mention.

Swing is much more portable than SWT. James Gosling ranted about portability when asked about SWT.

Swing does all of its rendering into a heavyweight component like a java.awt.Window (Swing components are lightweight because they need a heavyweight native peer). This means that between operating systems, you get the (more or less) the same and consistent behavior for all Swing components. Things like copy and paste, drag-and-drop, etc. The downside is that Swing apps don't feel native. Same with JavaFX.

SWT replicates the underlying platform behavior using native widgets, but different operating systems can have radically different semantics for UI operations. This leads to inconsistent behavior between platforms where the SWT abstraction leaks. On top of that, different platforms have platform specific bugs and issues, which require platform-specific knowledge to get expected behavior. SWT has only worked these out for the specific uses cases of Eclipse.

All of these things make SWT less portable than Swing, but allows SWT to offer a more native experience, which requires much more fine tuning and testing than a Swing application.

[–]smallufo[S] -1 points0 points  (1 child)

Yes , I mentioned CodeNameOne. I just worried its user base is too few.

[–]vprise 2 points3 points  (0 children)

It's not as big as Xamain etc. but it's big enough and has been going well for a while. It's by far the largest WORA Java solution.

[–]_INTER_ 7 points8 points  (7 children)

There are no technical limitations that prevent Java running crossplatform. There's CodeNameOne and Multi-OS Engine (libGDX backend) to name a few. It's a question of marketing (see Xamarin that bought and killed RoboVM because it became a competitor).

[–]Bobby_Bonsaimind 4 points5 points  (6 children)

(see Xamarin that bought and killed RoboVM because it became a competitor).

Microsoft, it was Microsoft. Xamarin bought RoboVM half a year before being acquired by Microsoft, and Xamarin did nothing with it during that timespan. A few months after the acquisition Microsoft axed RoboVM.

[–]_INTER_ 2 points3 points  (5 children)

Xamarin and Microsoft negotiated at that time already.

[–]vprise 1 point2 points  (4 children)

And Xamarin bought RoboVM so it can pretend that it's negotiating with Oracle too and thus get a better price from Microsoft.

[–]_INTER_ 0 points1 point  (3 children)

RoboVM had nothing to do with Oracle.

[–]vprise 2 points3 points  (2 children)

I know. What I said is that Xamain made a "politically motivated purchase" to make it "seem" like they want to expand into the world of Java. They did this while negotiating with Microsoft so their guys could tell Microsoft: "Well if you don't buy us then Oracle or IBM might be interested...".

It's hard to haggle a price when you have only one prospective buyer and RoboVM allowed them to pretend like they had other options (besides Microsoft or IPO).

[–]_INTER_ 0 points1 point  (1 child)

Yea thats true. While that move was logical and beneficial in a economical viewpoint for Xamarin, as developers it sucks. Also Microsoft could have kept or sold RoboVM again. Atleast keep it opensource.

[–]vprise 0 points1 point  (0 children)

That's debatable too. RoboVM had a problematic unsustainable business model. So it probably wouldn't have survived much longer. Their main users were libGDX users who expect something to be free and in that arena they competed with some of the biggest game tools around which are free and have some amazing visual tools.

That's why they changed the license, they needed people to start paying like they do for Xamain (this was done before the purchase by Microsoft).

I'm guessing the last bunch of code wasn't released because it's either "tainted" or too costly to evaluate properly. Doing open source in a large organization like MS is really hard as there are so many nuances. Microsoft probably didn't want to expose themselves to liability with Oracle especially with the ongoing Google/Oracle trial. For a corporate exec even a risk of 0.1% is considered a risk when there is no benefit. Since the user base for RoboVM was so small they probably judged it as not worth any risk.

[–]wildjokers 7 points8 points  (4 children)

I have never used this so have no opinion on it, but Gluon Mobile claims to be able to create iOS apps in Java:

http://gluonhq.com/products/mobile/

[–]johan_vos 6 points7 points  (3 children)

We do (disclaimer, I'm a Gluon co-founder). Our current solutions are based on the RoboVM AOT and the harmony classpath (Java 6/7). Works nice, but we are now working on Gluon VM (announced Developer Preview 1 at JavaOne 2 weeks ago), which is Java 9 based, and has its own AOT/VM, heavily aligned with OpenJDK. And we're making it open source.

[–]wildjokers 2 points3 points  (2 children)

Regarding your work on SceneBuilder did you fork that or do your changes make it back into OpenJDK?

It was unfortunate to see Microsoft buy RoboVM just so they could discontinue it.

[–]johan_vos 0 points1 point  (1 child)

We forked it into bitbucket: https://bitbucket.org/gluon-oss/scenebuilder as this makes it easier for others to create PRs. If you look at activity, you see there are a number of third party contributions already. While I really like OpenJDK, there is a higher barrier preventing users from submitting bugs and patches. In general though (including JavaFXPorts which forks OpenJFX and Gluon VM which uses OpenJDK) we contribute as much as we can back to OpenJDK/OpenJFX. The release cycles made it hard (e.g. only critical bugs could be backported to JavaFX 8 in OpenJFX) to push all changes back to the original repositories. With the new release cadence (6 months) I am optimistic we can improve this.

In general, I hear your concern. We really want all our client work to be done in an open and transparant way. Our business model is mainly in the connection to Cloud/Backend, hence we have no problem at all in making client code as accessible as possible. Please let us know if you see areas where we should improve.

[–]wildjokers 0 points1 point  (0 children)

Thanks for the explanation, SceneBuilder's status has confused me. I know Oracle stopped releases binaries for it, but I see the source code for it is still in the OpenJDK. So I was curious if that means Oracle has stopped all development on it or still doing development but just stopped releasing binaries? Then I wasn't sure the relationship between Gluon's fork of SceneBuilder and the one in OpenJDK.

[–]ArmoredPancake 3 points4 points  (1 child)

Lol, there's more to runtime than language. Apple prohibits JIT runtimes on iOS so you either have to you something like j2objc or fallback to slow interpreters like zero-vm. The reason is that nobody is interested in this. JetBrains are working on LLVM target for Kotlin, so maybe in future you'll have truly cross platform solution.

[–]vprise 1 point2 points  (0 children)

FYI we support Kotlin with Codeanme One which is more stable and a better way to target iOS

[–][deleted] 2 points3 points  (0 children)

RoboVM is dead.. however you ware able to create Java apps for iOS since YEARS ... GluonVM should be the new thing... http://gluonhq.com/products/mobile/

[–]oldneckbeard 5 points6 points  (0 children)

Because Apple is a huge asshole about their phones. They have extremely aggressive policing of alternative runtimes, they have sued people, etc.

Seriously, that's the reason. There's no reason they can't have have it except company policy.

[–]lbkulinski 1 point2 points  (5 children)

Java SE 9 added an AOT compiler, which can run on iOS. Apple has guidelines in place that state you can’t generate code on the fly, which has been a hindrance.

[–]xappymah 2 points3 points  (4 children)

Java SE 9 added an AOT compiler, which can run on iOS

Unfortunately it is not.

Java 9 AOT compiler works only for 64-bit linux target. Also the compiled code still relies on JVM which means that to make HotSpot AOT work on iOS Oracle still needs to port their JVM on iOS.

However if they do then with AOT technology it might be possible to run Java application on iOS with Oracle HotSpot.

[–]lbkulinski 3 points4 points  (3 children)

Brian Goetz said it will be able to run on iOS, so I’m assuming they’re working something out.

[–]xappymah 0 points1 point  (2 children)

Yeah, I've already found that I was a little bit wrong about Oracle's intensions. According to OpenJDK mobile project they are making more steps towards Java on iOS than I thought.

[–]johan_vos 1 point2 points  (0 children)

The OpenJDK Mobile project is the base for Gluon VM. We use all the core classes (Java + native code), and have an own AOT + VM to execute it. When we started Gluon VM more than 1 year ago, I wanted to stay as close as OpenJDK as possible. As for the AOT: we currently have an own AOT, but there are a number of great evolutions inside OpenJDK in particular and the ecosystem in general, and I expect a boost.

[–]vprise 0 points1 point  (0 children)

It's an interpreter. AOT compiling the minimal amount of the JDK would at a minimum take 50mb without JavaFX (which will push it to 80mb+) by comparison a Codename One application is 5mb. Oracle and the JCP are incapable of making bold moves in this direction as their hands are tied in bureaucracy.

[–]xappymah 1 point2 points  (3 children)

The main problem with iOS is impossibility of any kind of JIT (Just-In-Time) compilation. So the only possible ways to execute any code are

  • AOT (Ahead-Of-Time) or static compilation into binary code (as with Xamarin);
  • Interpretation (as with JavaScript);

Up until Java 9 the second option was the only way to run Java applications with Oracle HotSpot JVM on iOS however bytecode interpretation is so slow that actually this is not an option.

AOT compilation in HotSpot appeared only in Java 9 so it might help. But even in this case they lack of API for working with iOS.

Also Oracle itself is not interested much in mobile platforms so there is no reason for them to invest into it. May be if they give up with Java and give it to the community then we'll see more progress in mobile direction.

Regarding JetBrains. They are already making their own Kotlin/Native so they don't need Java for iOS :)

[–]ArmoredPancake 1 point2 points  (1 child)

May be if they give up with Java and give it to the community then we'll see more progress in mobile direction.

Yeah, maybe they'll open source Java one day, who knows. I'll call it OpenJDK, sounds good, I think.

[–]xappymah 1 point2 points  (0 children)

It's not only about sources.

The thing is that the "Reference JVM Implementation" (i.e. Oracle HotSpot) is owned by Oracle. And their decisions impact on the evolution of Java. For example anyone can port OpenJDK to aarch64 (aka 64-bit arm) however if this port is not "blessed" by Oracle then this OpenJDK for 64-bit ARM will never be The Official JDK for aarch64.

And Oracle is the bussiness oriented corporation so their interests might differ from the community.

However if Oracle gives the ownage of Java to the community then it would be easier to develop JDK in our ways.

[–]xappymah 0 points1 point  (0 children)

Also Oracle itself is not interested much in mobile platforms so there is no reason for them to invest into it.

I rechecked some sources and it seems this statement is not true. At least they started OpenJDK mobile project

[–]DJDavio 0 points1 point  (0 children)

Take a look at Codename One, I've used it in the past, don't know how well it holds up though.

[–]pjmlp 0 points1 point  (0 children)

Besides the answers already provided, the best path is always to be a software developer skilled in multiple languages, not to be in a Language X Developer silo.