The "business grounds" were Sun suing to stop Microsoft from distributing their JVM clone. Sun claimed Microsoft's enhancements made the J++ machine non-conformant and a copyright infringement. Microsoft chose drop the product rather than fight about it..
The only "hubris" on the part of Microsoft was daring to make their JVM better than Sun's.
Yes.
COM+ was an internal project name that shipped as COMv2 with DCOM. The COM+ name was repurposed to refer to the distributed COM protocol rather than the implementation.
The connection to transactional services came later.
It seemed fairly apparent at the time that Microsoft tried to follow their traditional "embrace, extend and extinguish" strategy in order to force the open, portable, standard Java off MS-Windows platforms and replace it with a Microsoft-owned "MS-Java" limited to MS-Windows platforms.
According to Wikipedia
formatting link
Microsoft did not make a "better JVM", they removed the Java Native Interface (JNI) and replaced it with their own "J/Direct" interface, harming the portability of Java programs between MS-Windows and other systems. Further according to Wikipedia, there were two lawsuits against Microsoft over this issue, for which Microsoft paid over US$2 billion in out-of-court settlements.
I can't agree with that assessment. The reasons C# exists in spite of the previously available Java clearly never had anything whatsoever to do with computer language design or compiler technology. C# was not initially designed at all; it was cloned from Java strictly for reasons of business strategy. MS has always been afflicted with a really bad case of NIH (not invented here) syndrome, so when Java started to feel like one of the symptoms of that, their attempt at a cure was C#.
As to language design principles and goals, perhaps the shortest explanation of Java's (and thus, by cloning, C#'s) primary concept is "C++--". I.e. they took C++ and removed or at least downsized its more problematic constructs. Most prominently multiple inheritance was boiled down to the "interface"/"implements" construct, some of the legacy C semantics thrown out, and platform dependencies were moved from the language into the VM.
In a comparison between C# and Java for embedded usage I see Java several steps ahead. Java's "Micro Edition" and "Java Card" sub-sets at least exist and have some kind of an ecosystem to them.
If you look at the original Java whitepaper, it is /extremely/ clear that Gosling looked at and understood a wide range of computer science theory and practice, and selected just the right set of features that "play well" with each other.
That whitepaper, the clarity of its vision and exposition, was the reason I (and others) rapidly jumped on board the Java bandwagon.
I looked at Java Card 15 years ago, and it is such a small subset of Java that it is as similar to Java as JavaScript is to Java. In addition the execution environment is so (necessarily) limited that there's no real benefit to having Java.
It's a useful enough subset for its intended applications, such as payment cards.
The main benefit compared with earlier systems was the security model, which allowed applets running in the cards that were isolated from each other and whose communication to the outside was controlled by the communication object passed into the applet. There was some formal verification work done on the security model iirc.
Just so. But the security model (the only "interesting" bit of Javacard) isn't specific to Javacard. ISTR there being other languages for programming smartcards.
Aside: I'll _contend_ that the only useful thing that can be stored in a javacard is a magic number. When the card is used, that magic number is transmitted to a server, and a database defines the number allows. Corollary: there's no need for complex on-card logic.
There are many javacard applications including pki tokens, payment cards, and a few billion phone sims. Most of them involve 2-way communication and crypto.
Typically user credentials including a cryptographic signing key. The key has to be encapsulated in the card so it can't be copied. It's instead used to sign a challenge presented by an external device. For example, smart cards are used to authenticate some cable TV set-top boxes. If you could duplicate a card, you could use the second one to watch cable shows without paying.
There was a huge technical arms race between cable TV companies and cable pirates where pirates developed more and more sophisticated ways to copy cards, and card manufacturers designed progressively fancier countermeasures. Smart cards now have all kinds of obfuscation and tamper-resisting features to prevent extraction of the keys in the card.
Whether the server is local or remote is uninteresting in this context. /Neither/ requires sufficient on-chip logic to make Java worthwhile. The JavaCard app is so small that it would be easy to write in assembler!
Any support environment implementation would only be written once, by the card manufacturer, and could be written in any convenient language.
So yes, the security aspects of JavaCard are beneficial, but they are scarcely a killer advantage.
Actually I would say it depends on the systems architecture. C# is a decent GUI language. If you then assign the hard real time features to low level controllers (device drivers &/or micro controllers like Arduino), you can build a decently robust system.
True, but surely a different magic number (derived from the hidden magic number) /is/ transmitted. The derivation is not sufficiently complex to benefit from having Java in the card: either there is hardware assistance or it is highly optimised assembler.
Which brings us back to the question of whether there is any processing in the card that is sufficiently complex to warrant Java or another OOP+libraries.
On 06/11/16 22:59, Tom Gardner wrote: > Aside: I'll _contend_ that the only useful thing that > can be stored in a javacard is a magic number. When > the card is used, that magic number is transmitted > to a server, and a database defines the number allows. > Corollary: there's no need for complex on-card logic.
Whether the server is local or remote is uninteresting in this context. /Neither/ requires sufficient on-chip logic to make Java worthwhile. The JavaCard app is so small that it would be easy to write in assembler!
Any support environment implementation would only be written once, by the card manufacturer, and could be written in any convenient language.
So yes, the security aspects of JavaCard are beneficial, but they are scarcely a killer advantage.
Wait, you were the guy saying C++ is dangerous and now you're saying to write critical security applications in assembler? :-O
What does "sufficiently complex" mean? If I have to write a hello world program I have no trouble using C++ or some other huge language for it. Is C++ "warranted"? Probably not, but using it doesn't cost me anything, so what the hey.
Similarly, Javacard is a fairly simple bytecode interpreter and virtual machine. The interpreter consumes some program rom on the chip, and there is some ram overhead for the applets and their data, but it's not that big a fraction of the chip cost.
Part of the Javacard vision (I don't know how much it caught on, but it gets at least some use) was to have multiple applications on the card, that can't access each other's data. Assembly code would be able to get at everything in the card instead of just that application's data. You need some kind of application sandboxing and the Java applet model works nicely for that.
That locks you in with that card manufacturer, while you can move your javacard code around between cards easily.
Please read what I wrote. I did not suggest writing the /application/ in assembler.
Frequently the crypto routines are written in highly optimised assembler (even if that optimisation is done by tweaking the C and compiler flags, and examining the object code :) ) That's not a problem since all aspects of the algorithm are well defined and the algorithm itself is simple.
Those characteristics mean writing the crypto routines in assembler is very tractable and often beneficial.
Having said that, my suspicion is that the /applications/ on JavaCards are so simple that they /could/ be coded in assembler - but I wouldn't push that point. It could be easily countered by outlining an application that was /necessarily/ too complex for that to be reasonable.
Sigh. Please use some common sense about what "sufficiently complex to warrant" might mean. Hint: a googling leads to the first definition of warrant as a verb: "justify or necessitate (a course of action)."
I agree with that assessment. I would be interested in whether there are any real-world cases of multiple applications for different corporations on the same JavaCard.
Different corporations is necessary, if you think about it.
Yes, in theory. I wonder how often that is a benefit, in practice.
The Java applets on the card are what I mean by the application. It does things like manage PKI credentials, etc. I don't know if phone contacts on sim cards are usually implemented with applets.
Yes, crypto primitives are done with assembly code and/or hardware accelerators on the card. Your Java applet can them through appropriate interfaces.
I think you have a picture of these applets being coded by the card manufacturer. But it's usually the client application developer who codes them. Who expects to expect them to progam the cards in assembler? Java makes life a lot easier even if assembler were feasible.
PKCS11 token, one of the driving applications for javacard. Spec is linked from here:
formatting link
The "base" spec is a 150 page pdf and then there's some extensions in separate documents. There's a ton of code involved. But, I don't know how much of it has to be on the card itself.
G10 also offers PGP/GPG key management smart cards.
These cards run complex protocols--they're not just running some number through AES and sending back the answer.
I certainly think using Javacard is justified when faced with the much larger hassle and vulnerability surface of using assembler. That is true even of very small applications. The payment card and mobile phone industries use billions of javacards for a reason, not because they were hoodwinked by marketing crap.
Payment credentials for more than one bank account or credit card.
If you prefer BASIC, try basiccard.com. I have some of these. The cards aren't as flexible but the dev kit is cheaper.
Oh yes indeed; I use assembler as an extreme - which I suspect would be practical (even if not desirable!) for the simple apps I /imagine/ being on a JavaCard.
I'd welcome use cases of apps with complex logic, where the same end result couldn't reasonably be achieved by simply passing a magic number to a server.
I certainly haven't got time or inclination to read that!
A /quick/ skim didn't indicate compelling use cases, let alone for complex logic in the JavaCard.
As I said, examples would be welcome.
Oh yes indeed. But convenience is one thing, necessity another.
Only if from different companies (e.g. banks). Multiple accounts with the same institution can be dealt with by a single magic number.
After all, when Javacards aren't involved, I simply login to a bank once, and then fettle with all my accounts in that bank simultaneously.
OK, if I argue from one extreme, I can't complain if you use others :)
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.