Since when is enforcing your legal IP 'anticompetitive behavior'? There is no EULA involved here, this is a contract where both parties have input. If MF didn't agree with that "won't reverse engineer" clause they could ask for it to be changed, and IBM in turn could have said "no deal". Refusing to provide your competitor with a product so they can make a competing version is not anti-competitive, it is just common sense.

We aren't talking about some hypothetical case, we are talking about a real case and that case was filed in US district court. US, not UK, law applies. There is zero chance that any challenge of venue would succeed. The whole case is about US law, and MF agreed in the contract that the contract is governed by the laws of New York.

I haven't "put faith" in either side. However, either the code was not copied, in which case the suit would fail in either the US or the UK, or it was copied, in which case the suit could succeed in either the US or the UK (because the UK law does not allow reverse engineering to make a clone). I'll also note that in the link you provided it says that reverse engineering is allowed if you have a LEGAL copy of the work. The only way to get a legal copy is by agreeing to IBMs conditions. If you want to say those conditions are not legal, then there is no contract and they still don't have a legal copy.

Maybe try reading the actual article (or even summary) instead of the click-bait headline. This has nothing to do with 'fan art'.

From the summary: the DMCA requests focused on images that "straight up used sprites and assets from [Nintendo's] IP," according to the SGDB admin. Nintendo's requests so far seem to have ignored "completely original creations" and "pure fan art" even when that art involves drawings of Nintendo's original characters

First, the suit is filed in New York, so UK law doesn't matter in the slightest. Second, even if it was in the UK, your own link says the protections for reverse engineering do not apply if you create a program 'substantially similar in its expression' to the copyrighted material. So yeah, you can reverse engineer CICS to make some program work with it. You can't reverse engineer CICS to clone it (which was what was done here).

What makes you think UK law matters in the slightest to The United States District Court - Southern District of New York?

They got the code to reverse engineer by signing a contract that said they would not reverse engineer.

The only 'argument' required is 'our copyrighted material used without permission'. Did you even read TFS? While the click-bait headline is written to make you think they are going after 'fan art', the reality is very different.

From TFS: Even for the Switch games in question, the DMCA requests focused on images that "straight up used sprites and assets from [Nintendo's] IP," according to the SGDB admin. Nintendo's requests so far seem to have ignored "completely original creations" and "pure fan art" even when that art involves drawings of Nintendo's original characters.

Well, at least you have backed off your very incorrect claim of what bytecode is. Now let's do the same thing for JIT. First, it is not a 'marketing term'. The JITC is a real compiler, doing all the things a 'real compiler' does. It starts with source (bytecode), determines what is actually being accomplished (by making graphs, etc), and generating native code to implement that in the most efficient way. And since the compilation is happening on the exact hardware that will execute it, the compiler knows about the exact capabilities of the processor and can use any and all applicable features of that hardware. This is not possible with what you call 'real compilers' - you must explicitly compile for each version of hardware to pick up new features.

Next, what you are trying to present as a 'problem' (recompiling) is actually a feature. It is not that the recompilation MUST be done, it is that the recompilation CAN be done. Because the compilation is done at run time, profiling information can be gathered, like how many times did we go down this branch as opposed to that one. Now you have the capability (again, because you are running on the actual hardware) of redoing how you decide to branch, for example, so that the most used path is going to have the least effect on the processor pipeline. If these conditions change over time it will just recompile to fit the new conditions. These sorts of on-the-fly optimizations are what allow Java code to outperform 'native' code in some circumstances.

JIT compilation is triggered after a certain (user-defined) number of invocations of a method. It happens in a different thread, and the original thread just keeps going with the interpretation. Any subsequent invocations of the method will also be interpreted until the JITC is complete. There is no way the JIT is going to be invoked 'multiple times per loop'.

JIT cache is not inexhaustible? Are you stuck in the 16-bit era or something? The default cache size is 256MB and can be increased if needed (this is for the IBM J9 JVM on z/OS, one of those 'UI and low performance only systems' you are always babbling about).

The reason I bring up emulation is because it demonstrates that whether a particular LANGUAGE is interpreted or compiled language is not dependent on whether it runs 'natively' or not. 'C' is a compiled language, whether you can run the resulting executable directly or not. Java is a 100% compiled language. If you had a processor that implemented the JVM you could run it natively. There used to be such processors, but JIT got so good it is not worth having special hardware anymore.

And oh, I am not 'the younger crowd'. I have been developing in-house, heavy-duty large applications for very large companies for 42 years. That development used to be predominantly COBOL, but now is Java. A quick search shows many job openings for mainframe Java developers. Those jobs are not developing 'UI and low performing phone apps'. Sorry to burst your bubble.

They do publish the legend of what colors mean what. In this case, the assigned colors are: Blue: F200W, Green: F335M, Red: F444W, Orange: F470N

https://webbtelescope.org/cont...

Your ever so condescending description of bytecode tells me all I need to know - you haven't got a clue. 'A form of run-length encoding'??? Seriously? Bytecode is NOT 'a compressed form of original source' (like C64 basic tokens were). The JVM is a stack-based abstract machine, with things that a real machine has, like storage and an instruction set. The instruction set contains the things you would expect to find in an instruction set - loads, stores, branches, call, return, push, pop, arithmetic, logic, etc. The compiler, like all compilers, translates your source code into a series of machine instructions. The 'machine' in this case just happens to be the JVM.

Now, is the JVM your native machine? No. So to convert the bytecode into native instructions the JIT COMPILER is used. Yes, this happens at run-time so adds some overhead, but it only needs to be ONCE per method (until the JVM is restarted). Since we are discussing business software running on servers, a restart of the JVM happens very infrequently. Thus, there is almost no overhead to using Java in these types of applications (which is why so many businesses do it).

Suppose you have a mainframe emulator like Hercules. And on that emulator you run some C (or COBOL) program. Was that C (or COBOL) program compiled? According to your bizarre logic, no.

I guess COBOL, FORTRAN, PL/I, etc aren't real boys either, because no kernel contains a stitch of them either.

Do you also deny that much 'real business' software is/was written in COBOL? How much COBOL do you see in open source software or 'in trhe wild'? And here is another clue for you - mainframes have special instructions (implemented in hardware) to do things like enable pause-less garbage collection for Java. They also have special instructions for things COBOL does. Why? Because the vast majority of software running on these machines is either Java or COBOL. And nobody is using mainframes for 'quick and dirty niche jobs' or 'front-end UIs'. Face it, you have no clue about 'real business software'.

https://www.ibm.com/support/pa...

Compiling is translating one language to another. Often this is something like C to assembly (not 'native code'), but Java to bytecode is just as much compilation as anything else.

Wait, a network failure is an 'inconsequential thing'? I guess when you write code you use the theory of just ignore failures?

Java is compiled. You wanting to pretend it isn't doesn't make it so.

Most business software that is written in Java is in-house developed by the companies using the software. The fact that you don't know this (and thus ask for 'widely used' software) goes to show you know nothing about business software, or the companies that use it.

Never gonna happen, except maybe in niche products. Consumers don't care, and corporations want their systems to be remotely/automatically updateable.

Collusion is 'illegal or secret agreement to cheat or deceive others'. Your 'the reasons stated are legal' doesn't matter. You absolutely should win.

Kicking the vendors off isn't the issue. The issue is the collusion between Apple and Amazon to do that in order to raise prices.