Tips for OpenSource Project – Git

Recently I’m working on a opensource project: it-chain/engine. I’ve participate in this project as collaborator early in the year. For about 6 month, there’re lots of hard situation to work with other developers. And also learned about how can I work with others not making awkward situation. In addition I want to share the tips to work on opensource project and how to use git, not basic tutorial but more about practices which fit into opensource project.

Work on Smaller Feature

I think this is coincide with the principle of Seperation of Concerns(SoC) Principle in software design. And this is what I utmost want to emphasize in this post. Let’s assume that you are working on food delivery service project with others. And one developer on your team issued on github that “Now I’m going to fix whole delivery system” and let’s assume that these delivery system code affects on all other sub-servcies code, like UserManagement, StockManagement. Then whenever other developers are trying to fix those sub-services, the codes will broken because the developer who works on whole delivery system will mass up whole of your codes. And I think this is one of most irritating situation. Works on smaller feature first which do not affact on others parts, then integrate with others.

Issue on github which feature I’m going to working on

Two different developers may work on same part. And at the point of pull request, the other developer who is not pull requested may panic. So this is basic but important manner to working with other in opensource project. Issue what’s I’m going to working on and tag the other developers to notify.

But code should be large enough to express functional unit

For example, someone pull requested with this single struct

We don’t know what is this command struct is. And where this struct are going to used. It might be better to pull request with ConfirmBlockHandler function which actually use this struct. And other can see that where this struct are going to used in the view of whole system.

Tips on Using Git

git pull -r

Usually in personal project we just pull the code. But just pull the code actually dirties your git tree if that project grow.

And there’s another advantage by using -r option. For easily rebase, pull request should have least number of commit. This convention helps each pull request have 1 commit and this also helps each pull request have smaller feature which helps other feedback your codes and also each team member can work well by not interfered with the codes that pull requested.

git commit --amend

Our team makes conventions one of which is not to make unnecessary commit and this can be the cause of reject of pull request.
To remove unnecessary commits, git commit --amend is the way. Let’s assume that you made a commit with message “add command handler”, then you find out that you forgot to add some pieces of codes, of course by mistake. But this fixes are too small to make another commit. Then you can use --amend options. You just need to type git commit --amend then the codes that you commited and the codes that you fixes are now in one commit with message “add command handler”.

git reset --soft HEAD~<NUM>

You got a feedback from pull request that you may need to combine two commits into one that you pull requested. Because other can think the second commit is unnecessary. Then you can use git reset in the local.

Let’s this is the commits you made. In this situation, you need to combine Unnecessary commit into Some commit. Then you can use git reset --soft HEAD~1, with this you reset the recent one commit and those codes you made in Unnecessary commit are unstaged. Your team feedbacks you combine two commits so now you git add . and git commit --amend. Then your commits looks like this.

How to Write Go Testing


In making your application with code, it is strongly recommended to write test cases. Because it can make sure that your whole bunch of codes work correctly and for your mind health. Recently I have a chance to work in great project named it-chain-Engine with golang. In shortly this project is about lightweight and completely customizable blockchain engine.

Completely customizable, because this project is implemented with DDD & event sourcing way which can separate every component with bounded context and each component is composed with lots of layers. And to make sure those layers as well as micro components which consists of layer are interact well, writing test case is best. So how can we write go testing? There are some ways and I’ll post some tips with my experience.

Use the “underscore test” package

Those codes are almost same. Then what is difference? What is good thing when writing “underscore test” package name?

One thing is we can write test cases like when we really use that codes. When we use BlockPoolModel in other package, we write codes like blockchain.NewBlockPool(), not NewBlockPool(). This provides us the real experience as we actually write some codes.

Also there is another advantage that provide exception which golang files in the same directory belong to the same package. In other words, you can put block_pool.go and block_pool_test.go in the same directory named blockchain with different package name blockchain and blockchain_test.

Test Helpers

When testing, we may need to setup test fixture like connecting to db, mq, providing mock datas. So we are writing that codes over and over although actual testing codes really short. You may can think ‘How about refactor those codes’ like JUnit @Before or mocha before method. We can implement it using defer.

Here before writing actual test codes you can setup fixture, in this case executing cmd commands works as JUnit’s @Before. And in SetupTest you can pass testing.T, so you can also test whether our test fixtures are setup well. Also as you can see SetupTest returns function. In returned function you can clean up fixture like close db connection, remove files and so on. By refactor setup function you can increase readability of your test codes and can see what is going on in those test cases at once. And the best thing is you can save your effort to write boring setup codes.

