Here is the cost of JavaSE subscription. Not sure how to feel about this.
Am I reading this right that using java SDK is no longer free?
So jre is still free for now but anyone using java SE 9 or higher has to pay if you make money.
as I understand it, the Oracle SDK will not be free anymore, but there are alternatives. As far as I can tell it doesn’t directly effect any of us using what we use now, but in the future if you want the newer java releases you’ll probably need to use a different sdk. Someone correct me if I’m wrong.
That’s how I read it except for the server stuff. I am not sure if that is straight off pay to play. If it is, jme will be affected sooner or later.
you have openJDK, what else do I need yo develop on java?
OpenJDK will remain Open. I’ve switched my home servers to Zulu a while back and have had no issues at all. So that is worth a try if you like to use another build than Oracles.
Exactly… I do not read this as having any notable implications for jME, open source Java, or anyone else who for any reason might not want paid Java support. In other words, I don’t see any downsides here (long or short term), and a few possible benefits. In the document linked by @iamcreasy they specifically mention using OpenJDK if you don’t want a subscription license or if you would not benefit from their support. What they’re really selling here is support aimed at enterprise developers/admins, including support for releases that are past the OpenJDK support dates. I don’t see any downsides here for us or developers in general, especially since they expressly mention making the Oracle JDK fully compatible with OpenJDK (which it basically has been for the last several releases). There could be a benefit for OpenJDK users as a result of this too - Oracle will likely successfully monetize Java support with this move, which could very well have a trickle-down effect into OpenJDK. Also keep in mind that Oracle is not the only controlling party involved in OpenJDK… if I’m horribly wrong and Oracle does do some nasty lock-down of future versions of Java, I fully expect the existing OpenJDK to fork and continue on under the guidance of the Eclipse Foundation and Red Hat (basically what already happened with Java EE).
What hosting service do you guys recommend?
Reason I ask is I see no options on the service I was going to use that allows this. It uses SE.
I’m assuming that’s a hosting service to run your game server? As long as you target JDK 9 or newer you can use the JDK provided
jlink tool to totally avoid this. It lets you build your application + a minified version of the runtime + VM specific to your app/platform that’s entirely self contained. Use OpenJDK to build that image, run it on your hosting service, and you’re golden. No Oracle subscriptions/shared runtime version/other licensing issues.
This is starting to turn into a nightmare with the tax law changes just enacted by the Supreme Court (created out of thin air) added to this crap.
Jme SDK will continue to use the free version and build the dist assuming free use so its a no go for commercial use?
I should now install openJDK. I use netbeans for ide can it be set to use openJDK just by pointing to it from libraries/manage platforms or will I need to use a different IDE?
I found a VPS site that allows for openJDK,
Anyone had experience with these people?
Sorry to sound negative but after reading the install for openJDK I now would also have to install even more programs just to use the openJDK, gnu tools. On top of this I am going to have to install netbeans from apache eventually so this is starting to get real stupid guys. How many hoops should one have to jump through just to use java?
Why not just move to C# instead?
I’m not super concerned about this particular development for the game industry (although in general I’m not at all a fan of the ruling). For one, sales tax traditionally applies to “material” goods (I’m not sure if online software downloads are counted in this or not), not online virtual goods. I also don’t believe that taxes for online “services” (i.e., gaming subscriptions) are sales tax, and I also don’t know if gaming subscriptions are taxable or not - it may depend on your particular state of residence/business. This is definitely a huge issue for Amazon/eBay/Etsy/Anyone shipping goods purchased online across state boundaries, but I’d be surprised if it affected the game industry beyond possibly making the purchase of games on Steam/etc. taxable events. This isn’t an area that I’m very well versed in, however, so take everything above with a grain of salt.
I can’t speak to what the Jme SDK will continue to use, but I think this is incorrect. The subscription stuff seems only to apply to (a) support, and (b) “commercial” features/extra tools provided by Oracle. Keep in mind that Java has always had a very strong separation between the development environment and the runtime environment (“write once run anywhere”). If you develop on the free version it’ll run identically in the commercial version and if you develop in the commercial version I do not believe that there are any license encumberments that prevent you from running the binary in the free version (that would be an extremely drastic license restriction that would sink Oracle’s profits on this - people are often afraid of the GPL, but that’s 100000000x worse for any developer, commercial or otherwise). At any rate, the only difference I see with the subscription Java SE release is that you get lots of extra support and a few extra tools. I don’t think this means anything drastic for developers at all.
I don’t use Netbeans so I can’t specifically help with setup, but you’ll definitely be able to use OpenJDK with Netbeans. Oracle and OpenJDK are virtually identical - Oracle just has a few “bonuses” built in that I believe are fairly niche and inconsequential for most developers. I use OpenJDK all the time without issues (The Oracle JDK binaries on my machine aren’t even used by anything else on my machine right now - I could uninstall them without any effect). The VM & class library in the Oracle release are the exact same VM & libraries you get through the OpenJDK download. Unless you’re using the Oracle extras, they’re functionally identical (and have been for some time).
I’m not sure where you’re getting that from - you might need that to compile OpenJDK yourself, but I’ve never encountered such a thing just to install it. More information about your setup would be helpful.
Most developers already have a favorite IDE that isn’t developed/supported by Oracle. I don’t think Netbeans has a large market share right now, so it’s not a surprise that Oracle transferred the project to the Apache Foundation (it’ll probably get a lot more love there anyway). For anyone using Eclipse/IntelliJ, installing an IDE totally separately from the Java install is a completely normal fact of life anyway. This really isn’t a substantial burden on a developer (and as I indicated above, I think Netbeans users will probably benefit from this move quite a bit in the long run).
There really aren’t any hoops added by this. You need the same thing you’ve always needed: a Java SDK (i.e., a build of OpenJDK that could be Oracle’s Java SE release, an Oracle OpenJDK build, a Zulu OpenJDK build, a totally independent commercial Java SDK, etc.), and your IDE of choice (skip this if you’re fine with a text editor + command line). Having developed with a lot more than just Java (C++,C#,Python,Node.js,etc.) this is as painless as it gets. Literally no other project can possibly beat that unless they bundle an IDE + runtime together (which has all its own snafus too).
The best news too is that with the modular JDK and
jlink you can build 100% standalone distributable applications. The user doesn’t need Java (of any sort) installed on their machine, and they don’t even need to know your program was written in Java. It’s not substantially different from compiling and distributing a C++ program (except that you get to write in Java instead of C++ - yay! ). This makes compatibility issues virtually nonexistent, eases maintenance burdens, and assuming you’re using an OpenJDK build then licenses are a non-issue.
I have to write C# at my day job and I can give you a list… a very loooooooong list.
I’ll reduce it to a few big points that I’ve hit though:
The C#/.Net ecosystem are about 10 years behind Java. Pretty much your only tool options are Visual Studio (proprietary Microsoft IDE) or Visual Studio Code (open source glorified text editor) + command line tools. If you’re developing on Linux, Visual Studio Code is pretty much your only viable option right now aside from a barebones text editor + command line tools (Eclipse is working on a C# plugin, but it’s very young right now and I haven’t been successful in getting a remotely functional install). Compare that to a wealth of well established, open source, and cross platform Java tools and you see what you’re missing out on.
In addition to the IDE issues, good open source libraries tend to be hard to find. Java is extremely well entrenched here - name any task you want to do and there are probably 2-3 or more mature, well-supported open source libraries that do it. In C#, you’re lucky to have 1 library, and many of those are supported by single developers. Java’s open source library ecosystem is eons ahead of C#'s right now.
The C#/.Net ecosystem are very fragmented at the moment. A few years back your only options were the official Windows-only proprietary Microsoft .Net Framework and Mono (which tended to lag behind the official release in library support/features). A couple of years ago Microsoft decided to remedy this by starting with a clean slate and developing a new .Net specification + open source cross platform runtime called .Net Core. The good news about this is that you can at least build and run .Net applications cross platform in a well supported manner (without the works-on-.Net-but-not-on-Mono issues), but the bad news is that library developers must explicitly target .Net Core (with some hefty restrictions on what libraries can be used). The result is that library developers often have to support both .Net Core and the older .Net Framework in the same library, and while things have substantially improved in the last year it’s not uncommon to find a library that only supports .Net Framework (which is still Windows-only). Libraries are also often drastically less portable between versions than they are with Java (you’ll have to target only very recent .Net Core versions or your library dependencies are going to support only newer versions - and your program won’t even compile, let alone run, until you resolve this). The only bright side here is that similar to Java’s
jlinktool, .Net Core can build a standalone, distributable package that can be run on the target machine without any dependencies or extra installs and without the user ever installing anything .Net related.
Minor detail and entirely one of personal taste, but I find C# code to be pretty cludgy compared to Java code. C# is more complicated a language than Java is and while there are some perks to that there are also downsides and quite a few more “gotchas” and places for language feature abuse than Java has. I find Java to have a very good balance of simple, clean language design and advanced features. C# “feels” a lot more like something that got slapped together than an elegant and consistently designed language that effectively balances power with opportunities to shoot yourself in the foot. Plus, with no checked exceptions, writing production-grade C# code with proper error checking is a major pain in the backside (and in some cases just isn’t possible until you’ve deployed and gotten some weird exception that you just didn’t have any way to anticipate and guard against).
My bottom line is that as far as developer experience goes for both languages + ecosystems, Java’s a well-kept Mustang and C# is more of a rather aged Taurus with quite a few dings and scrapes and pesky mechanical issues. At the end of the day you can reach the same destination, but one will get you there painlessly after a fun ride and the other will get you there with a few headaches, I-hope-I-make-it-up-this-hill moments, and maybe a stop at a repair shop or two.
This General Public License does not permit incorporating your program into
Taken directly from the GPL License. If you ship OpenJDK to with any program, it gotta be under the GPL too.
This means that the source code HAVE to be available.
This would be the case if OpenJDK were under the standard GPL, but it’s not - it’s under the GPL with the Classpath Exception. The Classpath Exception means that the GPL only applies to the original program, not to other “independent modules” that are linked to the original program and that run as a different, “non-derivative” program. In other words, if you modify the OpenJDK standard library and distribute this modified version, you must provide the modified code under the GPL. If you link the OpenJDK standard library into a standalone program along with your own code, you’ve linked to separate modules to create a different product and your code has no license restrictions whatsoever. Lots and lots of folks use OpenJDK outside of standard open source territory, and they can because of this exception.
jlinking your code + OpenJDK modules into a redistributable runtime image doesn’t make any difference here.
This is well-plowed territory, and it’s safe.
Win 7, see my name icon for setup.
I thought I was going to have to install md5 checksum, which is outdated and unsupported and I absolutely hate installing a chain of programs to make something work.
After searching the net I found windows has a built in utility called certUtil I can use instead.
I also checked out c# and found that what you are saying makes sense. I agree with your car assessment. I also re-confirmed that everything except jmonkey is worse than a nightmare, its more like night terror.
On a side note, I am kinda excited about the jvmhost.com site since it looks very scalable. Definitely looks belter than what I was planning on using.
I am going to bite the bullet tomorrow and try this out.
I can totally relate to your assessment on C#. I also need to do that on my day job. And I could add the documentation to the table also. XMLDoc is virtually non-existent vs javadoc on methods and classes, at least on the .NET classic, I doubt it is better in the Core. Then you are pretty much forced to go MSDN, while there is more, usually basics like algorithmic complexities are not mentioned and class name doesn’t usually implicate the implementation used so you can’t deduct this either (collection types).
Java SE Advanced, Java SE Advanced Desktop, and Java SE Suite products have transitioned to a Java SE Subscriptions
No info that regular JDK usage (commercial and non-commercial) requires a subscription. As I understand nothing has changed for us actually.
Yeah, manually installing dependencies is a total mess. What’s the use for the md5 checksum? If you’re working with SSL certificates then anything you need should all be built into the JDK or would come from an external standard SSL utility.
I’m curious to hear how you fair there… although I’m a bit skeptical of its usefulness for game servers since their front page offerings are much more related to servlet/enterprise uses. You don’t technically need a Java specific host for running a game server - any old VPS (virtual private server) will do. You can either install a JVM on your VPS or… wait for it…
jlink a self-contained runtime image, upload to your VPS, and run without ever managing any external installs.
I haven’t paid much attention to that sort of thing though, so I wouldn’t know if they have extra perks for using a host-provided JVM over just installing your own JVM/software on a plain ol’ VPS.
Yeah, that’s totally been my experience… very poor documentation on many of the libraries, and good luck getting much detail out of MSDN.
Good catch - I haven’t read any of this stuff in great detail, but nothing that I read indicated that standard developer usage would be altered. At any rate, the more money Oracle makes on commercial Java support the more they’ll reinvest into OpenJDK and the Java ecosystem.
So looks like this is purely an “extra cost option” offering extended support for commercial users of Java.