Live data from Hacker News

Minecraft removing obfuscation in Java Edition

minecraft.net

441–450 of 478 posts

Re: Minecraft removing obfuscation in Java Edition

#441
post #351

Earlier quoted context omitted.

> Hell, they could even make it Open Source with a clause preventing other companies from using to code to make a profit Such a clause would immediately make it Source Available not Open Source.

by that logic GPL wouldn’t be open source either since it also adds restrictions unlike the fuck license nowadays github is filled with so-called open source projects under GPL3 but the maintainers want you to pay for a dual license

Let's look at the OSI definition since that's what people mean by Open Source (particularly when capitalized):

https://opensource.org/osd

> The license must allow modifications and derived works, and must allow them to be distributed under the same terms as the license of the original software.

> No Discrimination Against Fields of Endeavor

You cannot restrict selling derivatives of the software (a field of endeaver), and the derived work must be able to be shared under a similar license.

GPL does not add any restrictions counter to that. It allows you to redistribute and sell copies if you want, you just have to respect your user's freedom by also giving them the modified source code.

Re: Minecraft removing obfuscation in Java Edition

#442
post #351

Earlier quoted context omitted.

> Hell, they could even make it Open Source with a clause preventing other companies from using to code to make a profit Such a clause would immediately make it Source Available not Open Source.

by that logic GPL wouldn’t be open source either since it also adds restrictions unlike the fuck license nowadays github is filled with so-called open source projects under GPL3 but the maintainers want you to pay for a dual license

[deleted]

Re: Minecraft removing obfuscation in Java Edition

#443
post #261

Earlier quoted context omitted.

As someone coding since 1986 it is always kind of interesting how Java gets the hate for something that it never started, and was already common in the industry even before Oak became an idea. To the point that there are people that will assert the GoF book, published before Java was invented, actually contains Java in it.

People did it, some times, when they needed it. It was so rare that the GoF though they needed to write a book to teach people how to use those patterns when they eventually find them. But after the book was published, those patterns became "advanced programming that is worth testing for in job interviews", and people started to code for their CVs. The same happened briefly with refactoring, and for much longer with…

It was, but still the book did not magically changed from Smalltalk and C++ into Java.

Re: Minecraft removing obfuscation in Java Edition

#444
post #324

Earlier quoted context omitted.

It is called packages. There is nothing on the modules as programming concept that requires the existence of functions as entity. Again, Smalltalk did it first, and is actually one of the languages on the famous GoF book, used to create all the OOP patterns people complain about, the other being C++.

> There is nothing on the modules as programming concept that requires the existence of functions as entity. I didn't claim it does. To make the point though: bare functions are a much simpler building block, and a much cleaner building block than classes. Classes by their nature put state and behavior in one place. If one doesn't need that, then a class is actually not the right concept to go for (assuming one has t…

From type systems theory point of view, a class is an extensible module that can be used as a variable.

As mentioned in another reply, Java did not invent this, it was building upon Smalltalk and SELF, with a little bit of Objective-C on the side, and C++ like syntax.

Try to create a single function in Smalltalk, or SELF.

http://stephane.ducasse.free.fr/FreeBooks.html

https://www.strongtalk.org/

https://selflanguage.org/

It is also no accident that when Java came into the scene, some big Smalltalk names like IBM, one day of the other easily migrated their Smalltalk tooling into Java, and to this day Eclipse still has the same object browser as any Smalltalk environment.

Smalltalk,

https://www.researchgate.net/figure/The-Smalltalk-browser-sh...

Which you will find a certain similarity including with NeXTSTEP navigation tools, and eventually OS X Finder,

The code browser in Eclipse

https://i.sstatic.net/4OFEM.png

By the way, in OOP languages like Python, even functions are objects,

    Python 3.14.0 (tags/v3.14.0:ebf955d, Oct  7 2025, 10:15:03) [MSC v.1944 64 bit (AMD64)] on win32
    Type "help", "copyright", "credits" or "license" for more information.
    >>> def sum(x, y): return x + y
    ...
    >>> sum
    
    >>> dir(sum)
    ['__annotate__', '__annotations__', '__builtins__', '__call__', '__class__', '__closure__', '__code__', '__defaults__', '__delattr__', '__dict__', '__dir__', '__doc__', '__eq__', '__format__', '__ge__', '__get__', '__getattribute__', '__getstate__', '__globals__', '__gt__', '__hash__', '__init__', '__init_subclass__', '__kwdefaults__', '__le__', '__lt__', '__module__', '__name__', '__ne__', '__new__', '__qualname__', '__reduce__', '__reduce_ex__', '__repr__', '__setattr__', '__sizeof__', '__str__', '__subclasshook__', '__type_params__']
    >>> type(sum)
    
    >>> sum.__name__
    'sum'
    >>> sum.__class__
    

Re: Minecraft removing obfuscation in Java Edition

#445
post #421

Earlier quoted context omitted.

This is also true, and also why I want it to be a relatively unopinionated base engine. Unfortunately technical advancements came alongside opinionated content. 1.8 brought creative mode and fast/tintable skylight updates - and hunger and very griefy endermen and a bucnh of worldgen structures. 1.0 brought itemstack NBT - to support enchantments and potions - and gave a sandbox game an official end. 1.3 brought clien…

All of those things seem like upsides to me! And for what it's worth, I think I've visited The End once? What makes it a sandbox is that you can play however you want - let The End be your goal, if you'd like, or just mine and build big castles, or mess around in Creative mode. That's the brilliance of it.

When you're engaging in game design, you usually want to make a coherent sandbox. If the best way to produce electricity in your electricity mod is to enslave an army of witches to throw healing potions at each other, it's probably not your design intention. You probably wanted it to involve digging for coal, or solar panels.

In current Minecraft a lot of resources are renewable via villager trading. The best way to get many resources is to enslave some villagers and find a trading loop that nets a profit in emeralds on each cycle, then spend some of that profit on the thing you want. If you want the player to dig up coal to make electricity, they can make a trading hall or a wither skeleton farm instead. If you want the player to dig up iron to expand their factory they'll make an iron golem farm which produces it at a high rate for free. The section of the design space that you wanted to access is blocked off by the mechanics of the base game.

Re: Minecraft removing obfuscation in Java Edition

#446
post #421

Earlier quoted context omitted.

All of those things seem like upsides to me! And for what it's worth, I think I've visited The End once? What makes it a sandbox is that you can play however you want - let The End be your goal, if you'd like, or just mine and build big castles, or mess around in Creative mode. That's the brilliance of it.

When you're engaging in game design, you usually want to make a coherent sandbox. If the best way to produce electricity in your electricity mod is to enslave an army of witches to throw healing potions at each other, it's probably not your design intention. You probably wanted it to involve digging for coal, or solar panels. In current Minecraft a lot of resources are renewable via villager trading. The best way to…

Or maybe they just wanted to mix fantasy and tech?

Or maybe it wasn't intentional, but emergent... sort of like, you know, playing in a sandbox?

Villager trading is another new(ish) mechanic I don't partake in. I know others who don't either. I don't think we're playing the game wrong.

And if a mod/pack developer doesn't want players to use vanilla mechanics, they can disable those, as many, many developers do.

Re: Minecraft removing obfuscation in Java Edition

#447

Earlier quoted context omitted.

>You cannot have quality software without these basic testing techniques Of course you can, wtf? Mock are often the reason of tests being green and app not working :)

