The two most popular, if not the only versions of Minecraft, Java and Bedrock. Java being around 8 years old, and Bedrock being about the same age as Java. The two have their differences and their similarities but which version is truly the best version money can buy? Java gets more features while Bedrock has all the features of Java, and less. A popular example of this is the Combat Update which brings a more realistic combat system to the game while Bedrock just has unrealistic combat in which you can spam a mob with a sword to kill it quickly. But unlike Java edition, Bedrock is more optimized for Windows 10 devices. In Bedrock edition, you can set the render distance higher and fly with less lag, where as with the highest setting on Java, there is some noticeable lag. Yes, Java edition has it's flaws, but so does Bedrock. So which version do you guys like more?
I'll put my answers this way after having a bit of time with Bedrock/Console and mostly Java experience.
Performance = Bedrock
Mod/Datapack/Behaviour Pack Support = Java (Bedrock's is just beginning so it's fair to say, no clue about how Pocket Edition's prior fits in with Bedrock I assume it isn't the same support).
Resource Packs = Java (Bedrock is good for options but I'm not a fan of the marketplace besides what good it is for devs of those I just like Java's way).
Movement/Gameplay = Tough to say, I like Java's before and with the combat update. The combat after 1.9 really doesn't bother me using a shield to deflect and a sword/axe to take on mobs I like the idea even for how in-depth that is it to make critical attacks count but sometimes the shield holding when I'm low on health isn't the best but it can't be helped if I'm terrible at the came sometimes or don't make potions or can't eat that's my own fault obviously I know XD. Swimming is tough to say but Java since Bedrock seems a bit awkward I find and I've just been with Java for so long so that bias will be there but Bedrock's isn't terrible. Otherwise, I'm ok with the combat in Bedrock if I don't want to add classic combat with a mod or waiting for the combat snapshot to be part of 1.15 where I could choose between classic and 1.9 combat or they might just remove it (who knows, can only predict right now). But otherwise things like menus are good in both, server play is about the same for me I find. Otherwise if I'm missing something let me know but I will have more to say about Bedrock differences I like if someone brings it to my attention or if I play Bedrock again.
Version choice = Java, I can choose any version I want, have many launchers if the Vanilla one doesn't suit what I'm after (I use Vanilla, MultiMC and Twitch for different reasons so they all get their use I'm just saying) Bedrock is meant to be Vanilla but updated, mods and downgrading might be a thing but it's not as satisfying to do as Java.
Otherwise though if I were to put it out there I am Java biased but for a breakdown and more suggestions I can say my likes for Bedrock I just don't remember them all here.
I have only ever played on Java, and a much older version at that (1.5.1 to 1.6.4, in addition to my own modded versions which I think of as separate versions, not mods). This also reveals the major reasons why I only play on Java - older versions and mods, I wouldn't ever think of touching Bedrock because it doesn't support either (plus it appears to have never had the world generation in 1.6.4, especially the underground, as Bedrock only got caves after they made world generation like that in Java 1.8. Bedrock does have much bigger ravines though, then again, my own mods have ravines that are even bigger, while not always seeming to completely cut through the surface down to lava level, like every Bedrock ravine I've seen somebody post).
I also see people saying how well Bedrock runs - compared to the latest Java versions? You can say the same thing about 1.6.4, especially my own optimized, bugfixed (many still not fixed as of 1.14, including some critical (e.g. world corruption) ones, not to mention all the new bugs; 1.13 had more new bugs than any other version) modded versions (with some relatively simple code changes I've made order-of-magnitude optimizations, and despite being more complex than 1.7+ world generation is significantly faster than vanilla 1.6.4; the game itself also takes a few seconds to load, faster than 1.13 took to load an existing world, which is nearly instant in 1.6.4, it doesn't even have time to print out the load progress, "preparing spawn area %").
Ironically, part of the bad performance of newer Java versions can be blamed on Mojang porting over code from Bedrock without optimizing it for Java, or assuming that the JVM will perform the same optimizations as the C++ compiler:
Minecraft Bedrock Dev mojang_tommo
We fortunately don't use Java and so we can create as many BlockPos we want. Last time I checked we create around 400k every time a chunk is tessellated, but they're inlined and ultimately deconstructed into 3 ints and it doesn't even make a dent in the profiling
(in other words, they shouldn't have ever added BlockPos at all (1.6.4 does have a very similar-looking "ChunkPosition" class but it is only used where it makes sense, like returning a coordinate from a method; I've just used an array for the same thing, or even a packed value, like for my "blockstates", which are a block ID(0-255) + data value * 256), and I'm not ever sure how it would make the code better/easier to read anyway, same for the overuse of objects/wrappers/enums/layers/etc everywhere else, which has greatly inflated the size and complexity of the game (classes and code size vs the number of new features) since 1.8)
I normally play Java, but my wife started a Bedrock world, then invited us to it. I love using the VR headset I use in Bedrock. ViveCraft.org has a VR player for Java, but only recently released 1.14.3. For whatever reason at the moment, it doesn't work on my headset. So for now, I'm playing Bedrock. This will likely continue until my wife and/ or our mutual friend gets annoyed and we go back to playing Java. Being able to play both provides some perspective, as there are things I like in one version that do not exist on the other. That gives me a chance to further annoy Mojang on the Feedback page asking for Minecraft Parity.
A man's gotta do what a man's gotta do, and I'm gonna do what my wife tells me to. I just hope she doesn't tell me to stop pestering Mojang.
Java. Bedrock is like if someone had mixed windows 10 and pocket edition to make one abomination of a game. Bedrock is made to run with lower end devices, which is just a really bad decision in general because it isn't fair for higher end devices. The redstone of bedrock is the most confusing. The reason java redstone is different is because the java edition has more bugs in redstone, but they have been in the game so long and have become integral and natural for almost all redstone engineers. The bedrock colors for grass, leaves, clouds, etc. are the worst colors I have seen in any game. Ever. I can think of maybe 100 more reasons why I prefer java, but there is no way I can include all of them. I am a 100% die hard java player, and there is no way that will ever change.
Bedrock edition, because I like having more render distance with less lag and I prefer games to be optimized to peak efficiency.
Even the modding community does not justify the shortcomings of Java for me personally.
Java had its run, but the problem with that version of Minecraft is that it runs inside of a virtual machine, which if you know the basics of how that works, it adds unnecessary waste to the program. Minecraft doesn't need to have a VM to function on hardware, as evidenced with pocket edition and later bedrock, and there's a good reason why a C++ version exists, and that has nothing to do with people having a bad PC, as some claim.
it's not like a retro game, where you literally need emulation to get it to function on relevant hardware that has fundamentally different architecture to the systems those games were designed for, and I fail to see the appeal of Java or why purists defend it, sure it has more features, but the primary concern with video games is responsiveness first and foremost. Why get a high performance PC if the games you're going to play don't use it correctly? defeats the purpose.
if bedrock edition is lacking in certain aspects, then ask Microsoft/Mojang to make the improvements you wish to see,
that is the only way you're going to get Minecraft bedrock edition on an even playing field with Java with regard to content/updates.
As I mentioned before, it is Mojang's own sloppy coding that explains why Java runs so poorly; for example, here is a comparison of how awful even 1.6.4 is to my own optimizations:
Vanilla (leaves are on Fancy, "rendering" time is time spent on rendering during a chunk update, static FPS wasn't affected):
19:16:03 - Took 3610 nanoseconds to render leaf block
19:16:03 - Took 3562 nanoseconds to render leaf block
19:16:05 - Took 3566 nanoseconds to render leaf block
19:16:31 - Took 108979 nanoseconds to render fence block
19:16:37 - Took 109323 nanoseconds to render fence block
19:16:45 - Took 108307 nanoseconds to render fence block
18:40:44 - Took 11862531 nanoseconds to update light
18:40:51 - Took 11634184 nanoseconds to update light
18:40:59 - Took 11769624 nanoseconds to update light
My optimized versions:
22:22:30 - Took 451 nanoseconds to render leaf block
22:22:31 - Took 461 nanoseconds to render leaf block
22:22:32 - Took 458 nanoseconds to render leaf block
19:08:38 - Took 2635 nanoseconds to render fence block
19:08:46 - Took 2621 nanoseconds to render fence block
19:08:54 - Took 2623 nanoseconds to render fence block
16:31:40 - Took 146978 nanoseconds to update light
16:31:51 - Took 147039 nanoseconds to update light
16:32:02 - Took 146940 nanoseconds to update light
Yes, the last one is around 80 times faster than vanilla! Indeed, when I decided to compare my optimizations to the lighting engine to vanilla the lag was so extreme I thought the game was going to crash (I was using pistons to move a block over a hole in a high ceiling), yet with my modded version there is only minor stuttering (this could be eliminated if it were multithreaded, as 1.14 apparently did, but unless they actually optimized it as much as I did. which i doubt, it will just cause delayed lighting updates). My lighting engine also fixes numerous bugs, such as blocks "saving" light or persistent black spots, and enables blocks to have different light levels based on metadata (thus blocks like redstone lamps and torches can use a single block ID instead of two). In terms of real-world performance a Superflat world set to "Mega Forest" generates several times faster - all because of the time saved on lighting.
Of course, some of the code in libraries included with the JVM is just as bad; for example, most of the game relies on Java's built-in "Random" to generate random numbers but it is both slow and only has 48 bits of state (this means that for every seed there are 65535 other seeds which are the same aside from the biome map, which uses a custom 64 bit RNG):
Random.nextint() took 21.068 nanoseconds
Random32.nextint() took 1.1745 nanoseconds; was 18.218817 times faster than Random
Random48.nextint() took 2.632 nanoseconds; was 8.0045595 times faster than Random
Random64.nextint() took 2.313 nanoseconds; was 9.108517 times faster than Random
Random48 is simply a near-replica of Java's Random, which is so slow because it was designed to be threadsafe, which is not needed for most (all?) uses in the game and uses an "AtomicLong" object instead of a "long" primitive, while Random64 is my own RNG which is both even faster and truly 64 bit; in large part due to this as well as adding custom methods which replace several calls I was able to triple the speed of my cave generator (e.g. one line which is called hundreds of times per cave tunnel generated is "(rand.nextFloat() - rand.nextFloat()) * rand.nextFloat()"; a single method call which does the same thing internally is twice as fast). 2.3 nanoseconds is also pretty fast - 432 million random numbers per second (the only real difference between Random48 and Random64 is that Random48 has an additional operation to truncate the result to 48 bits, hence it is slightly slower; 32/64 bit just uses the size of the datatype itself to truncate the result).
Even more impressive is a 32 bit implementation, which I use for most uses where a large number of states aren't important, like in my world generator classes which generate things like trees and ores (this isn't even a separate class, I just use a "lcg" variable/field and a basic RNG algorithm, "lcg = lcg * 1664525 + 1013904223", plus code to extract bits from it as needed, so it also avoids creating more objects), which can produce nearly a billion random numbers per second - that's certainly not interpreted speed (and yes, I did make sure that the JVM didn't just optimize my tests away - it is smart enough to remove code whose result is never used) - modern JVMs perform a lot of just-in-time compilation to native code which can be just as fast - the biggest flaw being the way they handle memory, which where Mojang's coding practices are at their worst:
My first few game engine attempts had this problem. I would allocate new objects all the time, for everything. All position vectors were immutable, because separation of concerns, information hiding, encapsulation, that was all taught to me as good. It was taught that that is the correct way of making large, object oriented software systems. I was taught that I could just allocate new objects, let the old ones float away and get scooped up by the garbage collector. And for a while, everything was beautiful. Entity lists would grow with new entities and dead entities could be simply trimmed out of the list.
Well for my first attempt at an XNA game on the xbox 360, it lagged like crazy. Frame rate was single digits. It didn't do this on my computer, only on the Xbox. Turns out, the xbox360 has horrible garbage collection. Since then I've always maximized the reuse of my variables, using object pools all over the place and always reassigning and never discard memory that I've allocated. I've had to completely redesign my engine around this principle.
When he said that they replaced the coordinate points with an immutable BlockPos which must be reallocated and the old one discarded whenever a different coordinate was desired, I thought to myself "Just like I used to do. Same [censored] my professors taught me." This is not a good idea AT ALL for real time applications.
MumboJumbo has a YouTube video detailing how redstone works differently in the two versions. So anyone building a lot of redstone contraptions might want to take that into consideration when choosing a version.
Very true, it is easy to miss platforms and go straight to what benefits, strengths or feel each has especially as Java is the only option on any PC platform (Windows, Mac and Linux) compared to if you have the option of Console/Handheld, Mobile (iOS/Android/Windows 10 Phone at this point over 8.1) or Windows 10, that can't be ignored.
Rollback Post to RevisionRollBack
Forum Thread Maintainer: Fabric Project, Legacy Fabric, Power API, Rift/Fabric/Forge 1.13 to 1.16,
-Niche Community Content Finder, -Youtuber, -Modpack/Map Maker, -Duck
The Meaning of Life, the Universe, and Everything.
i read somewhere, probably here lol, that mojang has started to, and will continue to add java edition features to bedrock edition and bedrock edition features to java edition until they are essetially one version. they have already implementes some bedrock stuff in 1.15.
i wish i could remember where i read it so i could link it.
here is the link for the bedrock additions if anyone cares lol - 19w36a is the third snapshot for Java Edition 1.15, released on September 4, 2019,[/sup] which adds many features originally from Bedrock Edition.
There are certainly things platform specific, such as Marketplace or Redstone Quasi-Connectivity. Hopefully, the differences in actual gameplay will be far less noticeable as time goes by, and it won't matter as much. Which platform? Where are your friends already playing? That's the version I want to be on! 🤗
"Better" is a nice, spongy word that doesn't necessarily mean anything. Specifics are useful. Specifics like Mumbo Jumbo's video on things he *likes* about Bedrock redstone and things he *hates* about Bedrock redstone: