Description should be language-agnostic

Haskell translation:
https://www.codewars.com/kumite/63b973cc44b23a0031ada9e0?sel=63b973cc44b23a0031ada9e0

It doesn't mention the name of the conversion rates table in the description (Python).
Only found out via comments here that it is CONVERSION_RATES.

How do you tell a number from binary code? Is there some kind of formula for this?

You still have 2 big exploits to fix:

https://www.codewars.com/kata/reviews/5b59a8753237d248d6003489/groups/5b59b7273237d2a42d0037d7
https://www.codewars.com/kata/reviews/5b59a8753237d248d6003489/groups/5b7c5add5d191a2b9f00009e

You're also not checking if user functions would make visible changes on the object after going through the function.

I'd say it's a really, really, really bad practice for this kata to have solutions that mutates the input mercilessly ;-)

You are also mixing up the property of the properties of the object, and the object itself.

A perfectly normal object can have all its properties frozen (writable: false). It's just a side effect that whenever you freeze/seal an object, it also applies to all the properties. When Object.isFrozen and the like is called, it checks about the object itself, and not its properties, and yet by how your tests are written, doing the latter will pass your weak tests just fine.

For the purposes of this kata, the input object can only exist in one, single condition at a time. For example, if the input object is frozen, it is only frozen. It is not both sealed and frozen at the same time. It is just frozen.

Since freeze > seal > preventExtensions strictly, your requirements are suggesting a different behaviour from the original functions in Object. Naming them the same is really asking for confusion.

You should really name it something like isOnlyFrozen or something.

There is no way to determine properties can be updated in an object if it has no properties to begin with (i.e {}).

If all objects are supposed to be non-empty it should be mentioned in the descriptions.

it("should not be sealed", function() {
  Test.assertEquals(isSealed(frozenObj), false);
})

but

frozenObj = {a: 1, b: 2, c: 3};
Object.freeze(frozenObj);
Object.isSealed(frozenObj) === true

An object is sealed if it is not extensible and if all its properties are non-configurable and therefore not removable (but not necessarily non-writable).

Declaring Java methods to return "implementations" like this is a bad idea because it unnecessarilly imposes a restriction on the way the solution can be implemented.

public static ArrayList<ArrayList<Integer>> bucketize(final int[] arr)

Similarly this kind of calling code in Test is is sucking the life out of any creativity...

ArrayList<ArrayList<Integer>> actual = FrequencyAnalysisWithBuckets.bucketize(arr);

===

Use interfaces for APIs. That's what they are for...

public static List<List<Integer>> bucketize(final int[] arr)

Or better yet

public static List<Integer>[] bucketize(final int[] arr)