TeaVM: Build Fast, Modern Web Apps in Java(teavm.org)
teavm.org
TeaVM: Build Fast, Modern Web Apps in Java
http://teavm.org/
161 comments
Forget about web development for a second.
TeaVM is primarily a JVM byte-code to JS (and WASM, and plain C code) compiler. It is so effective at this, that not long ago I was able to bring a byte-code only proprietary JVM library to the web and it just worked. This thanks to an almost complete classpath library (based on Apache Harmony) and a macro system [1] that allows to produce POJO to JSON conversion code at compile time.
[1] http://teavm.org/docs/runtime/metaprogramming.html
TeaVM is primarily a JVM byte-code to JS (and WASM, and plain C code) compiler. It is so effective at this, that not long ago I was able to bring a byte-code only proprietary JVM library to the web and it just worked. This thanks to an almost complete classpath library (based on Apache Harmony) and a macro system [1] that allows to produce POJO to JSON conversion code at compile time.
[1] http://teavm.org/docs/runtime/metaprogramming.html
Anyone who has actually tried this have any comments?
I think it's interesting that they seem to position themselves as an alternative to programmers of jvm languages needing to switch to javascript for browser-side work, but they don't make a clear comparison to eg scala.js or kotlin js, where js code is generated, but not from class files.
I've tried playing with those, and one source of challenges is working with js libraries, which need some wrappers expressing method signatures, which is sometimes a challenge. TeaVM has a bunch of annotations for js interior, as well as the ability to deal with js code as just strings. But I can't see that it clearly solves the issues I find most annoying about scala.js or kotlin js. Is this only a great fit if you're in a polyglot jvm team that also wants to run that code in the browser?
I think it's interesting that they seem to position themselves as an alternative to programmers of jvm languages needing to switch to javascript for browser-side work, but they don't make a clear comparison to eg scala.js or kotlin js, where js code is generated, but not from class files.
I've tried playing with those, and one source of challenges is working with js libraries, which need some wrappers expressing method signatures, which is sometimes a challenge. TeaVM has a bunch of annotations for js interior, as well as the ability to deal with js code as just strings. But I can't see that it clearly solves the issues I find most annoying about scala.js or kotlin js. Is this only a great fit if you're in a polyglot jvm team that also wants to run that code in the browser?
FYI I, an author of TeaVM, used to work in Kotlin/JS team in JetBrains. Later I came to conclusion that Kotlin is still very Java-ish language, which inherits a lot of design of JVM platform and will always be 2nd class citizen in JS world. In that sense Kotlin/JS is not that different from TeaVM. There were same challenges on designing interop between Kotlin and JS, as with TeaVM and JS. True, in some rare cases having source code makes things easier. True, Kotlin/JS interop is little bit better that TeaVM's. This was not caused by impossibility to make better interop in TeaVM, this was deliberate choice. There's always trade-off between performance and interop quality. My decision was folloing: since it's impossible to make perfect interop and be 1st class citizen, I better make TeaVM perform good its primary job: execute Java.
These thoughts made me quit my job at Kotlin team and join Delightex to work on their product that uses TeaVM heavily: https://edu.cospaces.io/
These thoughts made me quit my job at Kotlin team and join Delightex to work on their product that uses TeaVM heavily: https://edu.cospaces.io/
> Anyone who has actually tried this have any comments?
I manage a Java/Kotlin WORA toolkit called Codename One that deploys to all the major platforms (iOS, Android, Windows, Mac, Web, etc..). We use TeaVM for our web platform, and it has been fantastic. It was the first solution to provide support for threads in JS. (i.e. Your java programs can use synchronization, and they will work properly when deployed to the web).
The performance is very good (we tried other options to get a web port working before we found TeaVM, and none could compare).
The developer is responsive to bugs - but it has been rock solid for us. At this point the JS port is one of our most stable platforms.
The development environment is also nice to work with. I work with all of the native SDKs that we deploy to, and TeaVM is my favourite. In particular, the JS<->Java interop is smooth and easy with minimal boiler plate. On most platforms, using a native API is at least a little painful - with some boiler plate necessary. On TeaVM it has annotations to be able to "drop into" javascript without a lot of fuss.
The performance is very good (we tried other options to get a web port working before we found TeaVM, and none could compare).
The developer is responsive to bugs - but it has been rock solid for us. At this point the JS port is one of our most stable platforms.
The development environment is also nice to work with. I work with all of the native SDKs that we deploy to, and TeaVM is my favourite. In particular, the JS<->Java interop is smooth and easy with minimal boiler plate. On most platforms, using a native API is at least a little painful - with some boiler plate necessary. On TeaVM it has annotations to be able to "drop into" javascript without a lot of fuss.
TeaVM is nice if you want to bring existing Java code depending on the Java standard library to a browser. Kotlin-js does not do that. You only have the Kotlin standard library if you target kotlin-js (well plus all the multiplatform stuff that is getting released lately). Multiplatform is the reason why this is getting interesting. There are a lot of good quality libraries that just work on kotlin-js now.
I've been using kotlin-js lately for browser development (with the Fritz2 framework). It's fine and improving rapidly. Just a year ago, this would have been a bit of a rough experience doing anything with it. But I've been using it since two months and have not really encountered any major issues. The Kotlin 1.4 release really improved things. And we indeed have a lot of Kotlin code for Android and our server so that made that an easy choice for us.
It's early days for WASM and languages like Kotlin and Java but I'm guessing that a lot of stuff is going to happen there in the next years. In the end you need more than a compilation target: you also need platform integration, development tools, and libraries. Kotlin-js is getting pretty nice for each of those and with all the multiplatform stuff coming out, you don't really need or miss a lot of the npm stuff. But if you do, it's fairly easy to deal with that as well (e.g. we integrated leaflet just a few weeks ago).
WASM support in Kotlin is still pretty immature. They recently kicked off an effort to improve support for that in the multiplatform gradle plugin. But there's still a lot of work to be done there. But, long term, I'd expect to compile to that rather than to Javascript.
I've been using kotlin-js lately for browser development (with the Fritz2 framework). It's fine and improving rapidly. Just a year ago, this would have been a bit of a rough experience doing anything with it. But I've been using it since two months and have not really encountered any major issues. The Kotlin 1.4 release really improved things. And we indeed have a lot of Kotlin code for Android and our server so that made that an easy choice for us.
It's early days for WASM and languages like Kotlin and Java but I'm guessing that a lot of stuff is going to happen there in the next years. In the end you need more than a compilation target: you also need platform integration, development tools, and libraries. Kotlin-js is getting pretty nice for each of those and with all the multiplatform stuff coming out, you don't really need or miss a lot of the npm stuff. But if you do, it's fairly easy to deal with that as well (e.g. we integrated leaflet just a few weeks ago).
WASM support in Kotlin is still pretty immature. They recently kicked off an effort to improve support for that in the multiplatform gradle plugin. But there's still a lot of work to be done there. But, long term, I'd expect to compile to that rather than to Javascript.
I have had great experience bringing my desktop apps to the browser with TeaVM. The performance is great, the generated JS is small (usually about 1mb gzip for my midsized apps).
I do have the benefit of a UI abstraction - my UI kit runs on Swing/JavaFX on the desktop, and on HTML/DOM (canvas based) in the browser.
https://reportmill.com/snaptea
I do have the benefit of a UI abstraction - my UI kit runs on Swing/JavaFX on the desktop, and on HTML/DOM (canvas based) in the browser.
https://reportmill.com/snaptea
I use TeaVM exclusively now to build web apps. It is rock solid and performant in every respect including runtime speed and download size. It is great alone or in conjunction with its SPA toolkit Flavour (https://blogs.oracle.com/javamagazine/java-in-the-browser-wi...)
Some examples:
* MerchMaker (make Roblox merch): https://frequal.com/merchmaker/
* Funniest Stories Ever (fill in the blank stories): https://fse.frequal.com
* CoronaWait (store wait times and in-stock reports): https://coronawait.frequal.com/
Some examples:
* MerchMaker (make Roblox merch): https://frequal.com/merchmaker/
* Funniest Stories Ever (fill in the blank stories): https://fse.frequal.com
* CoronaWait (store wait times and in-stock reports): https://coronawait.frequal.com/
To piggyback on your request from someone who's tried it, I'm also curious about how this deals with the fact that Java is garbage collected but wasm (in itself) is not. Did they actually port a GC to wasm, or do they work around this in another way?
The WASM port is experimental. The Javascript target produces better performance. For JVM languages it will always be the case that the Javascript target performance better than the WASM target, mostly because of GC.
For the WASM port the developer wrote his own GC.
[deleted]
Targeting WASM is just like targeting a CPU, most of them also don't have hardware support for GC algorithms.
Most anti-GC FUD regarding WASM and GC kind of stems from people not getting how GCs are implemented.
Most anti-GC FUD regarding WASM and GC kind of stems from people not getting how GCs are implemented.
They do have a GC on their roadmap, I assume to better support running languages that need a GC without having to pull their whole runtime into WASM. Isn't it fair to say WASM is somewhere in-between a CPU and a VM?
There are CPUs with hardware GC support, then tagged memory is coming back into fashion as means to tame C derived languages, and most Assembly languages are actually processed by tiny runtimes (microcode), as the pure hardware based gates is long gone in most high performance CPUs.
So between a CPU and VM depends pretty much on how one looks at it.
So between a CPU and VM depends pretty much on how one looks at it.
I've used it because my uni still forces us to use Java (https://github.com/alphahorizonio/jnebulark) but the experience hasn't been that great for the actual framework (bindings are way to hard to do; I haven't found a way to do Promises yet, see https://github.com/alphahorizonio/jnebulark/blob/main/src/ma...). In general, docs are lacking quite a bit as well (you have to use the development version for most things now, which isn't in sync with the docs). We just took the sane route, wrote the backend in TypeScript (and ported to Java for Uni), and used React for the frontend. The WebAssembly support of TeaVM is fun to use for small modules though, we integrated it into a WIP project: https://docs.webnetes.dev/getting-started/develop/java.html
"I haven't found a way to do promises yet". TeaVM provides Java wrappers for most JS APIs, including promises (https://github.com/konsoletyper/teavm/blob/master/core/src/m...). If you require an API that doesn't have a wrapper yet, it is dead simple to create your own wrapper. Or just use the @JSBody annotation to write your own ad-hoc Javascript.
Thanks for the link! This looks like a significant improvement over my current solution of trying to pass callbacks ... which aren’t transferable types sadly ;)
This is pretty danged slick. I especially like the API to create your own components very intuitive.
One rotten egg I can spot: "Supported subset of Jackson". Ow. Jackson is unfortunately a land mine, rattled with CVEs over the years. This was mostly fixed by taking the best ideas from Jackson and standardizing them as JsonB, which not have several good implementations. I would highly suggest they drop Jackson support in flavor of JsonB just so the Jackson libs don't have to be on anyones class path.
One rotten egg I can spot: "Supported subset of Jackson". Ow. Jackson is unfortunately a land mine, rattled with CVEs over the years. This was mostly fixed by taking the best ideas from Jackson and standardizing them as JsonB, which not have several good implementations. I would highly suggest they drop Jackson support in flavor of JsonB just so the Jackson libs don't have to be on anyones class path.
Any more details? A quick googling doesn’t find many talking about comparative performance and security of Jackson vs jsonb vs gson?
Have seen Jackson in parts of my code base (internal, but still)
Have seen Jackson in parts of my code base (internal, but still)
These 3 issues basically.
https://www.cvedetails.com/vulnerability-list.php?vendor_id=...
As Jackson is used in Spring, you can assume most banks, big corporations, etc. use it. So, update your dependencies and it's fine.
Gson is kind of to be avoided for the simple reason that it seems to be no longer maintained by Google. I've used it in the past and its fine but wouldn't pick it for something new because of this.
If you are using Kotlin, kotlinx serialization is worth a look. I've been using that recently. One of the nice things is that it relies on compiler plugins and code generation rather than a lot of reflective magic at runtime. From a security and performance point of view, that's a good thing.
https://www.cvedetails.com/vulnerability-list.php?vendor_id=...
As Jackson is used in Spring, you can assume most banks, big corporations, etc. use it. So, update your dependencies and it's fine.
Gson is kind of to be avoided for the simple reason that it seems to be no longer maintained by Google. I've used it in the past and its fine but wouldn't pick it for something new because of this.
If you are using Kotlin, kotlinx serialization is worth a look. I've been using that recently. One of the nice things is that it relies on compiler plugins and code generation rather than a lot of reflective magic at runtime. From a security and performance point of view, that's a good thing.
kotlinx.serialization has a learning curve, but it is quite flexible and very fast. I've only used it on the JVM but obviously its cross-platform nature is a big plus as well.
It could use some simplified syntax (similar to how Kotson improved on Gson), perhaps a JPath parser. But for something that just went 1.0 very recently, it is terrific.
It could use some simplified syntax (similar to how Kotson improved on Gson), perhaps a JPath parser. But for something that just went 1.0 very recently, it is terrific.
We are using kotlinx serialization in a multiplatform project where we use the same model classes in a cross platform API client and our Spring server. Tested this on Javascript and JVM so far and will likely add IOS there soonish.
TeaVM Flavour does not compile Jackson. Instead it comes with its own JSON serializer that supports subset of Jackson annotation. As Kotlin serialization, it relies on code generation, no reflection used at all.
Correct, I'd rather not have it on the classpath nonetheless.
The hard part about WASM is passing data in and out. You can't pass JavaScript numbers, strings, arrays or objects, because WASM only understands bytes. Does TeaVM make this easier?
Update: TeaVM does make it easier: http://teavm.org/docs/runtime/jso.html
Update: TeaVM does make it easier: http://teavm.org/docs/runtime/jso.html
What's the recommended way to drop into blocking code? For example, if you already have a worker thread pool executing some blocking code.
I am guessing it will automatically look for static occurrences of park(), wait(), etc anything that goes into a blocked state and yields to the next handler on the event queue?
Even with the coroutine support, it doesn't seem smart enough to make something like "while (true) { ... }" auto-yield to other functions or handlers on the event queue. To be fair, it's not like javascript does this for you either.
I am guessing it will automatically look for static occurrences of park(), wait(), etc anything that goes into a blocked state and yields to the next handler on the event queue?
Even with the coroutine support, it doesn't seem smart enough to make something like "while (true) { ... }" auto-yield to other functions or handlers on the event queue. To be fair, it's not like javascript does this for you either.
To use "blocking" code you must be running in a Java thread. You cannot "block" the main javascript thread. Generally all of our code runs on a Java thread. For JS events (which always occur on the main JS thread, I just wrap in new Thread(()->{...}).start();
How big is the js for ToDoMVC generated by TeaVM ?
31.55KB transferred according to Chrome for the sample app here: http://teavm.org/live-examples/todomvc/#/
Compared to React, GWT, Vaadin, and CheerpJ, TeaVM comes out on top for Lighthouse scores and JavaScript size: https://renato.athaydes.com/posts/comparing-jvm-alternatives...
Compared to React, GWT, Vaadin, and CheerpJ, TeaVM comes out on top for Lighthouse scores and JavaScript size: https://renato.athaydes.com/posts/comparing-jvm-alternatives...
> Its close relative is the well-known GWT
The thing that is (somewhat) well-known for being an awful mess, which Google eventually realised and moved away from? Those who do not learn the mistakes of history...
The thing that is (somewhat) well-known for being an awful mess, which Google eventually realised and moved away from? Those who do not learn the mistakes of history...
Only the UI toolkit part was a mess. Google still uses Java to JavaScript compilation, through GWT’s successor J2CL.
If curious see also
2018 https://news.ycombinator.com/item?id=16075933
2018 https://news.ycombinator.com/item?id=16075933
On-topic questions: If it's generating wasm, how's the collector work? If it's generating JavaScript, what happens to weak refs?
There are separate compiler backends for Wasm and JS. JS BE does not support WeakReferences (or rather supports them as a class, but does not support weak reference semantics). For Wasm BE I written my own GC, which supports weak references.
How does this compare to Google Web Toolkit?
TeaVM and Flavour are an improvement over GWT. Why is TeaVM better?
* Full threading implementation
* Fast builds
* Designer-friendly HTML/CSS
Detailed comparison: https://frequal.com/TeaVM/TeaVmVsGwt.html
* Full threading implementation
* Fast builds
* Designer-friendly HTML/CSS
Detailed comparison: https://frequal.com/TeaVM/TeaVmVsGwt.html
It compiles JVM bytecode. GWT compiles Java source code. Therefore, GWT requires source whereas TeaVM doesn’t. It also means TeaVM will work with any language that compiles to JVM bytecode.
Is this a Java alternative to Blazor?
TeaVM + Flavour makes a superior alternative to Blazor.
* TeaVM supports threads, Blazor does not.
* TeaVM apps can start in 3s, Blazor apps cannot.
* TeaVM eliminates unused code for fast startup, Blazor is architecturally limited to download an entire VM at startup.
Details: https://frequal.com/java/TeaVmVsBlazorWasm1-0.html
Comparison chart: https://frequal.com/java/TeaVmVsBlazorChart.html
* TeaVM supports threads, Blazor does not.
* TeaVM apps can start in 3s, Blazor apps cannot.
* TeaVM eliminates unused code for fast startup, Blazor is architecturally limited to download an entire VM at startup.
Details: https://frequal.com/java/TeaVmVsBlazorWasm1-0.html
Comparison chart: https://frequal.com/java/TeaVmVsBlazorChart.html
I always thought of TeaVM as a toy project, but boy, was I wrong!
Yes, you could describe it that way, I suppose. TeaVM is just the "VM" part of it. The developer has a "sister" project called "Flavour" that provides a UI framework. https://github.com/konsoletyper/teavm-flavour
the word GWT gives me PTSD
no doubt. was once involved at a place that had a GWT codebase and I was a react dev, right there then I decided to quit my job. surprised why the industry continues to regress backwards and not embrace html and the web as they should be.
TeaVM, especially when used with its Flavour toolkit, fully embraces HTML and CSS. Flavour templates are HTML5 with a small number of extra elements to allow dynamism and interactivity. Templates can be styled with CSS and worked on by designers and developers alike.
A good way to think about it is a new single-page app framework for the web that lets you code in a popular, safe, statically-typed language with great IDEs and tools.
A good way to think about it is a new single-page app framework for the web that lets you code in a popular, safe, statically-typed language with great IDEs and tools.
I have Firefox’s “HTTPS-only” mode enabled. teavm.org is only served on HTTP. This gave me a rather bad first impression of a thing for making modern web apps—TLS is table stakes that you should never be without.
(I tend to find something HTTP-only about once a day, normally on sites that have been around for over ten years. Normally I’d just shrug if it’s a content site, but this being for making web apps, I figured it was worth commenting on.)
(I tend to find something HTTP-only about once a day, normally on sites that have been around for over ten years. Normally I’d just shrug if it’s a content site, but this being for making web apps, I figured it was worth commenting on.)
Tell me again what the threat mode TLS protects against for a marketing site?
The only thing I can think of is my ISP injecting some HTML at the top of the page. Something that I haven’t seen for years.
The only thing I can think of is my ISP injecting some HTML at the top of the page. Something that I haven’t seen for years.
Letting the ISP inject stuff is the threat model, and it has happened in real life. https://www.theregister.com/2015/03/27/github_under_fire_fro...
Every connection that happens over unsecured HTTP is a connection that can be hijacked by middlemen for nefarious purposes, both for spying and for attacking.
Encrypting as many connections as possible is a form of herd immunity. Encrypting even unimportant "marketing" websites protects everyone on the web by raising the cost of interception and lowering the benefits.
Every connection that happens over unsecured HTTP is a connection that can be hijacked by middlemen for nefarious purposes, both for spying and for attacking.
Encrypting as many connections as possible is a form of herd immunity. Encrypting even unimportant "marketing" websites protects everyone on the web by raising the cost of interception and lowering the benefits.
100% yes.
It's also about the entire internet & its users, not just threat models on specific sites.
We can't ask the general public to consider threat models and evaluate what sites should need HTTPS or just HTTP. General, non-technical intuition is basically useless for this eval; it's not a good path.
It's much smarter to just make HTTPS the default, make it easy & free for any site to provide it, and then let browsers show big warnings for any site that's not secured.
(Browsers are moving this way already)
It's also about the entire internet & its users, not just threat models on specific sites.
We can't ask the general public to consider threat models and evaluate what sites should need HTTPS or just HTTP. General, non-technical intuition is basically useless for this eval; it's not a good path.
It's much smarter to just make HTTPS the default, make it easy & free for any site to provide it, and then let browsers show big warnings for any site that's not secured.
(Browsers are moving this way already)
> without the difficulties of a JavaScript development stack.
Yes. It's very difficult to write a full stack application using JavaScript. I cannot find tools or frameworks.
Yes. It's very difficult to write a full stack application using JavaScript. I cannot find tools or frameworks.
The frameworks and tools aren't all that stable, reliable, or intentionally designed compared with what Java programmers might be used to. I don't fault anyone for trying to get off the bus.
Is JS tooling less of a Rube Goldberg machine nowadays? I remember that the people I knew who got into it but not fully used to use these humongous auto-generated boilerplates that glued together webpack, gulp, babel, had build processes involving native dependencies that would fail with weird errors vaguely related to Node JS versions, and this all to develop in the frontend.
Compare: Clojure. You have the project.clj file and put your dependencies there. The you do lein run or build a fat jar and run it like java -cp your.jar your_app.core. The end.
Compare: Clojure. You have the project.clj file and put your dependencies there. The you do lein run or build a fat jar and run it like java -cp your.jar your_app.core. The end.
Not really (any less). A couple of years ago we migrated a project from Spring + GWT to Spring + Vue. The Vue part is nicer, but everything around it feels messy. The team is primarily backend / java developers (we had a frontend expert at the time too), but we felt that the JS frontend part shouldn't be that hard to master. Maybe Vaadin would have been a better option after all?
No it’s even more so with the rise of framework frameworks like Next.JS and Cypress. These frameworks are just wrappers around other frameworks. JS will never escape this as its primary reason for existence was a glue layer between Browser and HTML/CSS.
I've yet to see a single professional software company use these eztra layers. Though there are no doubt some most people are still using React, Vue or Angular directly.
Here are a few software companies moving to next.js.
https://nextjs.org/case-studies/hulu
https://nextjs.org/showcase/uber
https://eng.lyft.com/changing-lanes-how-lyft-is-migrating-10...
https://nextjs.org/case-studies/hulu
https://nextjs.org/showcase/uber
https://eng.lyft.com/changing-lanes-how-lyft-is-migrating-10...
Thw humungous auto-geberated boilerplates are rude goldberg machines. But you don't need those at all. A simple webpack config (including setting up babel, typescript, etc) is less than 100 lines (not nothing, but comparable to build scripts in other langauges).
It's worth noting that there is some inherent complexity in the web platform due to the fact that you are generally targetting multiple platforms. Server side code has it easy here (and indeed Node.js generally needs little in the way of build process)
Regarding error with native NPM dependencies (usually when switching node versionw, or switching between macOS node and linux node in docker): this can almost always be solved witha simple `npm rebuild` once when you change node version.
It's worth noting that there is some inherent complexity in the web platform due to the fact that you are generally targetting multiple platforms. Server side code has it easy here (and indeed Node.js generally needs little in the way of build process)
Regarding error with native NPM dependencies (usually when switching node versionw, or switching between macOS node and linux node in docker): this can almost always be solved witha simple `npm rebuild` once when you change node version.
After all the shebang out comes an html with tables instead of divs.
divs + css in yet another file, you mean. Tables at least do something in and of themselves; divs do not.
1999 called, it wants it's html structure back. lolz!
<eye roll> For tables, tables are fine. The only thing worse than jumping on a new thing because it's new is completely abandoning something because it's not.
And "lolz"? 2010 called...
And "lolz"? 2010 called...
I don't see how using TeaVM, which is not stable at all, has very little activity (a handful of commits since summer) and is going to be extremely niche since most people don't have that weird aversion to modern JS tooling, is a solution.
Come on. Even if you dispise the
js world, plenty of examples of well written JavaScript frameworks and successful end user products.
Sounds easy enough: Use the well written frameworks as needed, and you can make successful end products too.
What would be your advice to someone seeking to do this?
e.g. - is it simply a matter of intelligence, perseverance, attitude? - is there a technical or social practice you find helpful?
What would be your advice to someone seeking to do this?
e.g. - is it simply a matter of intelligence, perseverance, attitude? - is there a technical or social practice you find helpful?
I don’t think this is the definition of difficult the author is using. I find JavaScript intimidating and difficult due to too many tools and frameworks. I cannot rely on any of their documentation, either on their site, or the peripheral collective experience of stack overflow, to be accurate to the actual thing I’m trying to use. This makes it difficult to me.
My last four projects, changed from Angular 6 and Ionide, just Angular 6, followed by Vue.js, now doing one with React.
Who knows what the FE team will remember to come up on the next assignment.
Who knows what the FE team will remember to come up on the next assignment.
I used to work at a large F500 corp and managed a legacy app that used raw js/jquery on the front end. Every two years like clockwork we'd get a mandate that "all apps will now use X" where X was [ext-js, ember, angular]. As the person in charge of the app I ignored all those directives and saved myself a boatload of work. App is still using jquery today last I heard.
Why does everyone keep lumping jQuery in with vanilla JS, in exalted reverence, as if jQuery wasn't a massive source of bloat during its heyday? The practice of pulling in all of jQuery just to add an event listener for showing and hiding a div is _why_ web development looks the way it does today. Normalization of deviance is the vehicle, and jQuery was the payload.
I come across stuff "only" using jQuery today, and every time, I end up ripping it out because it's totally unnecessary and often ends up being the source of breakage and logic errors. What's worse is that its APIs are awful, and it's impossible to debug in its blob form. The fix always ends up being to just get rid of it.
I come across stuff "only" using jQuery today, and every time, I end up ripping it out because it's totally unnecessary and often ends up being the source of breakage and logic errors. What's worse is that its APIs are awful, and it's impossible to debug in its blob form. The fix always ends up being to just get rid of it.
That's not the point of the comment above.
FYI: The point is that every year or two you get a new "revolutionary" framework. Unless you're working full time on FE - you're not going to be "in with the cool kids".
FYI: The point is that every year or two you get a new "revolutionary" framework. Unless you're working full time on FE - you're not going to be "in with the cool kids".
Genius
Soon it may be Svelte for me as it simplifies the React data model for me a lot... But there goes all the ecosystem again for React/Angular/Vue libs and docs. Then we repeat until someone figures out a better way to develop on the web (aka whats after Svelte?).
I'm hoping https://hotwire.dev/ solves some of my issues, I hope to see it picked up in SpringBoot/Quarkus community more.
I'm hoping https://hotwire.dev/ solves some of my issues, I hope to see it picked up in SpringBoot/Quarkus community more.
I don't know whether it's sarcasm or not.
Finding them is not the problem. Figuring out which one to use is.
The obvious way to me for full stack JavaScript is to use JavaScript on the server with node.js and JavaScript on the client via a... Browser.
Java applets reinvented
Nah.
Java applets involved running an actual JVM on every client computer, which meant basically doubling the risk surface of the browser... plus you had a completely different UI (that couldn't match the browser UI) sitting inside a web page.
I confess I wrote a bunch of Java applets back in the day; but I can't say I'm surprised they died, and I don't think they'll be back.
Java applets involved running an actual JVM on every client computer, which meant basically doubling the risk surface of the browser... plus you had a completely different UI (that couldn't match the browser UI) sitting inside a web page.
I confess I wrote a bunch of Java applets back in the day; but I can't say I'm surprised they died, and I don't think they'll be back.
>I confess I wrote a bunch of Java applets back in the day
Heh. Nothing to confess. Before the HTML5 set of standards (circle 2008), there were certain things you just couldn't do in the browser with JavaScript. That's why there was space for plugins like Applets, Flash, ActiveX, RealPlayer, etc. I did quite a bit of Flash/AS3 (along with the Flash wasm/asm precursor named 'alchemy') development back in the day. If I was able to do it with JS/HTML/CSS I would have done that instead - but you just couldn't.
Heh. Nothing to confess. Before the HTML5 set of standards (circle 2008), there were certain things you just couldn't do in the browser with JavaScript. That's why there was space for plugins like Applets, Flash, ActiveX, RealPlayer, etc. I did quite a bit of Flash/AS3 (along with the Flash wasm/asm precursor named 'alchemy') development back in the day. If I was able to do it with JS/HTML/CSS I would have done that instead - but you just couldn't.
Maybe having a SSL cert would made it more presentable for a web framework. Maybe
How does Java pricing work these days (after being bought by Oracle)?
After being rescued by Oracle, after all no one else wanted to buy Sun, not even Google (hoping it would just sink most likely).
Java is as open source and still has multiple implementations available, even Microsoft is now a Java vendor (after having bought jClarity).
Basically you want free beer like Linux? Get a distribution from OpenJDK.
You want support Red-Hat/SuSE style? There is Oracle, and a plenty of other vendors happy to sell JDKs with support.
Java is as open source and still has multiple implementations available, even Microsoft is now a Java vendor (after having bought jClarity).
Basically you want free beer like Linux? Get a distribution from OpenJDK.
You want support Red-Hat/SuSE style? There is Oracle, and a plenty of other vendors happy to sell JDKs with support.
>After being rescued by Oracle
Java was not rescued by Oracle. There was never any danger of Java going away or not having a proper sponsor. If anything was 'rescued', it was the SPARC/Solaris division of Sun.
Java was not rescued by Oracle. There was never any danger of Java going away or not having a proper sponsor. If anything was 'rescued', it was the SPARC/Solaris division of Sun.
At the time, and that is still the case today, Sun / Oracle was the single largest contributor to the Java Ecosystem.
Java will surely live but will it thrive without all those investment?
Java will surely live but will it thrive without all those investment?
>At the time, and that is still the case today, Sun / Oracle was the single largest contributor to the Java Ecosystem.
So what? What does that have to do with what I argued?
>Java will surely live but will it thrive without all those investment?
Are you really trying to make the argument that had Oracle not bought Sun, that Java, one of the most popular programming languages, would have gone away?
So what? What does that have to do with what I argued?
>Java will surely live but will it thrive without all those investment?
Are you really trying to make the argument that had Oracle not bought Sun, that Java, one of the most popular programming languages, would have gone away?
Definitely, as proven by the high performance JIT and GC implementation available for Ruby and Python by the community.
Heh. OK. Oracle clearly saved Java, the most popular programming language in the world, which also drives much of corporate and government infrastructure. We live in different realities. This idea is so silly I'm not even sure if you're serious, given that SUN's troubles at the time are a matter of historical record. Java was never the problem. In fact, it was SUN's most highly valued asset. SUN never recovered after the dot com crash and industry transition to x86 and Linux, all of which led to the death of SPARC and Solaris. But let's leave it at that.
>as proven by the high performance JIT and GC implementation available for Ruby and Python by the community.
It's almost like interpreted dynamic languages are not quite as conducive to the same kind of optimizations as a statically typed compiled language. JavaScript, another interpreted dynamic language, did have massive amount of resources poured into its JIT and GC implementation. No question there were meaningful performance gains. Is it faster than Java? No. Is it ever going to be faster? No, not unless the language compromises on its dynamic nature.
And you're still chasing this red-herring. I never argued that FOSS can do a better job at evolving a programming language runtime, than a corporate sponsor. Why are you harping on that as if that is an argument to support the idea that java was in trouble and needed a bailout from Oracle?
>as proven by the high performance JIT and GC implementation available for Ruby and Python by the community.
It's almost like interpreted dynamic languages are not quite as conducive to the same kind of optimizations as a statically typed compiled language. JavaScript, another interpreted dynamic language, did have massive amount of resources poured into its JIT and GC implementation. No question there were meaningful performance gains. Is it faster than Java? No. Is it ever going to be faster? No, not unless the language compromises on its dynamic nature.
And you're still chasing this red-herring. I never argued that FOSS can do a better job at evolving a programming language runtime, than a corporate sponsor. Why are you harping on that as if that is an argument to support the idea that java was in trouble and needed a bailout from Oracle?
Sure, where are the post Java 6 FOSS contributions from the community, if I may ask?
I made no statement about who contributed to Java and how much. So what does that have to do with anything?
Are you actually making the argument that had Oracle not bought Sun that Java, one of the most widely used commercial programming language then and now, would have .. what? Gone away? Disappeared?
Are you actually making the argument that had Oracle not bought Sun that Java, one of the most widely used commercial programming language then and now, would have .. what? Gone away? Disappeared?
Definitely, as proven by the high performance JIT and GC implementation available for Ruby and Python by the community.
> Basically you want free beer like Linux? Get a distribution from OpenJDK.
After the Oracle lawsuit, why should people feel safe believing that Oracle will respect the terms of the license instead of trying to extract more money and subject you to a costly lawsuit?
After the Oracle lawsuit, why should people feel safe believing that Oracle will respect the terms of the license instead of trying to extract more money and subject you to a costly lawsuit?
Oracle's lawsuit was for modifying the license.
GPL with Classpath exception covers you well enough.
Google skipped on the GPL license, so they don't get the benefits of that license.... unlike all Java users.
GPL with Classpath exception covers you well enough.
Google skipped on the GPL license, so they don't get the benefits of that license.... unlike all Java users.
Do you trust Linux? It has the exact same license. Do you have any source where Oracle issued a lawsuit for lawful use of a license?
The same way they felt safe after Sun won over Microsoft.
... what? That's a non-answer.
Sure it is, Android Java === Google's J++, and the hammer shall fall just as hard.
Google had the opportunity to own Java, decided it wasn't worth the money, so now they should suffer the long due penalty.
Google had the opportunity to own Java, decided it wasn't worth the money, so now they should suffer the long due penalty.
That's still not an answer. You're avoiding the question and... I don't know, answering some other question that no one asked, it looks like.
If a company has the option between OpenJDK and its "free" license or paying Oracle for a different license, why would anyone feel safe choosing the former, given that when you deal with Oracle, you deal with the risk of wasting as much money or more to defend yourself in court than the price of Oracle's paid option? Open source licenses are only as good as as the belief by the licensing party that the terms of the license mean anything.
If a company has the option between OpenJDK and its "free" license or paying Oracle for a different license, why would anyone feel safe choosing the former, given that when you deal with Oracle, you deal with the risk of wasting as much money or more to defend yourself in court than the price of Oracle's paid option? Open source licenses are only as good as as the belief by the licensing party that the terms of the license mean anything.
My dear, Oracle SDK == OpenJDK + JFR license + support.
If you don't want to give money to Oracle, there are plenty of other companies to choose from, including Amazon, IBM, Microsoft, Alibaba, SAP, Azul.
If you don't want to give money to Oracle, there are plenty of other companies to choose from, including Amazon, IBM, Microsoft, Alibaba, SAP, Azul.
Once again, you have avoided the question (although you've spiced it up this time with some additional condescension).
You listed OpenJDK as a viable "free" option. Defend it, or don't, but stop trying to pivot the conversation while pretending that changing the subject is a valid answer answer to the thing that was asked.
You listed OpenJDK as a viable "free" option. Defend it, or don't, but stop trying to pivot the conversation while pretending that changing the subject is a valid answer answer to the thing that was asked.
The ability to understand falls on the recipient.
Your favourite search engine has the answer.
If you feel like trolling, that is your problem, bye.
Your favourite search engine has the answer.
If you feel like trolling, that is your problem, bye.
There is no confusion on this end. You're ignoring the question that I'm asking, because the answer is unpleasant, and you're instead responding with non-answers, because looking like you're saying something when you're really saying nothing is easier.
Facts: We have evidence that Oracle doesn't care about the actual terms of GPL. We have evidence that they're willing to subject people to legal turmoil if Oracle decides they want you to pay instead of using the "free" license.
Facts: We have evidence that Oracle doesn't care about the actual terms of GPL. We have evidence that they're willing to subject people to legal turmoil if Oracle decides they want you to pay instead of using the "free" license.
Amazon Corretto - Free
Java 8,11 supported by a big firm (Amazon)
https://aws.amazon.com/corretto/
Java 8,11 supported by a big firm (Amazon)
https://aws.amazon.com/corretto/
Thanks! I haven't heard about this.
Every seems to be being snarky, but on the off chance you care about the actual pricing, and assuming you're talking about Oracle's JDK and not OpenJDK: Oracle's JDK is free to use. You can pay for support if you want, which gives you the bleeding edge security patches immediately (without support you can upgrade every six months to get the all patches). The pricing for support is calculated by CPU core count I believe. So if you're using Java in production on 100 cores, that's going to be more expensive than 10. I don't have the specific numbers off the top of my head though.
It's worth pointing out that with Oracle's new Java licensing model whether something is free on charge depends on a number of things including how Oracle thinks it's being deployed.
The Oracle JDK is indeed free of charge for developing aplications, but running that app using Oracle Java on a server as opposed to a desktop needs a paid license subscription & generates exposure to Oracle license audits.
Many, many firms are now using OpenJDK and the like, and have policies against even downloading Oracle's version.
The Oracle JDK is indeed free of charge for developing aplications, but running that app using Oracle Java on a server as opposed to a desktop needs a paid license subscription & generates exposure to Oracle license audits.
Many, many firms are now using OpenJDK and the like, and have policies against even downloading Oracle's version.
I was not trying be to snarky. I was genuinely curious to know how it is priced after the oracle acquisition. As a language that I am most used to, I wanted to evaluate how much it'd cost (a rough estimate based on cores/users) if I were to launch a web service based on Java.
OpenJDK is Oracle's free, open-source implementation of the Oracle JDK. It is where Oracle does all of its JDK development. You can use it with no restrictions. If you want to pay for support, you can pay Oracle or any of several other companies that package up and support the OpenJDK. If you choose to pay Oracle, you'll get the Oracle JDK which is identical to the OpenJDK except for a couple of error messages and the ID string.
Oracle actually publish their price list for Oracle Java here - https://www.oracle.com/uk/corporate/pricing/#java-se
In short, starts at $25 per processor per month, discounts starting at 100+ . Look at using OpenJDK/ Amazon Corretto instead
In short, starts at $25 per processor per month, discounts starting at 100+ . Look at using OpenJDK/ Amazon Corretto instead
Since Java is free to use and is primarily developed as a GPL software - there are no licensing costs, that you would care about.
You can use OpenJDK (via adoptopenjdk, Redhat or many others) and it's free.
Or you pay Oracle for support. Or some other company.
Oracle isn't special.
Or you pay Oracle for support. Or some other company.
Oracle isn't special.
Well, on the other hand OpenJDK is 99% Oracle's work repackaged.
If Oracle decided to stop putting out new FOSS-licenced versions, there would be no new OpenJDK releases (since all the core Java devs are Oracle employees).
So it's like a no-community project, where you get a dump of FOSS code every now and then from a vendor.
If Oracle decided to stop putting out new FOSS-licenced versions, there would be no new OpenJDK releases (since all the core Java devs are Oracle employees).
So it's like a no-community project, where you get a dump of FOSS code every now and then from a vendor.
In recent Java versions, there's roughly 20% of external contributions:
https://blogs.oracle.com/java-platform-group/the-arrival-of-...
Oracle seems to pursue GraalVM EE as a way to monetize Java. It would be insane for them to change the license, piss off companies with deep pockets, risk a hard fork and see most employees working on the JDK leave.
https://blogs.oracle.com/java-platform-group/the-arrival-of-...
Oracle seems to pursue GraalVM EE as a way to monetize Java. It would be insane for them to change the license, piss off companies with deep pockets, risk a hard fork and see most employees working on the JDK leave.
>In recent Java versions, there's roughly 20% of external contributions:
Have to check your link to find out, but is it by number or by impact?
(Asking cause many projects have seemingly many "external contributors" but if one looks almost all real work happens by a core team, and the external contributors just do some change here and there, or even clerical work, like fixing comments and documentation and such).
Have to check your link to find out, but is it by number or by impact?
(Asking cause many projects have seemingly many "external contributors" but if one looks almost all real work happens by a core team, and the external contributors just do some change here and there, or even clerical work, like fixing comments and documentation and such).
The post measures by issue count, though not all issues are equal.
> Of the 2,136 JIRA issues marked as fixed in Java 15, 1,702 were completed by people working for Oracle, while 434 were contributed by individual developers and developers working for other organizations.
> Of the 2,136 JIRA issues marked as fixed in Java 15, 1,702 were completed by people working for Oracle, while 434 were contributed by individual developers and developers working for other organizations.
A correction - all the core Java developers are paid by Oracle to develop Java. I doubt that Oracle would win anything, by abandoning OpenJDK.
And now - they can't. Companies that are able to maintain Java are X times larger than Oracle and the core team would easily be rehired by IBM, Google, Aamazon, Facebook, Apple, etc...
And now - they can't. Companies that are able to maintain Java are X times larger than Oracle and the core team would easily be rehired by IBM, Google, Aamazon, Facebook, Apple, etc...
None of the companies you listed would gain much over current model. They would rather move to different technologies in case Java is abandoned.
> Companies that are able to maintain Java are X times larger than Oracle
With exception of maybe IBM which anyway is crapping out, none of the other owe their business success to directly to Java based product or services. If Java were to be abandoned they can easily migrate / rewrite their internal tools / products to a different platform even if it takes 5-10 years. It is not like current prod systems will stop working just by announcement.
Also to think further Oracle abandons Java , Amazon and Google would have huge incentive to either charge lot more for Java on cloud or redirect their customers to alternatives.
> Companies that are able to maintain Java are X times larger than Oracle
With exception of maybe IBM which anyway is crapping out, none of the other owe their business success to directly to Java based product or services. If Java were to be abandoned they can easily migrate / rewrite their internal tools / products to a different platform even if it takes 5-10 years. It is not like current prod systems will stop working just by announcement.
Also to think further Oracle abandons Java , Amazon and Google would have huge incentive to either charge lot more for Java on cloud or redirect their customers to alternatives.
> They would rather move to different technologies in case Java is abandoned.
They had the opportunity to do so for at least a decade now, but they didn't. Google, even after the massive row with Oracle, still uses Java extensively. Still has new projects written in Java(or running on JVM). Having a big legal battle between Google and Oracle would surely have dissuaded FAANGs from starting Java projects, right? Nope... You're flat out wrong.
> Java were to be abandoned they can easily migrate / rewrite
That's one delusional world you live in.
> It is not like current prod systems will stop working just by announcement.
And what makes you think that those big boys aren't going to be interested in maintaining JVM?
They had the opportunity to do so for at least a decade now, but they didn't. Google, even after the massive row with Oracle, still uses Java extensively. Still has new projects written in Java(or running on JVM). Having a big legal battle between Google and Oracle would surely have dissuaded FAANGs from starting Java projects, right? Nope... You're flat out wrong.
> Java were to be abandoned they can easily migrate / rewrite
That's one delusional world you live in.
> It is not like current prod systems will stop working just by announcement.
And what makes you think that those big boys aren't going to be interested in maintaining JVM?
As opposed to which big open-source project? Do you really believe linux is a few individuals’ work? Just look at which companies pay the contributors.
Free forever. It's open source.
Java is too slow. Just because modern hardware allows for software to be very heavy doesn't mean that it should be acceptable for you as a developer to produce heavy software.
It's 2021. 1999 wants its arguments back.
At the language/runtime level Java has been faster than anything else we have used on the Web with huge success (faster than PHP, Ruby/Rails, Python, Node, for example) even since 2000, and is as fast or faster than Go. It's also used in HFT - where ultimate speed means a lot.
Seriously, your argument sounds like the first year CS student argument of yore, where they hear that assembly is faster, and want to rewrite everything in assembly (fortunately today's first year CS students are more well informed).
At the language/runtime level Java has been faster than anything else we have used on the Web with huge success (faster than PHP, Ruby/Rails, Python, Node, for example) even since 2000, and is as fast or faster than Go. It's also used in HFT - where ultimate speed means a lot.
Seriously, your argument sounds like the first year CS student argument of yore, where they hear that assembly is faster, and want to rewrite everything in assembly (fortunately today's first year CS students are more well informed).
I complain all the time about the memory consumption of Java software, they behave like they are the only ones running on a computer, but not the speed. The JVM is actually pretty fast. For sure it's a bit slower than native code but if your Java code is slow, I'm sorry but it's your code and using C++, C, Rust or whatever else faster will not make your code fast.
Yep, here are some sources to back up the claim that Java performance is pretty okay.
TechEmpower benchmarks: https://www.techempower.com/benchmarks/#section=data-r19&hw=...
Language benchmarks game: https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
And just because i found it pretty interesting, here's a summary of a study that not only measures memory consumption and execution time, but also how much energy certain languages required: https://jaxenter.com/energy-efficient-programming-languages-...
TechEmpower benchmarks: https://www.techempower.com/benchmarks/#section=data-r19&hw=...
Language benchmarks game: https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
And just because i found it pretty interesting, here's a summary of a study that not only measures memory consumption and execution time, but also how much energy certain languages required: https://jaxenter.com/energy-efficient-programming-languages-...
My biggest issue with the JVM is the RAM consumption. Every other language, even JS beats it. GraalVM's native image feature is the only way to fix this and that is pretty sad that it took them multiple decades to fix such a glaring flaw.
Did you set a heap size for your app? Because the JVM has an eager way of consuming RAM (since then it doesn’t have to do useless work with garbage collection) - and the defaults are closer to a server config.
I'm sincerely wondering how you came to that conclusion. Java has one of the fastest VMs, but maybe you mean the startup speed?
JVMs that most people use are optimised for repeated execution of the same code paths on long running processes. If this isn’t your use-case then lots of tuning work is required.
That fits the common Java use-case of servers and desktop applications. Not so much for Lambda instances or command-line tools, but Java isn't highly used there anyway.
I don't know where you're getting this...
Lambda instances run really well with JVMs(the whole COW memory architecture)... and even CLIs run well enough.
Lambda instances run really well with JVMs(the whole COW memory architecture)... and even CLIs run well enough.
Like using the AOT compiler or JIT caches provided in recent versions, they are no longer features only available to customers of commercial JDKs.
The free AOT compilers have atrocious compile times (far, far worse than even Rust or Scala) and don't support all of the features so library support is extremely fragile. A lot of extremely popular Java libraries make extensive use of runtime reflection and none of the AOT compilers handle it well without a lot of extremely error prone manual configuration.
I actually like Java and the JVM but if AOT compilation and efficient memory usage is what you want Java is definitely not the language to use.
I actually like Java and the JVM but if AOT compilation and efficient memory usage is what you want Java is definitely not the language to use.
Yes, GraalVM requires a new sub ecosystem of libraries that are built with it's native image feature in mind. That means no more Spring, no more Hibernate and so on. Old codebases will not benefit and new code base require abandoning your existing Java expertise.
> no more Hibernate and so on
Quarkus, Redhat's, native first frameworks works fine with Hibernate and GraalVM. One of contributors gave a [talk](https://www.youtube.com/watch?v=za5CSBX-UME&feature=youtu.be)
Quarkus, Redhat's, native first frameworks works fine with Hibernate and GraalVM. One of contributors gave a [talk](https://www.youtube.com/watch?v=za5CSBX-UME&feature=youtu.be)
They work perfectly fine with JIT caches.
Plus not everyone is fan of Spring and Hirbenate.
The first I used only once in 20 years of Java projects, the second is the first to go away when I get called to optimise database performance in Java applications.
Plus not everyone is fan of Spring and Hirbenate.
The first I used only once in 20 years of Java projects, the second is the first to go away when I get called to optimise database performance in Java applications.
I agree. My main issue is with the Java zealots that come into the discussion and make it seem like anyone can just take their existing Java application and use it with an AOT compiler. The reality is that you will most likely have to make changes to your code, do a significant amount of configuration, and heavily modify or remove dependencies. Furthermore, you are isolating yourself from the huge Java community because very few people are using any of the existing AOT Java compilers.
They try to paint an extremely rosy picture of the current situation when the reality is that it's a very long way from the experience you get in Rust, Go, D, C, C++, Haskell, Ocaml or any of the languages where AOT is considered the default.
They try to paint an extremely rosy picture of the current situation when the reality is that it's a very long way from the experience you get in Rust, Go, D, C, C++, Haskell, Ocaml or any of the languages where AOT is considered the default.
> main issue is with the Java zealots
Any sufficiently large population will have someone who will literally say anything. And the common outrage trope on the internet is to rage against a straw man.
Now I haven't used GraalVM in production, but in having played around with it and doing new code from scratch, I found AOT compilation to be really good.
I think the change will come faster than you think.
You can build your leaf, domain level code into a native shared lib and still use the reflective code at the top level to compose the application.
https://www.graalvm.org/reference-manual/native-image/#build...
If Java gets CTFE (compile time function evaluation), constexpr for C++ folks, much of the need for runtime reflection would disappear.
There is no reason that JITed reflective code (along with VM) can't be combined AOT code in the same program. You can already do this in Graal via front ends for llvm-ir and wasm.
As it is now, you can already mix Rust, C, C++ trivially with bytecode via LLVM ir. And for languages that compile to Wasm, GraalVM has a front end for that as well.
https://www.graalvm.org/reference-manual/wasm/#embedding-web...
Any sufficiently large population will have someone who will literally say anything. And the common outrage trope on the internet is to rage against a straw man.
Now I haven't used GraalVM in production, but in having played around with it and doing new code from scratch, I found AOT compilation to be really good.
I think the change will come faster than you think.
You can build your leaf, domain level code into a native shared lib and still use the reflective code at the top level to compose the application.
https://www.graalvm.org/reference-manual/native-image/#build...
If Java gets CTFE (compile time function evaluation), constexpr for C++ folks, much of the need for runtime reflection would disappear.
There is no reason that JITed reflective code (along with VM) can't be combined AOT code in the same program. You can already do this in Graal via front ends for llvm-ir and wasm.
As it is now, you can already mix Rust, C, C++ trivially with bytecode via LLVM ir. And for languages that compile to Wasm, GraalVM has a front end for that as well.
https://www.graalvm.org/reference-manual/wasm/#embedding-web...
If Java gets CTFE (compile time function evaluation), constexpr for C++ folks, much of the need for runtime reflection would disappear.
Just to remind people that Quarkus has a "pre-compile" stage that allows code to wire itself up using reflection, annotations, config properties, etc, before the full compile. This makes start-up times much faster.
Just to remind people that Quarkus has a "pre-compile" stage that allows code to wire itself up using reflection, annotations, config properties, etc, before the full compile. This makes start-up times much faster.
Thanks for the compliment, I deliver software solutions in Java, C#, JavaScript, TypeScript, Swift, Objective-C, C++.
Hence JIT caches.
Slow startup from command line
Is sub 100ms not enough these day?
Sure... IntelliJ IDEA startup isn't instant. Atom's startup isn't instant. QT Creator's startup isn't instant. GIMP starts in a few seconds... etc.
Sure... IntelliJ IDEA startup isn't instant. Atom's startup isn't instant. QT Creator's startup isn't instant. GIMP starts in a few seconds... etc.
All free JDKs now offer AOT compilers and JIT caches.
Which is relevant for a server how?
This is on the comment thread of a tool to make client-side applications.
However, it's all besides the point because this tool takes Java (JVM) bytecode and translates it to WebAssembly, there's no JVM involved for end users at any point.
However, it's all besides the point because this tool takes Java (JVM) bytecode and translates it to WebAssembly, there's no JVM involved for end users at any point.
Yet we're all using Electron apps every day.
Slow is pretty relative. What’s your use case? Start up time is not as good as native, agreed. Arithmetic? Hotspot is pretty darn fast. Developer speed? A lot better than C/C++ at least.
I'll do a shameless plug of our modern Java benchmarking story here for the doubters: https://jet-start.sh/blog/2020/06/09/jdk-gc-benchmarks-part1
Throw away your preconceived notions -- TeaVM beat React at its own game.
* Faster startup
* Better Lighthouse score
* Less code
See for yourself: https://renato.athaydes.com/posts/comparing-jvm-alternatives...
* Faster startup
* Better Lighthouse score
* Less code
See for yourself: https://renato.athaydes.com/posts/comparing-jvm-alternatives...
Yes, xcode is the living proof how blazingly fast an IDE written in native languages is. /s
This idea of 'heavy' is very fuzzy, though I agree. Most of the slowness I encounter though is with specific frameworks, not the language/jvm.
I do sometimes use Go for its contiguous memory layout and await JEP 169: Value Objects from Project Valhalla.
I do sometimes use Go for its contiguous memory layout and await JEP 169: Value Objects from Project Valhalla.
> Most of the slowness I encounter though is with specific frameworks, not the language/jvm
Part of the problem is that those also happen to be the frameworks that the vast majority of the community uses.
The Java zealots also tend to ignore all of the problems associated with AOT Java compilers and the fact that it will most likely be a few years before value objects are finalized and in a released version of Java. Even then, a ton of Java developers won't be able to use any features beyond Java 8 or 11 since a lot of companies don't want to give up the ability to easily use their libraries on Android.
Part of the problem is that those also happen to be the frameworks that the vast majority of the community uses.
The Java zealots also tend to ignore all of the problems associated with AOT Java compilers and the fact that it will most likely be a few years before value objects are finalized and in a released version of Java. Even then, a ton of Java developers won't be able to use any features beyond Java 8 or 11 since a lot of companies don't want to give up the ability to easily use their libraries on Android.
https://news.ycombinator.com/newsguidelines.html