Table Driven Tests

How about testing about several cases with only one setting? You may can take into account Table Driven Tests. Let’s start with simple example and see what is it.

We can see fibTests slice (table) which provides test input and output. And every iteration you can test with given input, output. Advantage of this approach is you can test lot of cases with one actual test case codes and there’s no need much effort to add test cases, just add one row of table. Let’s see another one.

This is rather complicate example. First, used map instead of slice. As you can see key is used as test case description and by using value as struct you can explicitly indicate what is input, output and error. Below the table is injecting mock object to command handler which is what you are going to test. Mocking will be explained in next section. Finally in the for loop, there’s actual test codes commandHandler.HandleConfirmeBlockCommand(test.input.command).

Downsides: readability

This is about Table Driven Tests. And yes, there’s advantages with this technique but also exists downside. The point is readability, as you may noticed in second example, table’s input, output, error row can be large in real-world testing and more importantly you can’t know what is going to do with these huge inputs. You can find out where all of these inputs are going to use at the point of actual test codes.

Using Mock

Let’s assume that we want to test HandleTxCreatedEvent function. This function take txCreatedEvent as parameters and from this event we get target transaction to save. And with this transaction we save it to TransactionRepository.

But we do not know how TransactionRepository is implemented. So TransactionRepository may can affect to our test results. We should take control of txRepository.Save so that we can make sure the cause of failure of tests are not from TransactionRepository. And this is where Mock is come into play. We can see constructor receives TransactionRepository and create EventHandler object. And instead of injecting real TransactionRepository we could inject our own mocking TransactionRepository. As a result t.txRepository.Save(tx) could trigger our own defining function which helps tests.

With mocking, test goes like this. We create MockTransactionRepository struct which implements TransactionRepository so that we could inject this mock into our testing eventHandler. Next is declare functions we need to control, in this case SaveFunc which is triggered when MockTransactionRepository.Save is called. And those functions are defined inside test cases for our own tastes, we could assert about parameters and could return specific errors for some case. Finally inject those mocking object into our testing object: eventHandler.

Downsides: too many mocks

This methodolgy surly has downsides. We could think of testing object but that object receive too many parameters in constructor and for take control of those parameter object we should make all of them as mock, also implement mock object’s functions. So for one easy test case, we may need to write hundreds of codes for mocking object and this is super waste, and we are lazy.

But we need to think about this first! Those objects which need many mocking object may have too many responsibilities and this is not good design. We should think about separating those responsibility by separating object and this is about ‘Single Responsibility Principle’.

And the other way to solve this problem is redeclaring interface. We may not need all of the functions declared in TransactionRepository. We may only need write functions for this interface. So we could fix like this.

By creating WriteOnlyTransactionRepository, not only there’s just one function to implement in mock object but this could see that this repository only works for writing things at once and also separate responsibility. I think this is better design.

Hyperledger Fabric Configure Network – byfn 뜯어보기


Hyperledger Fabric docs를 읽다보면 가장 처음 접하게 되는 것이 byfn 튜토리얼이다. 처음에 개념적인 부분과 실제 네트워크의 흐름을 맞춰보는데 정말 도움이 되는 것 같다. 그런데 정말 찬찬히 뜯어봐야한다. 하나씩 ‘이건 왜 이렇게 동작하는거지?’, ‘이건 왜 안되는거지?’ 하면서 Fabric의 개념적인 부분하고 연결시키면서 생각하면 어느순간 전체적인 그림이 그려지게 된다.

처음에 sample을 받고, develop 혹은 연습하는데 도움이 되는 바이너리 파일을 받게 된다. 바이너리 파일에는 cryptogen, configtxlator, peer 등 우리가 네트워크를 쉽게 구성할 수 있게 도움을 줄 수 있는 프로그램들이 있다.

