그렇긴 하지만 작업하기 위해 이 클래스를 이해하는 것이 유용할 수 있습니다.
효율적으로 처리할 수 있습니다
키 세트 핸들에서 getPrimitive()를 호출하면 어떻게 되나요?
레지스트리1에 대한 호출로, 레지스트리에 생성할 구체적인 메서드가 있는 객체가 포함되어 있습니다.
키 및 프리미티브(예:
AesGcm 키 또는 ChunkedMac 인스턴스 등록처의 임무는 호출을 전달하는 것입니다.
전달합니다. 객체가 등록된 경우에만 작동하므로
사용할 프리미티브를 항상 등록하는 것이 중요합니다.
하지만 필요한 프리미티브를 이미 등록한 라이브러리를 사용하는 경우에는 어떻게 해야 하나요?
바로 이것이 문제입니다. 레지스트리가 삭제되는 이유 중 하나는
이 경우 라이브러리 작성자가
더 이상 해당 프리미티브를 등록하지 않습니다. 이 시점에서 코드가 중단되고
명확하지 않고 혼란스러울 수 있습니다. 따라서 항상
사용합니다. 예를 들어 Java 코드에서 MAC을 사용하려는 경우 다음을 수행해야 합니다.
설정 단계에서 다음을 수행합니다.
MacConfig.register()
이 코드는 필요한 모든 객체가
MAC 프리미티브를 사용하는 데 필요한 모든 위치에 있습니다.
이 문제에는 한 가지 측면이 더 있습니다. 일부 종속 항목은
실제로 필요하지 않고 의존하지 않으려는 것들이 있습니다. 이것은
글로벌 등록처를 삭제해야 하는 또 다른 이유가 있습니다.
정확하게 말하자면 레지스트리 클래스의 전역 싱글톤 인스턴스에 적용됩니다. 'Registry'라는 이름을 사용합니다. 클래스와 싱글톤을
교환하여 사용할 수 있습니다 ↩
[null,null,["최종 업데이트: 2025-07-25(UTC)"],[[["\u003cp\u003eThe Registry in Tink is a global entity responsible for generating new keys and primitives, but it is intended for internal use only and is slated for removal.\u003c/p\u003e\n"],["\u003cp\u003eThe Registry forwards calls from \u003ccode\u003egetPrimitive()\u003c/code\u003e to objects that create keys and primitives, and these objects must be registered for the process to work.\u003c/p\u003e\n"],["\u003cp\u003eIt's essential to explicitly register the primitives you intend to use (e.g., \u003ccode\u003eMacConfig.register()\u003c/code\u003e), to ensure your code works consistently and doesn't rely on the unpredictable behavior of other libraries.\u003c/p\u003e\n"],["\u003cp\u003eRelying on other libraries to register primitives can lead to unexpected code breakage if the library's registration practices change, making it crucial to self-manage registrations.\u003c/p\u003e\n"]]],["The Registry is a global entity in Tink for generating keys and primitives, but it's slated for removal and should not be directly accessed. `getPrimitive()` calls are forwarded to the Registry, which then creates the correct object, if registered. It is crucial to register the primitives one intends to use directly, using method like `MacConfig.register()`, because relying on library registration leads to code fragility and unwanted dependencies. The class is considered for removal.\n"],null,["# Registry\n\n| This page describes an area that undergoes a major redesign at the moment. The status depends on the programming language used.\n\nStarting with the basics, here is an informal definition of Registry:\n| **Key Term:** **Registry** is a global entity in Tink that knows how to generate new keys and primitives.\n\nBut:\n| **Warning:** This class is intended to be used only by internal interfaces. You should NOT call its methods directly, but instead access them through higher level APIs like KeysetHandle.\n| **Warning:** This class is going to be removed.\n\nThat being said, it may be useful to understand this class in order to work\nwith Tink efficiently for the time being.\n\nWhat happens when you call `getPrimitive()` on a keyset handle? It forwards your\ncall to the Registry^[1](#fn1)^, which contains objects with concrete methods to create\nkeys and [*primitives*](/tink/design/primitives_and_interfaces), such as an\nAesGcm key or a ChunkedMac instance. The Registry's task is to forward the call\nto the correct object. This only works if the object is registered, which is why\n**it's important to always register the primitives you are going to use**.\n\nBut what if I use a library that already registered the primitives I need?\n--------------------------------------------------------------------------\n\nThat's precisely the problem. And one of the reasons Registry is being removed.\nBecause in this case your code works only until the library authors decide to\nnot register that primitive anymore. At this point your code breaks, and the\nreason is non-obvious and confusing. So **always register what you\nuse**. For example, if you intend you use MAC in your Java code, you should do\nthe following in the setup phase: \n\n```java\nMacConfig.register()\n```\n\nThis code ensures that all the necessary objects are registered in the\nnecessary places for you to use the MAC primitive.\n\nThere is one more side to this problem. Some of your dependencies may register\nthings you actually don't need and would prefer to not depend on. This is\nanother reason to remove the global Registry. \n\n*** ** * ** ***\n\n1. to the global singleton instance of the class Registry, to be precise. We use the name \"Registry\" for both, the class and the singleton, interchangeably. [↩](#fnref1)"]]
