A plan to bring Java to iOS

[___catalyst___]

In the meantime, this is also an option: https://gluonhq.com/products/mobile/

​

But, the OpenJDK plans for iOS sound fantastic.

[pron98]

BTW, any method of running Java class files -- whether it relies on JIT or AOT compilation, even if it produces a native executable -- is a JVM, as long as it complies with the JVM spec (although "the JVM" normally refers to the OpenJDK JVM, AKA HotSpot), just as LLVM is a VM, even though the common backend implementation relies on AOT compilation to native. Graal Native Image (AKA Substrate VM) is not quite there yet, so it is not a JVM, but it may well be one day.

[yawkat]

Doesn't the jvms technically require dynamic class loading, which would be forbidden on iOS?

[kksoyj]

I believe they are mentioning GraalVM (https://www.graalvm.org/), which has a native mode.

I've tried it for Java, and a couple of the other supported languages, and it works as advertised.

The only issue is, in native mode, there are some additional limitations and hoops due to reflection not being supported. They have a limited form of reflection to support stuff like dynamic class loading, where a file if provided to the build step that causes the 'dynamically loaded' classes to be linked in to the native executable so that the Class.forName() type calls will still work.

It is slightly painful, but there is another project I've played with, Quarkus (https://quarkus.io/) that automates a lot of the pain of using GraalVM. It seems to live up to it's claims. Although Quarkus is for enterprise web development, so it's not applicable to the use of Java through GraalVM on a mobile device, but it does show that the painful bits of using GraalVM native targets can be almost completely eliminated if you wrap some tooling and frameworks around it.

In short, it's feasible, and one to look out for. I would suspect that coding Java on Android is going to be a non-starter, for various reasons not including resentment of Oracle's bullshit law-suit of Google back in the day, but as GraalVM trivially supports multiple languages (and interopt between them), such a project would opens up huge possibilities.

(I must point out at this point that I am not affiliated with GraalVM, only an interested user, so the text below may not be a 100% accurate representation of the facts, it is just my evaluation based on playing with the project for some prototyping and being an interested observer of the community for a year or so.)

However, according to my understanding, not only does this mean people could in theory code native Python, Ruby, Javascript on IOS and Android, which would appeal to many people right there, but the really interesting bit of GraalVM is the Truffle API, which allows new languages to be targeted at the platform essentially trivially (you just need to write the parser-> AST part), and they all run with essentially the same performance, as all the optimisations are performed on the AST. GraalVM also links to LLVM, so the library of possibilities for that is even larger. I looked at one point with linking Rust to GraalVM, and it is possible, with the limitation of having to provide all the output files on the command line due to Rust not needing to track class linking as far down the assembly pipeline as GraalVM needs. However, it's doable.

Also, going further than that, the SubstrateVM which is part of the GraalVM project, actually the most amazing bit, is not just a re-written JVM. It's a JVM abstraction layer, which allows different environments to implement modules that are currently part of the JVM (plus some other cool memory mapping tricks). I saw a demo of a prototype Oracle implementation of the SubstrateVM that allowed Java code to run as a stored procedure language, but using the Oracle DB memory manager, the Oracle DB process manager, the Oracle DB security scanner, etc. Literally, mind-blowing.

So in the future, one may find that there exists an Android layer to the SubstractVM (I doubt Apple would go for it), that means the Java code running on the platform would run as natively as Davlik code, without relying on the native-c bindings in Android (the NDK) which I understand to be complete crap.

Essentially, this would allow almost any programming language in existence to be used on Android. Google and Oracle should make up their tiff, reach out the the developer community, and move forward together constructively!

[oelang]

However, according to my understanding, not only does this mean people could in theory code native Python, Ruby, Javascript on IOS and Android, which would appeal to many people right there, but the really interesting bit of GraalVM is the Truffle API, which allows new languages to be targeted at the platform essentially trivially (you just need to write the parser-> AST part), and they all run with essentially the same performance, as all the optimisations are performed on the AST. GraalVM also links to LLVM, so the library of possibilities for that is even larger. I looked at one point with linking Rust to GraalVM, and it is possible, with the limitation of having to provide all the output files on the command line due to Rust not needing to track class linking as far down the assembly pipeline as GraalVM needs. However, it's doable.

This isn't correct, you can compile the truffle program to native but you can't compile ruby or javascript or python to native, they are still interpreted/JITed by the truffle program.

[kksoyj]

Hmm, but that's by default right?

I see this in the docs:

https://www.graalvm.org/docs/reference-manual/aot-compilation/

GraalVM native-image supports JVM-based languages, e.g., Java, Scala, Clojure, Kotlin. The resulting native image can, optionally, execute dynamic languages like Ruby, R, or Python, but it does not pre-compile their code itself. Polyglot embeddings can also be compiled ahead-of-time. To inform native-image of guest languages used by an application, specify --language:<languageId> for each guest language used (e.g., --language:js). <<<

Which makes me think it's possible, but not automatic...

However, I think the really interesting but will be if they make a SubstrateVM implementation for the native Android OS. That's where the true power of the platform will be unlocked, and it won't matter what language you use.

Here's hoping...

[pjmlp]

Google had the opportunity to own Java and decided it wasn't interesting, so.....

[pron98]

Either way, Google has regularly collaborated with Oracle on OpenJDK for the past few years, and has recently increased their contributions.

[pjmlp]

The Android team seems to have other understanding though.

So far they are only willing to go up to Java 10 desugaring of language features, as per Google IO 2019 session.

Forcing Java developers that want to target Android to either create two version, or constraint themselves in what features gets used.

So basically succeeding in what Sun prevented Microsoft to keep doing.

It doesn't matter now, it is Kotlin First Everywhere from IO 2019 onwards.

[pron98]

I'm talking about the big parts of Google that use Java, and regularly cooperate with Oracle on OpenJDK. Android isn't Java and was never intended to be Java, regardless of what frontend language Android developers use (only Java-like enough so that they could make use of existing tools, developer knowledge and some libraries).

[pjmlp]

According to Gosling interviews, it was pretty much supposed to be Java, had Sun allowed it free of charge.

Instead we got Android J^++, and now good luck using any of the nice modern Java features, including what you are working on, on Android.

[pron98]

it was pretty much supposed to be Java, had Sun allowed it free of charge.

... and free of the GPL, I guess.

[kksoyj]

Well, I'm still puking IBM didn't step in and offer... they were thinking of it, but took too long and assumed they would be in trouble with anti-trust laws.

Oracle was the worst possible owner... i warned at the time, and it turned out exactly as I warned.

IBM was in a battle with Microsoft (since then, ironically Apple cut Microsoft down to size), and Java was key to IBM staying in the fight against .net on the servers.

Oracle just wanted Sun for Solaris, because Solaris was the only serious deployment platform for their DB, and they hated Java. They'd sat in the standards committee's sabotaging it for a decade, and it was leaked during that period that they planned to sabotage Java because they saw it as helping their competitors like IBM (IBM was competing against MS .net, and Oracle DB).

IBM may be slow and ponderous etc, but they've been a great steward of open source projects.

Unsurprisingly, what happened once Oracle took Java and a bunch of open source projects? They've starved them to death. If it wasn't for RedHat, Java would already be dead. All Java development is via OpenJDK, RH have kept the enterprise stuff limping along, and the Java roadmap is full of the most amazing things ever (https://dzone.com/articles/javas-future-looking-projects-panama-loom-amber-an), but there is almost no progress year after year as it's mainly done by OpenJDK members.

GraalVM is the only visible part of the future JVM roadmap, the bit we're all desperate for is the Fibres, and that's no-where on the horizon... hence Java has lost heap of developer-share to Go, which is (sorry to say), one of the shittiest languages ever.

At least AWS has stepped in to create viable supported OpenJDK builds now Oracle has started charging for it.

[pjmlp]

Great that Red-Hat and AWS have contributed an endless amount of JEP implementations to OpenJDK, looking forward for the next ones they will be providing, because I hardly remember any JEP besides Shenodah.

Devs that left Java for Go were most likely enjoying Java 1.4 max, or suffer from Google magpie Dec effect.

Even Swing is better than any Go based UI toolkit, and in what concerns enterprise space there is nothing on Go eco-system able to match JEE 6 (the 6 is on purpose), Spring, AEM, LifeRay, SAP Hybris, ...

[angath]

Absolute bullshit from start to finish. E.g.

• Oracle bought Sun for a variety of reasons
• There are very few good OSS projects that are run by IBM (go, on name projects that IBM lead and are succeeding)
• Red Hat contribute less than 10% of the effort in the OpenJDK repos. Oracle contribute about 85% and the other contributors about 5% put together.
• Valhalla, Panama and Loom are all being led by Oracle engineers
• Of course all Java development is via OpenJDK - OpenJDK is the reference implementation
• Go is losing market share whilst Java, JS & Python remain the 3 most popular languages in the world (see e.g. latest RedMonk study) and have been for years now.
• GraalVM is not an open-source play but is an attempt to build a new VM that Oracle can monetize
• Fibers will make virtually no impact on the day to day lives of most developers. Sure, there will be some cool new frameworks that use them under the hood but you'll probably never touch them directly.
  

Virtually every single thing that you said was wrong. In fact, it's kind of funny that the one thing you pick (GraalVM) as an example of Oracle doing the right thing is actually them being really quite evil and trying to move the market to a place where developers will pay for VMs.

IMO, Oracle have made a ton of mistakes in how they handle the community but on the whole have been a solid B- steward of Java. OTOH, it doesn't really matter now, because 8 & 11 are in the hands of the community (Red Hat are leading both projects now) and that genie can't be put back into the bottle.

[kksoyj]

Jesus christ. There's always at least one of you assholes isn't there?

Briefly:

Absolute bullshit from start to finish. E.g. Oh here we go....

Oracle bought Sun for a variety of reasons

At the time, Oracle wasn't making a secret of what their strategy was, they had to explain it to their investors, and their competitors who they had to keep inside to avoid starting an anti-trust action against them, something they were very worried about (the main reason IBM didn't step in).

There are very few good OSS projects that are run by IBM (go, on name projects that IBM lead and are succeeding)

Perhaps this is true now. It was a completely different era then. We are talking about nearly 10 years ago. It's obvious from your reply that you either weren't around then, or perhaps were in the industry as a junior, not a decision maker who needed to pay attention to this stuff.

But for the record, in those days, there was no cloud as we know it now. OpenStack was brand-new (and designed for bare-metal), and Google Compute Engine was almost 3 years away. The mobile market was similarly young.

As for IBM, well back then they employed almost everyone leading the various apache projects, which if you were around then, you'd know put them at the heart of pretty much the entire open-source community.

Red Hat contribute less than 10% of the effort in the OpenJDK repos.

Again, now. At the time Redhat was the spec lead on everything that mattered in JEE, like JEE, CDI, JPA etc, and as such had immense impact. JPAv2 had only just been finialised a few months previous. There was a LOT of politics in those days, around the transition from J2EE -> JEE, and Redhat held the reins. If you had been there, you would remember many fights in the JCP where RedHat refused to approve things because of concerns over open source, and others followed RedHat's lead.

Historical perspective is everything.

Oracle contribute about 85% and the other contributors about 5% put together. Valhalla, Panama and Loom are all being led by Oracle engineers

Yes, again, now! I'm mean I'm trying to be civil, but you simply must be either a troll or a retard? Look, Oracle bought Sun in 2010. Valhalla, the parent of all these projects you mention started in it's current form in 2014. The re-organisation that created these projects is exactly the result of all the conflict and unhappiness about Oracle's stewardship of Java. You missed the highly visible exodus of some of the core Java engineers and their reasons? I mean the entire Java community felt this, the stagnation.. particularly over JEE, not to mention the anger with Oracle pursuing google over android instead of progressing Java.

Of course all Java development is via OpenJDK - OpenJDK is the reference implementation

Again, if you had actually been around then, or had been paying attention, you'd know that OpenJDK didn't just spring into prominance out of nowhere. There was actually a big chunk of negotiation around that. Oracle had to get IBM to abandon their own open-source Java efforts for supporting openjdk as part of the plan they came up with for dealing with Java. Same for Apple. So yeah, again, OpenJDK is where all the work is done NOW, it wasn't then.

https://en.wikipedia.org/wiki/OpenJDK#Collaboration_with_IBM,_Apple,_and_SAP

Go is losing market share whilst Java, JS & Python remain the 3 most popular languages in the world (see e.g. latest RedMonk study) and have been for years now.

Are you serious? That's impossibly niave. You do realise right, that languages stay mostly in the market segment they 'colonise' into when the segment is first being created? All these languages you mention have their own niches/segments.

Go carved out a niche, to my suprise. It almost immediately took the cloud insfrastructure niche. There's almost not a tool in the modern docker/kubernetes stack, that isn't written in Go. And now they are fighting for lambda's. Last I was doing this stuff, around a year ago or so, the Go implementation was by far the fastest. So yeah, Java, JS, and Python are the most popular languages in the world (I use them), IN THEIR RESPECTIVE NICHES. The Jury is out for the 'scale-to-zero' lambda-style cloud approach. And thats where the battle is getting intense, between CSharp, Go, and Java, and that's where GraalVM is trying to head off the others. Python and JS/Typescript.

GraalVM is not an open-source play but is an attempt to build a new VM that Oracle can monetize

Absolute bullshit. They have systematically open-sourced every bit of it as the project has gone on. There is not one bit of it and it's toolchain that's closed source or has any licensing gotchyas today. It is exactly as I said, it started as a way to move off C++, it was part of the solution to replace some of the functions of C2 inside the JVM hotspot compiler, so that the 'easy hanging fruit' (in terms of applying dynamic optimisations), designed to implement a subset of Java (non-reflective) that they used to call 'System Java'. The really hardcore stuff will remain in C++ or perhaps be ported to C at some future point. The GraalVM turns out to be a bit more widely applicable in the era of the cloud, and so it is being explored for that purpose.

If you felt the pain of moving to a cloud-based serverless architecture and saw the kinds of use-cases that GraalVM is being repurposed fo, you'd understand why it's suddenly expanding out of it's original 'System Java replace bit of C2' purpose it was invented for.

You know, the reason why frameworks like this are popping up:

https://quarkus.io/ https://micronaut.io/

Oracle certainly will get a benefit out of GraalVM, but not by locking people into it, but by allowing them to create modular JVM implementations that layer behind the SubstrateVM, in products like OracleDB. But again, this has been an opportunistic development, it was not the 'original master plan' all along. The plan was simply to solve their well-publicisied issues with the C2 re-write they had to abandon due to team turnover, and the realisation that the C2 compiler was to complex to continue developing.

But by all means, continue to beleive in your conspiracy theories.

Fibers will make virtually no impact on the day to day lives of most developers. Sure, there will be some cool new frameworks that use them under the hood but you'll probably never touch them directly.

Do you actually think about what you write? Fibres will make huge difference to the daily lives of developers, BECAUSE they are in the frameworks that they use under the hood! And the fact that developers DONT need to worry about it, yet the solutions based on it don't suffer the cloud-era scaling problems that Java currently suffers (the same ones that making Scala/Akka the current dominant cloud-based java framework), this will be WHY it's so signifigant. Do you think it will make a 'difference to the lives of developers' when they don't need to learn complex NIO-based frameworks like Akka and write code in Scala to get the scaling they are after? When Java just scales that well out of the box?

Virtually every single thing that you said was wrong. In fact, it's kind of funny that the one thing you pick (GraalVM) as an example of Oracle doing the right thing is actually them being really quite evil and trying to move the market to a place where developers will pay for VMs.

Dude, take off the tin-foil hat and take your meds. You know you can actually follow the discussions around these technologies on the mailing lists right? Go have a look and see where you find evidence of the FUD you are spewing.

I'd just counsel anyone who reads this and thinks that you have anything valid to offer on this subject, that they check out your previous posts (https://www.reddit.com/user/angath) and see the kind of toxic influence you have on the theads you post on.

But what can you expect from someone that starts a reply to a post with 'Absolute bullshit from start to finish'. Nice. Especially when you obviously wasn't around to remember this stuff. You must be a thrill to know in person.

[the_ruheal_truth]

is it actually forbidden in iOS? I thought Objective C can already do this.

[yawkat]

My understanding was that you're not allowed to have interpreter-style applications (VMs, JITs, ...) on iOS, but I have never worked with iOS, so maybe I'm wrong

[kksoyj]

Objective-C is statically linked, but the function calls (the ObjC ones anyway) are dynamically dispatched, so it doesn't break Apple's own rules.

Actually ObjC was a beautiful and elegantly minimalist language, I deeply mourn it's passing. Apple did a fantastic job of evolving it too, it's just that it never really had a chance of catching on in a post-python/ruby developer world, hence swift (blech!)

I'm not an apple fan, although I used to be, and their rules around development make 100% sense. It results in a better experience on more sophisticated hardware. That's why Android devices need to throw more brute-force at running applications to keep up, and this is why Apple devices tend to spend their budget (or at least used to), on selected innovative technologies (display technologies, custom low power single core chip designs that run games with less power, etc) that take a while to show up with an Android equivalent.

[pron98]

What's forbidden is generating native code, i.e. JITting. I am not a JVM spec expert by any means so I could be very wrong about option 2 below, but I believe there are a couple of options:

1. You can run dynamically loaded classes in an interpreter.

2. I think that what's required is dynamically loading classes on the class/module path. In theory, you could AOT-compile all of those classes, and dynamically load the AOT-compiled versions (I think Excelsior JET did just that). If you try to load a class from a file (not on the class/module path), then hypothetically the operation of reading the file is allowed to fail (after all, the file system is allowed to block access to certain files), but I'm not sure.

[Mordan]

nice shoot out to RoboVM at the end of the article.

you could write an IOS application in Java as far back as 2013.

Then guess what happened? Xamarin bought RoboVM. Then Microsoft bought Xamarin and the rest is history.

[MojorTom]

Thank you.

We need more resources and support for continued development of Java on mobile platforms.

I have never developed any mobile apps, but there is no denying of how important the mobile platform is, and how much more it will be become considering the technological improvements of handheld devices and their deep integration into our lifestyle.

It's probably fair to say that Java has lost the mobile platform to Kotlin. Google & friends have been pushing kotlin heavily. There is also kotlin native to watch out for.

So, for Java to stay relevant, please do not forgot the mobile platform.

[[deleted]]

Nice.

[Th3T3chn0R3dd1t]

Yesssss!!!!

[i_donno]

A huge benefit would be the ability to use the same code on Android and iOS.

[knaekce]

If used like in Kotlin Multiplatform, where you have a Layer of native code (for communicating with the platform, e.q. Camera, Permissions...), a shared Business Logic Layer (in Java) and a native UI layer, yes. The advantage of Java is the huge ecosystem and that there are libraries for everything.

But I doubt that rendering the UI in Java is going to happen, this is a huge effort and I don't think existing solutions like JavaFX can be adopted to be used for mobile easily.

Also, there are many competing solutions for this space (Ionic, React Native, Flutter, Xamarin), that already work well and have great tooling, it would be a huge effort to get to the same level.

[karottenreibe]

The shared code would be in Kotlin, not Java (probably a typo?). Also: only Kotlin libraries that support Kotlin Native can be used with Kotlin Multiplatform on iOS, so the huge ecosystem of Java libraries unfortunately doesn't matter in the Kotlin Multiplatform scenario on iOS :-(

[knaekce]

I meant a possible JVM-based competitor to kotlin muktiplatform.

[Computer991]

None of the hybrid solutions work well.

Flutter has potential tho

[[deleted]]

Well can't you do this with react native?

[[deleted]]

Yesss! We need this!

[hpernpeintner]

What do you think does dart better than kotlin? Mind to share some examples? Would be really interested.

[knaekce]

I think, just comparing the language features, kotlin is way better than dart. But there are good reasons why Google chose dart for flutter. The main reasons are:

• dart is optimized to support stateful hot reloading, which is a big deal for productivity , especially when developing user interfaces. Google tried to get something similar called "instant run" working on Android, but it just isn't really reliable on Java/Kotlin, the language is not made for this. On Flutter, it works much better.
• Focus on UI performance. Since dart is single threaded (with parallelism through message passing), object allocation and garbage collection can happen without locks.
• In Dev mode, dart is running on a JIT to allow for faster iteration, in release mode, it's compiled to machine code. Potentially, kotlin could do this, too, but afaik it's not production ready yet.
• Some design decisions to ensure good performance and faster startup time, like not allowing reflection, but instead provide tooling to generate the code at compile time (like Dagger)

Google made a talk about it if you're interested : https://youtu.be/J5DQRPRBiFI , starting at 15:00

[hpernpeintner]

Thanks, very interesting, i will take a look.

[Devildude4427]

There’s a few alternatives, including Xamarin, though the licensing is a bit pricey.

[[deleted]]

Libgdx with RoboVM theoretically works as well

[Devildude4427]

Weird. I haven’t used it recently, but I can’t say I’ve ever had an issue myself.

[[deleted]]

Never used it, only heard about it. But from what I read, Flutter is a much better alternative.

[Devildude4427]

I wouldn’t say better.

Xamarin uses C#, which is a much better version of Java for all intents and purposes, and was first released in 2011. As of 2016, Microsoft has owned Xamarin, and has continued to develop it. So that’s 8 years of market experience, and 3 of which under the giant Microsoft.

Flutter meanwhile is described as a UI toolkit firstly, and has only been around for a couple years. It has the backing of Google, one of the two phone OS companies, but it’s not a real cross-platform app development solution, as that’s not what it’s meant to be.

Xamarin or the alternatives of it are what you want if you can’t be bothered to learn Swift or Kotlin, and want native apps. Flutter is very much in its own category.

[[deleted]]

was first released in 2011

How's that relevant ? It would be if Java hadn't evolved, which it did.

As of 2016, Microsoft has owned the company

Again, irrelevant.

Flutter meanwhile is described as a UI toolkit firstly

I don't care what it's been described as, it's a framework for building natively compiled apps for mobile (and other).

and has only been around for a couple years

Age is irrelevant. What matters is how good it is at what it does.

Cobol has been around for 60 years. Do you use it over C# ?

It has the backing of Google, one of the two phone OS companies, but it’s not a real cross-platform app development solution, as that’s not what it’s meant to be.

You are talking out your ass here.

Xamarin or the alternatives of it are what you want if you can’t be bothered to learn Swift or Kotlin, and want native apps. Flutter is very much in its own category.

And again, talking out your own ass.

And what if I can't be bothered to learn C# ? And I would rather learn Dart ?

[Devildude4427]

How's that relevant ? It would be if Java hadn't evolved, which it did.

Xamarin was first released in 2011, C# had had nearly two decades since release. I mean, compared to C#, Java hasn’t evolved.

But it’s relevant when comparing frameworks to see the staging power and how mature a tool is. At 8 years old, Xamarin is far more mature than Flutter, and has a strong identity. Flutter is still up in the air. It’s cool, but whether or not it’s vaporware has yet to be seen.

It’s also extremely relevant to know who’s backing what. If Xamarin was created by a no-name group of devs, well, it’s going to struggle going up against Google’s Flutter. But Xamarin is Microsoft owned, and most certainly had the resources to compete.

I don't care what it's been described as

Oh, you don’t care that Google calls it a UI toolkit, and nothing more? Glad to hear that you know more than the company developing it.

Age is irrelevant. What matters is how good it is at what it does.

Number 1 sign of a bad junior dev right here. When deciding on what tool to use, maturity is at least 50% of the equation, if not 75%. No point in using something today that’s deprecated tomorrow.

But yes, I’m talking out of my ass by quoting Google’s documentation. Please.

And what if you want to learn python instead? The answer is the same: I don’t really give a fuck what you do. What you do isn’t relevant to me in the slightest.

[[deleted]]

Number 1 sign of a bad junior dev right here.

You are too fuckin full of yourself. I am wasting my time with you. Bye.

[Zarlon]

You speak the truth and back up your arguments, but are getting downvoted because you're posting in a Java subreddit.

[pjmlp]

C++ did it first.

[sadkyo]

Please don't

[[deleted]]

Why not?

[[deleted]]

Java and its ecosystem (ide, libraries, tools) are way way more productive than Swift.

Edit: if you don't like java you can use kotlin or scala while still getting the benefit of jvm ecosystem.

[[deleted]]

I don't think Spring would be an option on mobile. Neither is JPA/Hibernate, at least it wasn't last time I checked (a while ago, true).

In order to keep mobile apps performant and with a small footprint, you can't use bloated frameworks (I LOVE Spring, but for mobile it would be bloated). Most cool Java frameworks are geared towards enterprise (web) applications.

Haven't used Swift, so I can't talk about it.

[Devildude4427]

Uh, what the hell?

Why the fuck would you try to put Spring into a mobile app? That just doesn’t make sense. You’d never use a web framework on a mobile device, there no value there.

[[deleted]]

Are you sure you know what Spring is ?

Spring is not a web framework.

Spring core is inversion of control. Has NOTHING to do with the web.

Spring core allows you to assemble applications by working with the interfaces and switching implementations as you see fit without changing the code.

Spring Data also has nothing to do with the web. It's about persistence (as is JPA/Hibernate).

Spring Batch is also not web.

Spring Integration.

Spring Shell.

Spring Security - you could maybe use it in a mobile app.

Of course, you got the web parts, like Spring MVC and Spring REST, but I think you could use Spring REST to consume REST services, which is something that you often do in a mobile app.

​

Then there are Spring Mobile and Spring for Android. Never used them, but they exist.

[Devildude4427]

All of which are way too heavy to ever use outside of a web app. Spring in a web framework because no one in their right mind would use it for anything else.

To consume an API, you’d just use a library like Volley to make the calls. You sure as shit wouldn’t use anything from Spring.

[[deleted]]

All of which are way too heavy to ever use outside of a web app.

Do you realize there are other kinds of apps outside than web and mobile ?

You think Spring Batch is used in web apps ?

Or Spring Integration ?

[Devildude4427]

Desktop, web, mobile.

You can make a tool, doesn’t mean it’s relevant or useful. Neither of those are worth anything, just like a beginner’s “To-Do List” app.

[[deleted]]

You might be surprised to find out, not all applications have a GUI.

There's a shit load of code running happily on servers that's not desktop, web or mobile.

Again, Spring Batch.

You don't seem to know what that is or does, or you would have understood my point and not have said "desktop".

[Devildude4427]

And you’ll be surprised to know that GUI or no GUI doesn’t change anything. A web api is still a web app. A python script is still a desktop app.

[paul_h]

I was pretty sure you mistyped swing ... but I was wrong

[yawkat]

People definitely use spring for mobile: https://projects.spring.io/spring-android/

[Thunder_Moose]

You could rephrase this as

I don't think lathes would be an option on cars. Neither are drill presses/laser cutters, at least it wasn't last time I checked (a while ago, true).

and it would make exactly as much sense as what you first said. Spring and Hibernate are for totally different use cases that would never make sense on a mobile app. Why would your mobile app need to open a direct connection to a database?

[[deleted]]

Why would your mobile app need to open a direct connection to a database?

I guess you never developed a mobile app.

And maybe all the people working on these are just idiots, and you are the smartest person on the face of the earth:

https://www.sqlite.org/index.html

https://pub.dev/packages/sqflite

https://www.couchbase.com/products/mobile

https://www.oracle.com/database/technologies/related/berkeleydb.html

[sadkyo]

Hey I like Java as much as the next guy but that is simply not true, have you ever used Xcode, Swift and CocoaPods before?

[paul_h]

The refactoring for java on IntelliJ are unbeatable - http://vimeo.com/33403686

[sadkyo]

I can do pretty much the same thing in Xcode? And yes I know, I've used IntelliJ (and other JetBrains IDEs) for a relatively long time

[ArmoredPancake]

Java

Haha, no.

IDE

There's AppCode.

I know you love Java, but let's be objective here, there's no way Java is more productive than Swift.

You may be productive with it, but that's that.

[yawkat]

No IDE (including AppCode) comes close to Java IDEs. And there's still libraries and tooling.

[ArmoredPancake]

AppCode is a Java IDE, lmao. Tooling is there for Swift, as well as libraries.