전체 디렉토리 구조이다. 빠진 파일들도 있지만 일단 우리에게 필요한 것은 이 정도이다. 간단하게 각각을 살펴보면 다음과 같다.

  • cryptogen: 간단하게 네트워크 구성원들에게 certificates들을 발급해준다. production에서는 사용하지 않는 것이 좋다. 대신 CA에서 받아야한다.
  • configtxlator: protobuf와 json 변환 및 파싱을 도와준다.
  • Hyperledger Fabric에서 만들어준 sample 스크립트이다. 이번 포스팅에서는 이 파일을 하나하나 다 뜯어 볼 것이다.
  • configtx.yaml: 네트워크의 channel과 genesis block을 만들고 anchor peer를 설정한다. 파일 이름에서 유추할 수 있듯이 네트워크 전체의 설정 내용을 담고 있다.
  • crypto-config.yaml: cryptogen이 이 파일을 사용한다. 이 파일을 이용해서 organization와 그 구성원들에게 각각의 certificate을 발급한다. 그래서 각각의 organization들이 독자적인 CA를 가지고 있는 것처럼 보이게 할 수 있다.
  • docker-compose-cli.yaml, docker-compose-base.yaml: 전체 네트워크 노드들의 docker-compose 설정들이다.

튜토리얼에서는 ./ -m generate ./ -m up으로 전체적인 네트워크 구성이 시작되고 완성된다. 우리는 byfn.sh에서 어떤 일이 일어나는지 알아보고 싶다.

Generate Crypto Artifacts, Channel Configuration

시작 부분이다. generate 에서는 generateCerts, replacePrivateKey, generateChannelArtifacts 가 일어난다.

Create Certificates Using Cryptogen

generateCerts 부분이다. 여기서는 cryptogen 을 이용해서 네트워크의 ceritificates를 만들게 된다. cryptogen 의 사용법은 다음 링크에 자세히 나와있다.(사용법) cryptogen으로 만든 crypto artifacts들은 crypto-config에서 확인할 수 있다. 펼쳐보면 확인할 수 있겠지만 ordererOrganizations, peerOragnizations 디렉토리로 나눠져있고, 각각은 orderer의 certificate, peer들의 certificate들이 담겨져있다.

여기서 잠깐 지금 포스팅을 하는 이유가 나온다. replacePrivateKey 를 보면 알겠지만 organization domain이 hardcoding 되어있다. 그렇기 때문에 우리는 이 스크립트를 이용하는 것이 아니라, 이해한 뒤에 우리가 필요한 부분에 대해서 스크립트를 다시 짜야한다.

이 부분은 Fabric과 관련은 없는 부분이다. 단순히 docker-compose template파일을 복사한 뒤에 이전에 우리가 cryptogen으로부터 받은 certifcate들을 리눅스의 sed 명령어를 이용해 compose 파일 적절한 부분에 바꿔넣기 하고 있다.

Generate Channel Config Transaction

Channel configuration들을 만드는 부분이다. 이 부분은 echo 부분이 이해하는데 도움이 되어서 남겨놓았다.

configtxgen -profile TwoOrgsOrdererGenesis -outputBlock ./channel-artifacts/genesis.block

먼저 configtxgen 을 이용해서 Genesis block을 만든다. genesis block의 설정과 관련된 부분은 configtx.yaml 파일의 Profiles 에 명시되어있다.

TwoOrgsOrdererGenesis 를 보면 genesis block의 설정을 알 수 있다. 네트워크의 Orderer를 설정하고 Consortiums 섹션에서 consortium 이름과 거기에 속한 organization들을 설정할 수 있다. (configtx.yaml 더 자세한 설명 보기)


으로 channel configuration 파일을 만든다.

여기서는 각 organization의 anchor peer들의 정보를 transaction으로 만든다.

여기서 만들어진 네 파일들은 모두 channel을 만드는데 설정파일같은 역할을 하게 된다. 네이밍에서 알 수 있지만 모두 .block, .tx로 끝나는 것을 볼 수 있다. 각각은 모두 block이거나 transaction들로 channel이 만들어지고 그 channel의 peer들의 ledger에 모두 기록되게 된다.

지금까지 우리가 만든 것을 정리하면 다음과 같다.

  • Orderer, Peer certificates
  • Genesis Block
  • Channel config transaction
  • Anchor peer config transaction for each organization

이제 channel을 만들기 위한 준비는 끝났고, 노드들을 띄워서 channel을 만들고 네트워크를 형성할 순서이다.

Build Network

network를 띄우는데 두 가지 옵션이 있다. state database로 default인 leveldb를 쓸 것이냐 couchdb를 쓸 것이냐가 그것인데 일단은 leveldb를 쓰기로 한다.(바꾸는 것은 정말 어렵지 않다.) 그리고 지금 단계부터는 스크립트를 돌리지 말고 직접 docker에 들어가서 놀아보는 것을 권장한다.

