[1] https://en.m.wikipedia.org/wiki/Java_Card
[2] https://superuser.com/questions/362567/are-there-any-credit-...
[3] https://www.oracle.com/java/java-card/
All of this is just as easy as, if not easier than, using ChatGPT. It's unclear that such a tool even serves this purpose (retrieval of basic facts) adequately, so it should probably be avoided in the future.
(fwiw I have a bit of prior experience here)
Even fully passive NFC tags contain logic that needs power to talk NFC back to the reader, there’s no such thing as just reading data via NFC.
You know those 4 lights on a contactless card reader? They indicate different transaction stages between the card and the terminal. I don’t find them that useful because it’s so fast they all appear to light at the same time, but that’s what they are!
https://www.cardlogix.com/product/cardlogix-credentsys-lite-...
And on another source:
Visa became the first large payment company to license JavaCard. Visa mandated JavaCard for all of Visa’s smartcard payment cards. Later, MasterCard acquired Mondex, and Peter Hill joined as their CTO, licensed JavaCard, and ported the Mondex payment platform to JavaCard.
Source: https://javacardforum.com/2022/07/28/the-birth-of-javacard/
It's almost bizarre what that thing does.
Though mind you, it is a very limited subset of Java, not the standard one.
respect yourself enough to look at primary sources
It didn't help any that it was clear from the initial post you were questioning someone with domain knowledge, which was later gently indicated to you
Engineering is all about tradeoffs, and ‘works’ is pretty high praise frankly.
Ideological purity is rather subjective, and has an unfortunately poor track record of real world success.
And perhaps proposes a concrete alternative that matches those constraints better?
Don't forget to include things like long term support, developer time, interoperability, etc.
Kind of, yes. Since instead of evaluating based on an understanding of the technology you're saying "In this universe was chosen for a project, the project was successful, show me the universes where the alternative decision was made".
I'm saying that if you think something is crap and doesn't meet customer needs, at least propose a concrete alternative you believe is better so someone can respond meaningfully! Or concretely what concrete needs are not being met!
Currently, we have one example of something that all evidence leads us to believe fits the universe as it exists, at least in that specific niche.
If you think it doesn't, how doesn't it? Or if you're saying there is something better, are you saying that is hand written assembly? Or TurboPascal? Or ADA? Or some as yet not designed system?
I'm not asking for an alternative universe. I'm asking you to support your statement with enough details it can be assessed in the current universe.
You: If it is the convenient alternative than it is a good choice
Me: That is a bad justification for something being a good choice
You: What criteria then?
Me: An understanding of the engineering principals/ domain
Am I accurately summarizing this conversation so far? This isn't about alternatives, or what else they should have done. Something can be a bad fit and the right choice.
As an example, I could say "Java dominates that section due to historical artifacts of business, not technology. Java is a bad fit for this type of work otherwise because of the complexity involved in implementing a Java VM in hardware". I can then also say "Java is the only real choice because of those historical artifacts so I have to recommend that you use it unless you're willing to build your own hardware from scratch".
I actually don't have to propose any alternatives at all, hopefully you can see that - we can just evaluate Java as a language (complex VM, assumes a heavy runtime) against the constraints (custom hardware, low energy) and see that the fit is weak. Obviously people overcame that and made it work, and because of that Java is the obvious choice for this technology.
In that scenario, it's literally the best possible fit.
That you don't have any viable better alternative at hand may be further evidence of that? (and I don't mean from a standards basis 'well, it's locked into financial rules now, so gov't intervention'). I mean, what else was going to work considering all the factors involved? What else could work better, considering the factors involved?
JavaCard is in fact so widely used and implemented (SIM cards, bank cards, health cards, passports, etc.) that it probably has literally 10's of billions of devices manufactured using it (3.5bln claimed as of 2010 - https://www.oracle.com/technical-resources/articles/javase/j...), in essentially every high value target rich environment niche you can think of, and at extremely low costs. Literally sub-cent per-item.
And with very high environmental stresses (like debit cards getting sat on, left in hot cars, run over, dropped in puddles, jammed into random dirty readers over and over again, etc.), those devices keep working.
And everyone from random countries gov'ts to random financial firms to telcos have managed to implement what they need in it without too much difficulty, and a minimum number of security issues. Which is frankly astonishing if you've ever dealt with folks like that.
So love or hate Java, or JavaCard from a stylistic perspective - any perceived complexity for implementing a Java VM in hardware has had no practical economic effect, or slowed down implementation meaningfully.
It's fit for purpose.
Probably also ugly and feels gross using them sometimes, but a lot of fit for purpose stuff is until you've experienced the alternatives. Hopefully you never have to fix a sewage lift station pump, or clear a clogged sewer line, or clean out a transmission after it's burned out.
Each of these has literally hundreds of years of specialized knowledge and expertise behind their often boring looking facades. They're all amazingly complex if you learn about them. And they're all better than throwing sewage in the street, or carrying everything on horseback. And they're beautiful in their own way when you appreciate why they are how they are.
Even if they're not shiny and flashy, there is beauty in them, because they work well.
And they're still amazing engineering marvels, necessary for our lives as we know them and based on the actual engineering principals involved and the problem domain.
So we fundamentally disagree.
> has had no practical economic effect, or slowed down implementation meaningfully.
This goes back to my "to prove me wrong you have to show me alternate universes where other options had that investment made under the same circumstances".
This is an assertion that can only be disputed with an alternate universe.
Notice the difference?
To propose alternative solutions based on practical economic effect just requires a reasonable degree of comparison to projects of similar scope at other times, reports of difficulty from various vendors, and comparisons of end price for this solution, end price for other solutions of similar scope, to the overall scope of the solution and value it brings. None of which requires perfect alternative universe A/B testing to come to some reasonable analysis.
If another solution could be done for half the price (say $0.005 per unit, instead of $0.01 per unit) but the perceived value for vendors is $1/unit - then it's hard to say there is any practical economic effect going either way. Neither solution would block profitability or value. That said, they could easily be compared and better/worse solutions could also be determined or tradeoffs analyzed based on that data, also without perfect alternate universe A/B testing to come to some reasonable analysis. Industry does this all the time at scale, including projected costs of implementation of various solutions.
If the solution was rolled out within a timeframe considered useful/expected for this kind of solution, then it also didn't slow down implementation meaningfully - as in it didn't block it, or add serious delay. If there is another solution which could have been done in half the time, that's cool. But it wasn't required.
Doesn't mean they wouldn't have been better solutions, and proposed them as alternatives can easily be done without parallel universes! In fact, chances are they have already been implemented somewhere in another niche, so there is adequate data to do so.
No.
> If the solution was rolled out within a timeframe considered useful/expected for this kind of solution, then it also didn't slow down implementation meaningfully - as in it didn't block it, or add serious delay.
Also no.
JVM wastes cycles on things like classes, which is not necessary at all. Going forward, Rust has already proven that you can do things at compile time to guarantee things like memory safety.
ART also compiles to native since Android 5.
Android 14 is around the corner, time to keep up with the times.
Does it always make sense? No. But clearly a bunch of folks have found it valuable in many niches.
32 bit 4mhz processor with ~64kb of nvram all running off of an induction charge!
https://source.android.com/docs/core/connect/esim-overview?h...
I think the e-sim idea is probably a net security benefit imo, apple has leveraged the carriers out of a fairly dangerous tool.
https://www.youtube.com/watch?v=31D94QOo2gY
Recently I was thinking about what a program written to take advantage of Optane's persistent-memory model would have looked like, if you use it like RAM it's forever gonna be slow shitty RAM. Javacard seems to be the closest hit for that, in some ways. Maybe some of the higher-tier javacards have GC.
I guess at that point it's basically a JVM application state snapshot, which is the same thing, so maybe not any better.
When I think about a "Java OS", I imagine a JVM running in kernel mode, providing minimal OS functionality (scheduler, access to hardware I/O ports) and there not being any kind of userspace.
While Android isn't proper Java, converting JVM bytecodes into a better format for embedded deployment is quite common on embedded world.
PTC, Aicas, Gemalto, microEJ, WebSphere Real Time, Aonix,....
Current Java OS as per your definition, would be PTC and Aicas real time JVMs for bare metal deployments in embedded scenarios.
IMAO, Android kind of achieve that...kind of. They write lots of OS logics in Java (or Kotlin) but mixing lots of system services written in native code at the same time, interconnected by the famous (or infamous?) Bind IPC.