Posts by waynec

T-Mobile USA: DON'T install Apple's iOS 10, for the love of God

What about iPhone 6s?

Presumably this isn't a problem with iPhone 6s on T-Mobile. I have one and updated to iOS 10 and haven't seen any problems yet.

Why Microsoft's .NET Core is the future of its development platform

.NET Core is not yet ready for prime time

We did an analysis of our product to see whether it would run on .NET Core, using the available ApiPort tool: http://jnbridge.com/blog/why-we-cannot-yet-support-net-core. We weren't surprised that our own stuff wouldn't yet work on .NET Core (as the article says, migrating existing .NET applications to .NET Core is likely to be difficult, if not impossible), but looking at the unsupported APIs, I'd be surprised if many non-trivial, enterprise applications could be created for the new platform. We can only hope that will change, and the number of missing APIs will go down over time, but that remains to be seen.

Devs ask Microsoft for real .NET universal apps: Windows, Mac, iOS, Android

Universal apps would be a great thing, and Microsoft should be commended for going in that direction, but some of their efforts are not yet ready for prime time. Earlier this year, they announced Project Centennial, to support migration of Windows desktop apps to Store apps (and from there to universal apps), but we've since heard nothing.

As for .NET Core, it's currently missing a host of APIs that any serious enterprise application would need. Perhaps they'll eventually implement these APIs, but I'm not holding my breath.

'Silent but deadly' Java security update breaks legacy apps - dev

Some responses

Hi guys -- I wrote the blog post that John (the article's author) cited. This is a great discussion. I just have a couple of comments on some of the comments here.

Our product does handle Java 7 (and 6, and 5, etc -- our stuff works with Java back to 1.3.1, although we'll probably move that up to Java 5 in the next release) just fine. But it's a tool that customers use to run and deploy their own software -- it allows .NET code to communicate with Java code. The Java runs in its own JVM, and the users get to choose whichever JRE they want -- it can be any version, it can be 32-bit or 64-bit. It can be be from just about any vendor. That's a good thing, because our users have their own environments, and it's their own business -- we don't dictate or judge. So, the problem isn't ours (we're not making people use Java 6, as some people say -- but our customers might choose to use Java 6), except that our customers' problems become our problems, and then we have to scramble. But it bothers me when we have to scramble to solve a problem that really wasn't caused by us, and which really shouldn't have been a problem to begin with.

Someone mentioned we should use the registry to choose the Java that we use. But that only tells us what Java is on the machine -- it doesn't tell us what Java the user wants or needs. Again, we let the user make that decision -- checking the registry won't tell us what we want to know. (Nor will JAVA_HOME, as someone else suggested.)

As for why any enterprise customer would allow auto-updates... the answer is that they shouldn't. But clearly it happens -- it happened to the customers of our customer. (Our customer is an ISV that uses our product. Their customers are the end users.) And when it happened, our customer heard about it from their customer, and called us, and we had to scramble, and the problem was easily corrected, but it shouldn't have been a problem in the first place, as someone mentioned.

As for the comment about why we don't supply the jvm.dll -- first because it should be up to our users to determine which version we need -- we can handle just about any one chosen and don't dictate. Second because jvm.dll doesn't work in isolation and we'd have to supply an entire private JRE -- it's much more than a single file.

Finally, I just want to point out that in our case, the problem is just the validity of a file path -- Java 6 and Java 7 reside in different places, and a single path won't work with both. However, this discussion has certainly come up with plenty of examples of Java software that works with Java 6 that simply won't work with Java 7.