docker-compose -f docker-compose-cli.yaml up 으로 노드들을 띄운다. 여기 -d 옵션을 빼고 실행해서 직접 로그들을 살펴보는 것이 좋다. 또 cli docker container에서 을 실행시키는데 이 부분도 직접 container에서 돌려보는 것이 좋다.

더 나아가기 전에 우리가 주로 놀 곳이 cli 이기때문에 docker-compose-cli.yaml 에서 cli 가 어떻게 생겼는지부터 살펴보자. 그리고 혹시 docker나 docker-compose에 익숙하지 않은 사람들은 간단하게나마 어떤 것인지, 무엇을 하는 것인지 이해하고 보면 더 좋을 것 같다.

여기서 우리가 살펴볼 부분은 environment 부분들이다. 앞으로 cli에서 우리는 environment variable들을 바꾸면서 다른 organization, 다른 peer들로 옮겨다닐 것이다. 현재 로 되어있고 volumes 에서 crypto-config 가 mount 되어있으므로 environment variable을 바꾸지 않는 이상 cli는 peer0.org1처럼 행동하게 된다. 또한 volumes 에서 chancode, crypto-config, scripts, channel-artifacts 가 mount 되어 있는데 이 덕분에 나중에 cli에서 chaincode install과 channel을 만들거나 join할 수 있다.

그럼 이제 다른 터미널을 띄워서 cli로 들어가보자.

docker exec -it cli bash

Create Channel

먼저 channel을 만들기 전에 transaction을 제출할 Orderer의 certificate을 환경변수로 설정해주어야한다. 그리고 설명의 편의를 위해 channel이름도 ‘mychannel’이란 이름으로 환경변수에 넣어주자.

설정을 마쳤으면 아까 만들어놓은 channel config transaction을 Orderer에게 제출하자.

그러면 Received block: 0을 통해 mychannel channel가 성공적으로 생성되었고, mychannel.block 이라는 genesis block을 받았음을 알 수 있다.

docker-compose 의 로그를 통해서도 성공적으로 orderer에 transaction이 제출되었음을 확인할 수 있다.

Join Organizations to Channel

이제 우리는 성공적으로 channel을 생성했다. 이제 남은 일은 org1.peer1과 org2.peer0, org2.peer1들을 channel에 참여시키는 것이다. 아까도 말했지만 cli docker container는 crypto-config를 mount해놓았기 때문에 환경변수를 다른 peer로 바꾸는 것만으로도 그 peer처럼 행동할 수 있다. 그럼 먼저 org1.peer1으로 바꿔보자.

그리고 mychannel 에 join 요청을 보내자. Hyperledger Fabric에서는 channel에 join 요청을 할 때는 channel의 Genesis block을 가지고 요청을 보낸다. 그런데 우리는 아까 Genesis block을 만들어 놓았다. 그러면 이것을 가지고 join 요청을 보내보자.

성공적으로 join 했음을 확인할 수 있다. 마찬가지 방법으로 peer0.org2, peer1.org2도 channel에 join하면 된다. 이제 남은 일은 각 organization에서 anchor peer를 업데이트시키면 네트워크 구성이 마무리된다. Anchor peer의 설정파일은 아까 만들어둔 Org1MSPanchors.tx, Org2MSPanchors.tx 를 이용해서 업데이트하면 된다.

성공적으로 업데이트 시켰음을 확인할 수 있다.


Hyperledger Fabric이 어떤 식으로 돌아가는지 확인하고 싶다면, sample로 주어진 shell script를 찬찬히 뜯어보라고 권하고 싶다. 이번 포스팅에서 cryptogen으로 organization과 orderer의 certificate을 만들고, configtxgen으로 channel config transaction을 만든 다음, channel 하나에 두 개의 organization이 있는 네트워크를 만들었다. Channel join은 해당 channel의 genesis block을 가지고 join하게 된다.

다음 시리즈에서는 이제 이 네트워크를 확장하고 싶다면? 어떻게 하면 좋을 지에 대해서 얘기해보겠다.

Hyperledger Fabric Configure Network – Network Overview