> Of course you can, wtf? Explain then what is your alternative to unit and integration tests. > Mock are often the reason of tests being green and app not working :) I don't think that's a valid assumption. Tests just verify the system under test, and test doubles are there only to provide inputs in a way that isolates your system under test. If your tests either leave out invariants that are behind bugs and regress…

>Explain then what is your alternative to unit and integration tests.

Tests against real components instead of mocks.

>If your tests either leave out invariants that are behind bugs and regressions or have invalid/insufficient inputs, the problem lies in how you created tests, not in the concept of a mock.

Nowadays external components can be very complex systems e.g dbs, messaging queues, 3rd APIs and so on

A lot of things can go wrong and you arent even aware of them in order to get mocks right.

Examples? fuckin emojis.

On mocked in memory database they work fine, but fail on real db due to encoding settings.

Re: Minecraft removing obfuscation in Java Edition

#448

Earlier quoted context omitted.

> Of course you can, wtf? Explain then what is your alternative to unit and integration tests. > Mock are often the reason of tests being green and app not working :) I don't think that's a valid assumption. Tests just verify the system under test, and test doubles are there only to provide inputs in a way that isolates your system under test. If your tests either leave out invariants that are behind bugs and regress…

Most compilers do not use "unit" tests per se. Much more common are integration tests targeted at a particular lowering phase or optimization pass. This is pretty important since "unit tests" would be far too constraining for reasonable modifications to the compiler, e.g. adding a new pass could change the actual output code without modifying the semantics.

LLVM has "unit" tests

I mean they run single pass with some small llvm ir input and check if the output IR is fine

Re: Minecraft removing obfuscation in Java Edition

#449

Earlier quoted context omitted.

> Of course you can, wtf? Explain then what is your alternative to unit and integration tests. > Mock are often the reason of tests being green and app not working :) I don't think that's a valid assumption. Tests just verify the system under test, and test doubles are there only to provide inputs in a way that isolates your system under test. If your tests either leave out invariants that are behind bugs and regress…

>Explain then what is your alternative to unit and integration tests. Tests against real components instead of mocks. >If your tests either leave out invariants that are behind bugs and regressions or have invalid/insufficient inputs, the problem lies in how you created tests, not in the concept of a mock. Nowadays external components can be very complex systems e.g dbs, messaging queues, 3rd APIs and so on A lot of…

I'm not a fan of extensive mocking but you're conflating two rather different test cases. A test where you mock out the database connection is testing something in application code, which has nothing to do with database configuration. You should of course have tests towards the database too, but then you'd mock out parts of the application instead and not the database itself.

Re: Minecraft removing obfuscation in Java Edition

#450
post #449

Earlier quoted context omitted.

>Explain then what is your alternative to unit and integration tests. Tests against real components instead of mocks. >If your tests either leave out invariants that are behind bugs and regressions or have invalid/insufficient inputs, the problem lies in how you created tests, not in the concept of a mock. Nowadays external components can be very complex systems e.g dbs, messaging queues, 3rd APIs and so on A lot of…

I'm not a fan of extensive mocking but you're conflating two rather different test cases. A test where you mock out the database connection is testing something in application code, which has nothing to do with database configuration. You should of course have tests towards the database too, but then you'd mock out parts of the application instead and not the database itself.

>A test where you mock out the database connection is testing something in application code, which has nothing to do with database configuration.

Wdym?

You're testing e.g simple crude operation, e.g create hn thread

With mocked db it passed, with real db it fails due to encoding issue.

The result is that tests are green, but app does not work.

Post reply on HN