Hyperledger Fabric 네트워크 구축을 자유롭게 할 필요가 있어서 한 주간 찾으면서 공부했다. 공부해본 결과, 자료가 정말 없다. 이론적인 문서는 많은데 그것을 바탕으로 실제 네트워크를 구성하는데 레퍼런스가 될만한 것들이 정말 없었다. 그래도 고생하고 고생하며 노력한 끝에 이제 왠만큼 네트워크를 꾸릴 수 있게 되었다. 배운 것들을 정리한다는 생각으로 글을 써보기로 했다. 누군가에게 도움이 된다면 정말 더할나위 없을 것 같다.

다음과 같은 포스트를 작성할 예정이다.

  1. Network Overview
  2. byfn(Build Your First Network) 뜯어보기
  3. eyfn(Extend Your First Network) – Add New Org to Network
  4. Upgrade orderer from SOLO to Kafka
  5. No cryptogen!

Components of a Network

Hyperledger Fabric 네트워크는 다음과 같은 컴포넌트들로 구성된다.

  • Ledger (channel당 하나씩 있다. 그리고 blockchain과 state database로 구성된다.)
  • Smart Contract (chaincode)
  • Organizations, MSP
  • Peer nodes
  • Ordering services
  • Channel
  • Fabric CA

Transaction Flow


Transaction Proposal

각각의 컴포넌트들의 역할을 전체적인 흐름에서 파악하는 것이 더 이해하기 쉽다. 먼저 Client는 Application SDK에서 transaction proposal을 Endorsing Peer에게 날리게 된다. 어떤 Peer들이 endorser들이 되는지와 transaction이 valid한지 기준은 Endorsement Policy에 의해 결정된다. SmartContract의 역할을 하는 chaincode는 endorsement policy를 정의하고있다. Policy에 정의된 endorse peer들에게 Client는 무조건 transaction proposal을 보내야하며 그들의 endorse 여부를 모아야한다.

Proposal을 받은 Endorsing Peer들은 transaction을 ledger을 업데이트 시키지않고 chaincode 실제로 돌리면서 시뮬레이션해본다. 그리고 각 Endorsing Peer들은 시뮬레이션 결과를 RW Set 형태로 나오는데 이것을 endorse 할 지 reject 할 지의 응답과 함께 Application에 돌려준다. RW Set은 transaction을 시뮬레이션 하기 이전의 world state의 상태와 시뮬레이션 했을 때 그 결과 상태 두 가지 set을 말한다.

Submit to Ordering Service

만약 transaction이 endorse되었다면 ordering service에 보내게 된다. Ordering Service는 쉽게 생각하면 endorsed transaction queue라고 보면된다. 실제로는 여러 client들이 transaction 날리는데 이것을 하나로 queueing 해주는 것이다. 현재 Hyperledger Fabric에선 SOLO, Kafka 두 가지 방식을 지원한다. SOLO 방식은 production에서는 사용하지 말라고 doc에 명시하고 있다. 왜냐하면 ordering service node가 한 명이고 fault-tolerant하지 않다.

Broadcast Block

그리고 여기서 모아진 transaction들을 block으로 만들어서 anchor peer들에게 보내준다. Anchor peer들만 organization 내에서 block을 받을 수 있다. Anchor peer가 organization 내에 peer들에게 block들을 broadcast해준다. 마지막으로 block을 받은 peer들은 block validation을 거치고 나면 ledger에 저장하고 world state를 업데이트 시킨다. 그리고 transaction 성공여부를 client에게 알려준다.


그래서 위와 같은 전체적인 과정을 그려보면 다음과 같은 순서로 진행이 된다. Company에서 client를 이용해서 transaction을 날리면 바로 ledger에 저장하는 것이 아니라, 우선 endorse peer에게 endorse response를 수합해서 그것이 valid 하면 비로소 block으로 만들어질 수 있다. 또한 실제에서는 Company가 여러개이고, endorsed transaction들도 여러개가 날아올테니 그것을 ordering service를 이용해서 queueing하고 block으로 만들어서 전파하게된다. 다음 포스트에는 byfn 튜토리얼을 뜯어보면서 과정 하나하나가 어떤 의미인지 포스팅해보려고 한다.



How Java Pass Arguments

프로그래밍을 하면서 항상 method를 사용하고 거기에 관련된 arguments를 넘긴다. 그런데 어떻게 다른 method에 값들이 넘어가는지 메커니즘을 정확히 알지 못하면 가끔씩 미묘한 버그가 발생하기도 한다. 오늘 할 이야기는 Java에서 어떻게 arguments를 method로 넘기는지에 대해서다. Java를 공부해봤다면 한번 쯤 들어봤을 것 같다. 그리고 그것을 공부하면서 ‘음.. 그렇구나. 이해했으니 넘어가자’ 그러고 넘어갔다. 그리고 실제로 이해했다고 생각한 개념들에 대해서 제대로 된 깨달음을 얻을 때는 그와 관련된 버그때문에 고생하다 간신히 고쳤을 때일 것 같다!

문제가 발생했던 때는 Dijkstra’s Shortest Path Algorithm을 이용해서 Flight Scheduler를 만드는 중이었다. 나에게는 Flights들이 주어지고 그것을 이용해서 승객들의 출발지 공항부터 도착지 공항까지 최단 시간의 루트를 제공해주는 프로그램이다.

다음은 코드 중 일부이다. Shortest path를 가져온 뒤 Fringe Edge를 업데이트를 해주는 부분이다. 마지막으로 Edge weight를 업데이트한 뒤 Min-Heap에 집어 넣어준다. (이때 Min-Heap은 minutes을 기준으로 heapify된다.)

이렇게 Dijkstra’s Algorithm을 제대로 구현하고 동작시키면, 잘못된 경로가 나온다.

한참을 고생하다 Heap을 뜯어보았다. 그리고 문제의 실마리를 찾았다.

다음 결과에서 i=1의 element를 보고 머리가 번뜩였다. 두 element가 같은 주소를 가리키고 있구나!

Distance d = distanceMap.get(destination);에서 d는 새로운 주소에 변수를 할당받는 것이 아니라 Map에 있던 Distance를 가리키고 있는 것이다.

In Java, arguments are passed by value

먼저 Pass by value가 무엇일까. Pass by value는 어떤 arguments들이 method로 전달될 때 arguments들의 복사본이 전달되는 것이다. 그렇기 때문에 method 안에서 전달된 arguments들의 값을 아무리 바꾸어도 method 바깥의 variables들의 값은 그대로다.(복사한 것들을 method 안으로 넘겼기 때문에!)

이야기를 더 진행하기 전에 Java에서 arguments들이 어떻게 memory에 저장되는지에 대해서 알아보자. 먼저 Java에는 두 가지 종류의 변수 종류가 있다: primitivesobjects이다.

Primitive variables는 항상 stack에 저장된다. 하지만 Object의 경우 두 단계를 거쳐서 저장된다. 먼저 object의 실제 데이터가 Heap 영역에 저장되고 그 reference(pointer, Heap 영역의 주소)가 stack에 저장된다.

그렇다면 Java에서는 어떤 방식으로 arguments들이 전달될까?

Java에서는 항상 arguments들은 pass by value 형식으로 전달된다. 그래서 method를 호출할 때마다 다음과 같은 과정이 반복된다.

  • argument의 복사본들이 stack에 생성되고 그것의 복사본들을 method로 넘겨준다.
    • 만약에 argument가 primitive type이었다면, 단순하게 복사본을 stack에 생성하고 그것을 method안으로 넘겨준다.
    • 만약에 argument가 object type이라면, 그 reference(pointer, Heap 영역의 주소)를 stack에 저장하고 그것을 method에게 넘겨준다. 그렇기 때문에 method를 호출하기 전 argument로 넘어가는 variable과 method를 호출하면서 method로 넘어가는 variable은 같은 object data를 가리키고 있다.

two objects pointing to same heap address

그렇기 때문에 아까 발생한 문제는 위와 같은 그림으로 나타낼 수 있다. Map에 있는 Distance object와 get으로 얻은 Distance reference는 같은 Heap 영역을 가리키고 있다. 그래서 하나의 값을 바꾸면 다른 값도 변하게 된다.

그렇다면 어떻게 문제를 해결할 수 있을까? 바로 new를 이용해서 Heap영역에 새 메모리를 할당받아서 그곳을 가리키는 reference를 이용하면 될 것이다.


Java는 pass-by-value로 argument가 method에 전달된다. 또한 그 argument가 Object인 경우, 실제 data는 Heap영역에 저장한 후 address를 stack에 저장한다. 따라서 Object를 argument로 전달할 때는 data의 address를 전달하는 것이다.