15 ਦਸੰ 2025·5 ਮਿੰਟ
James Gosling, Java, ਅਤੇ “Write Once, Run Anywhere” ਦਾ ਉਠਾਣ
James Gosling ਦੀ Java ਅਤੇ “Write Once, Run Anywhere” ਨੇ ਐਂਟਰਪ੍ਰਾਈਜ਼ ਸਿਸਟਮ, ਟੂਲਿੰਗ ਅਤੇ ਆਧੁਨਿਕ ਬੈਕਐਂਡ ਅਭਿਆਸਾਂ ਨੂੰ ਕਿਵੇਂ ਪ੍ਰਭਾਵਿਤ ਕੀਤਾ—JVM ਤੋਂ ਕਲਾਉਡ ਤੱਕ।
ਇਸ ਪੋਸਟ ਵਿੱਚ ਕੀ ਆਵੇਗਾ (ਅਤੇ ਇਹ ਅੱਜ ਵੀ ਕਿਉਂ ਮਹੱਤਵਪੂਰਨ ਹੈ)
ਜਾਵਾ ਦਾ ਸਭ ਤੋਂ ਮਸ਼ਹੂਰ ਵਾਅਦਾ—“Write Once, Run Anywhere” (WORA)—ਬੈਕਐਂਡ ਟੀਮਾਂ ਲਈ ਸਿਰਫ਼ ਮਾਰਕੇਟਿੰਗ ਨਹੀਂ ਸੀ। ਇਹ ਇੱਕ ਪ੍ਰਯੋਗਤਮਕ ਦਾਅ ਸੀ: ਤੁਸੀਂ ਇੱਕ ਗੰਭੀਰ ਸਿਸਟਮ ਇੱਕ ਵਾਰੀ ਬਣਾਉਂਦੇ ਹੋ, ਵੱਖ-ਵੱਖ ਓਐਸਾਂ ਅਤੇ ਹਾਰਡਵੇਅਰ `ਤੇ ਡਿਪਲੌਇ ਕਰ ਸਕਦੇ ਹੋ, ਅਤੇ ਜਦੋਂ ਕੰਪਨੀ ਵਧਦੀ ਹੈ ਤਾਂ ਰੱਖ-ਰਖਾਅ ਅਸਾਨ ਰਹਿੰਦਾ ਹੈ।
ਇਹ ਪੋਸਟ ਦੱਸਦਾ ਹੈ ਕਿ ਉਹ ਦਾਅ ਕਿਵੇਂ ਕੰਮ ਕਰਦਾ ਸੀ, ਕੰਪਨੀਆਂ ਜਾਵਾ ਨੂੰ ਇੰਨੀ ਤੇਜ਼ੀ ਨਾਲ ਕਿਉਂ ਅਪਣਾਇਆ, ਅਤੇ 1990s ਵਿੱਚ ਕੀਤੇ ਫੈਸਲੇ ਅੱਜ ਦੇ ਬੈਕਐਂਡ ਵਿਕਾਸ—ਫਰੇਮਵਰਕ, ਬਿਲਡ ਟੂਲਜ਼, ਡਿਪਲੌਇਮੈਂਟ ਪੈਟਰਨ, ਅਤੇ ਲੰਮੇ ਸਮੇਂ ਚੱਲਣ ਵਾਲੇ ਪ੍ਰੋਡਕਸ਼ਨ ਸਿਸਟਮਾਂ—ਨੂੰ ਕਿਵੇਂ ਆਕਾਰ ਦਿੰਦੇ ਹਨ।
ਇਸ ਇਤਿਹਾਸ ਤੋਂ ਤੁਹਾਨੂੰ ਕੀ ਮਿਲੇਗਾ
ਅਸੀਂ James Gosling ਦੇ ਮੂਲ ਲੱਛਿਆਂ ਤੋਂ ਸ਼ੁਰੂ ਕਰਾਂਗੇ ਅਤੇ ਵੇਖਾਂਗੇ ਕਿ ਭਾਸ਼ਾ ਅਤੇ ਰਨਟਾਈਮ portability ਦੀਆਂ ਮੁਸ਼ਕਲਾਂ ਨੂੰ ਘਟਾਉਣ ਲਈ ਕਿਵੇਂ ਡਿਜ਼ਾਈਨ ਕੀਤੇ ਗਏ।
ਫਿਰ ਅਸੀਂ ਐਂਟਰਪ੍ਰਾਈਜ਼ ਕਹਾਣੀ ਨੂੰ ਫਾਲੋ ਕਰਾਂਗੇ: ਜਾਵਾ ਕਿਉਂ ਗਰੀਵਤਾ ਵਾਲਾ ਵਿਕਲਪ ਬਣਿਆ, ਐਪ ਸਰਵਰ ਅਤੇ ਐਂਟਰਪ੍ਰਾਈਜ਼ ਮਿਆਰ ਕਿਵੇਂ ਉਭਰੇ, ਅਤੇ ਟੂਲਿੰਗ (IDEਜ਼, ਬਿਲਡ ਆਟੋਮੇਸ਼ਨ, ਟੈਸਟਿੰਗ) ਕਿਵੇਂ ਇੱਕ ਸ਼ਕਤਿ ਵਧਾਉਣ ਵਾਲਾ ਤੱਤ ਬਣ ਗਿਆ।
ਅੰਤ ਵਿੱਚ, ਅਸੀਂ “ਕਲਾਸਿਕ” ਜਾਵਾ ਦੁਨੀਆਂ ਨੂੰ ਮੌਜੂਦਾ ਹਕੀਕਤਾਂ ਨਾਲ ਜੋੜਾਂਗੇ—Spring ਦਾ ਉਭਾਰ, ਕਲਾਉਡ ਡਿਪਲੌਇਮੈਂਟ, ਕಂಟੇਨਰ, Kubernetes, ਅਤੇ ਜਦੋਂ ਤੁਹਾਡੇ ਰਨਟਾਈਮ ਵਿੱਚ ਦਰਜਨਾਂ ਸਰਵਿਸز ਅਤੇ ਤੀਜੀ-ਪক্ষੀ ਨਿਰਭਰਤਾਵਾਂ ਹੁੰਦੀਆਂ ਹਨ ਤਾਂ “ਕਿਤੇ ਵੀ ਚਲਾਓ” ਦਾ ਅਸਲੀ ਮਤਲਬ ਕੀ ਹੁੰਦਾ ਹੈ।
ਮੁੱਖ ਸ਼ਬਦ (ਪੋਸਟ ਭਰ ਵਰਤੇ ਜਾਣਗੇ)
Portability/ਪੋਰਟੇਬਿਲਿਟੀ: ਉਹ ਸਮਰੱਥਾ ਕਿ ਇੱਕੋ ਪ੍ਰੋਗਰਾਮ ਵੱਖ-ਵੱਖ ਮਹੋਲਾਂ (Windows/Linux/macOS, ਵੱਖ-ਵੱਖ CPU ਕਿਸਮਾਂ) `ਤੇ ਬਿਨਾਂ ਜ਼ਿਆਦਾ ਬਦਲਾਅ ਦੇ ਚਲ ਸਕੇ।
JVM (Java Virtual Machine): ਉਹ ਰਨਟਾਈਮ ਜੋ ਜਾਵਾ ਪ੍ਰੋਗਰਾਮ ਚਲਾਉਂਦਾ ਹੈ। ਜਾਵਾ ਸਿੱਧਾ ਮਸ਼ੀਨ-ਸਪੀਸੀਫਿਕ ਕੋਡ `ਤੇ ਸਭਿਆਚਾਰ ਕਰਨ ਦੀ ਬਜਾਏ JVM ਨੂੰ ਟਾਰਗੇਟ ਕਰਦੀ ਹੈ।
Bytecode/ਬਾਈਟਕੋਡ: ਜਾਵਾ ਕੰਪਾਇਲਰ ਦੁਆਰਾ ਬਣਾਇਆ ਗਿਆ ਮੱਧਵਤੀ ਫਾਰਮੈਟ। ਇਹੀ ਉਹ ਮਕੈਨਿਜ਼ਮ ਹੈ ਜੋ WORA ਨੂੰ ਸਮਭਵ ਬਣਾਉਂਦਾ ਹੈ।
WORA ਅਜੇ ਵੀ ਮਾਇਨੇ ਰੱਖਦੀ ਹੈ ਕਿਉਂਕਿ ਬਹੁਤ ਸਾਰੀਆਂ ਬੈਕਐਂਡ ਟੀਮਾਂ ਅੱਜ ਵੀ ਉਹੀ ਤਰਜੀਹਾਂ ਤੋਲ ਰਹੀਆਂ ਹਨ: ਸਥਿਰ ਰਨਟਾਈਮ, ਭਵਿੱਖਬਾਣੀਯੋਗ ਡਿਪਲੌਇਮੈਂਟ, ਟੀਮ ਉਤਪਾਦਕਤਾ, ਅਤੇ ਉਹ ਸਿਸਟਮ ਜੋ ਦਸ਼ਕਾਂ ਤੱਕ ਚੱਲਣੇ ਲਾਜ਼ਮੀ ਹੁੰਦੇ ਹਨ।
James Gosling ਅਤੇ ਜਾਵਾ ਦੇ ਮੂਲ ਲਛੇ
ਜਾਵਾ ਨੂੰ ਅਕਸਰ James Gosling ਨਾਲ ਜੋੜਿਆ ਜਾਂਦਾ ਹੈ, ਪਰ ਇਹ ਕਦੇ ਵੀ ਇੱਕਲੌਤਾ ਯਤਨ ਨਹੀਂ ਸੀ। 1990s ਦੀ ਸ਼ੁਰੂਆਤ ਵਿੱਚ Sun Microsystems ਤੇ Gosling ਇੱਕ ਛੋਟੀ ਟੀਮ (ਜੋ ਆਮ ਤੌਰ 'ਤੇ “Green” ਪ੍ਰੋਜੈਕਟ ਕਹਾਂੀਦੀ ਸੀ) ਦੇ ਨਾਲ ਕੰਮ ਕਰ ਰਿਹਾ ਸੀ ਜਿਸਦਾ ਮਕਸਦ ਇਕ ਐਸੀ ਭਾਸ਼ਾ ਅਤੇ ਰਨਟਾਈਮ ਬਣਾਉਣਾ ਸੀ ਜੋ ਵੱਖ-ਵੱਖ ਡਿਵਾਈਸਾਂ ਅਤੇ ਓਪਰੇਟਿੰਗ ਸਿਸਟਮਾਂ ਤੇ ਬਿਨਾਂ ਮੁੜ-ਲਿਖੇ ਚੱਲ ਸਕੇ।
ਨਤੀਜਾ ਸਿਰਫ਼ ਨਵੀਂ ਸਿੰਟੈਕਸ ਨਹੀਂ ਸੀ—ਇਹ ਇੱਕ ਪੂਰਾ “ਪਲੇਟਫਾਰਮ” ਵਿਚਾਰ ਸੀ: ਇੱਕ ਭਾਸ਼ਾ, ਇੱਕ ਕੰਪਾਇਲਰ, ਅਤੇ ਇੱਕ ਵਰਚੁਅਲ ਮਸ਼ੀਨ ਜੋ ਮਿਲ ਕੇ ਸੋਫਟਵੇਅਰ ਨੂੰ ਘੱਟ ਅਣਧਿਆਨਤੀਆਂ ਨਾਲ ਸ਼ਿਪ ਕਰਨ ਯੋਗ ਬਣਾਉਂਦੇ।
ਲਛੇ: ਸੁਰੱਖਿਆ, ਪੋਰਟੇਬਿਲਿਟੀ, ਉਤਪਾਦਕਤਾ
ਸ਼ੁਰੂ ਤੋਂ ਹੀ ਜਾਵਾ ਨੂੰ ਕੁਝ ਵਿਆਵਹਾਰਿਕ ਉਦੇਸ਼ ਨੇ ਰੂਪ ਦਿੱਤਾ:
- ਸੁਰੱਖਿਆ ਅਤੇ ਭਰੋਸੇਯੋਗਤਾ: ਜਾਵਾ ਨੇ C/C++ ਵਿੱਚ ਵੇਖੇ ਜਾਂਦੇ ਆਮ ਕਰੈਸ਼ ਕਾਰਨਾਂ ਨੂੰ ਹਟਾਇਆ ਜਾਂ ਸੀਮਿਤ ਕੀਤਾ—ਖਾਸ ਕਰਕੇ ਡਾਇਰੈਕਟ ਪੌਇੰਟਰ-manipulation—ਅਤੇ ਰਨਟਾਈਮ ਚੈੱਕ ਜੋ ਅਚਾਨਕ ਖਰਾਬੀ ਦੀ ਥਾਂ ਪਛਾਣਯੋਗ ਤਰ੍ਹਾਂ fail ਕਰਨ ਨੂੰ ਤਰਜੀਹ ਦਿੰਦੇ ਹਨ।
- ਪੋਰਟੇਬਿਲਿਟੀ: ਕਿਸੇ CPU ਦੇ ਮਸ਼ੀਨ ਕੋਡ
ਤੇ ਸੀਧਾ ਕੰਪਾਇਲ ਕਰਨ ਦੀ ਥਾਂ, ਜਾਵਾ **ਬਾਈਟਕੋਡ**ਤੇ ਕੰਪਾਇਲ ਹੁੰਦਾ ਹੈ ਜੋ ਇੱਕ ਸਮਰੂਪ JVM `ਤੇ ਚੱਲਦਾ ਹੈ। ਇਸ ਫੈਸਲੇ ਨੇ “ਕ੍ਰਾਸ-ਪਲੇਟਫਾਰਮ” ਨੂੰ ਸ਼ਰਤਾਂ ਲਿਖ ਕੇ ਨਹੀਂ, ਬਲਕਿ ਇੱਕ ਸਥਿਰ ਰਨਟਾਈਮ ਕੰਟਰੈਕਟ ਰਾਹੀਂ ਹਲ ਕੀਤਾ। - ਡਿਵੈਲਪਰ ਉਤਪਾਦਕਤਾ: ਜਾਵਾ ਦਾ ਮਕਸਦ ਰੋਜ਼ਾਨਾ ਪ੍ਰੋਗਰਾਮਿੰਗ ਨੂੰ ਤੇਜ਼ ਅਤੇ ਘੱਟ ਗਲਤੀਆਂ ਵਾਲਾ ਬਣਾਉਣਾ ਸੀ—ਇਹ ਇੱਕ ਮਿਆਰੀ ਲਾਇਬ੍ਰੇਰੀ, ਇੱਕਸਾਰ ਟੂਲਿੰਗ ਉਮੀਦਾਂ, ਅਤੇ ਆਟੋਮੈਟਿਕ ਮੈਮੋਰੀ ਮੈਨੇਜਮੈਂਟ ਰਾਹੀਂ ਕੀਤਾ ਗਿਆ।
ਇਹ ਸਿਧਾਂਤ ਅਕੈਡਮਿਕ ਨਹੀਂ ਸਨ; ਇਹ ਅਸਲ ਖ਼ਰਚਿਆਂ ਦੇ ਪ੍ਰਤੀਕ੍ਰਿਆਵਾਂ ਸਨ: ਮੈਮੋਰੀ ਦੀਆਂ ਸਮੱਸਿਆਵਾਂ ਨੂੰ ਡੀਬੱਗ ਕਰਨ, ਕਈ ਪਲੇਟਫਾਰਮ-ਵਿਸ਼ੇਸ਼ ਬਿਲਡਾਂ ਨੂੰ ਸੰਭਾਲਣ, ਅਤੇ ਟੀਮਾਂ ਨੂੰ ਜਟਿਲ ਕੋਡਬੇਸਾਂ 'ਤੇ ਓਨਬੋਰਡ ਕਰਨ ਦੇ ਖਰਚੇ।
“Write Once, Run Anywhere” ਦਾ ਅਰਥ ਕੀ ਸੀ (ਅਤੇ ਕੀ ਨਹੀਂ ਸੀ)
ਅਮਲ ਵਿੱਚ, WORA ਦੇ ਮਤਲਬ ਸੀ:
- ਜੇ ਤੁਸੀਂ JVM ਨੂੰ ਟਾਰਗੇਟ ਕਰਦੇ ਹੋ, ਤਾਂ ਤੁਸੀਂ ਆਮ ਤੌਰ
ਤੇ **ਓਹੀ ਬਾਈਟਕੋਡ** ਵੱਖ-ਵੱਖ ਓਐਸਾਂਤੇ ਸ਼ਿਪ ਕਰ ਸਕਦੇ ਹੋ। - ਤੁਹਾਨੂੰ ਹੰਨੇ ਵੀ ਮਹੋਲ ਦੇ ਫਰਕ ਸੰਭਾਲਣੇ ਪੈਂਦੇ ਹਨ: ਫਾਇਲ ਪਾਥ, ਲੋਕਲਾਈਜ਼ੇਸ਼ਨ ਬਿਹੇਵਿਅਰ, ਨੈੱਟਵਰਕਿੰਗ ਖ਼ਾਸੀਅਤਾਂ, ਨੈਟਿਵ ਇੰਟੀਗ੍ਰੇਸ਼ਨ, ਅਤੇ ਡਿਪਲੌਇਮੈਂਟ ਪੈਕੇਜਿੰਗ।
ਇਸ ਲਈ ਨਾਅਰਾ “ਜਾਦੂਈ ਪੋਰਟੇਬਿਲਿਟੀ” ਨਹੀਂ ਸੀ। ਇਹ ਪੋਰਟੇਬਿਲਿਟੀ ਦਾ ਢਾਂਚਾ ਬਦਲਣ ਦਾ ਤਰੀਕਾ ਸੀ: ਹਰ-ਪਲੇਟਫਾਰਮ ਰੀਰਾਈਟ ਦੀ ਥਾਂ ਇੱਕ ਮਿਆਰਬੱਧ ਰਨਟਾਈਮ ਅਤੇ ਲਾਇਬ੍ਰੇਰੀਆਂ ਵੱਲ।
WORA ਕਿਵੇਂ ਕੰਮ ਕਰਦਾ ਹੈ: ਬਾਈਟਕੋਡ ਅਤੇ JVM
WORA ਇੱਕ ਕੰਪਾਇਲੇਸ਼ਨ ਅਤੇ ਰਨਟਾਈਮ ਮਾਡਲ ਹੈ ਜੋ ਬਿਲਡ ਕਰਨ ਅਤੇ ਚਲਾਉਣ ਨੂੰ ਵੱਖ ਕਰਦਾ ਹੈ।
ਸੋਰਸ ਕੋਡ → ਬਾਈਟਕੋਡ → JVM ਤੱਕ ਕਾਰਵਾਈ
ਜਾਵਾ ਸੋਰਸ ਫਾਇਲਾਂ (.java) ਨੂੰ javac ਦੁਆਰਾ ਬਾਈਟਕੋਡ (.class ਫਾਇਲਾਂ) ਵਿੱਚ ਕੰਪਾਇਲ ਕੀਤਾ ਜਾਂਦਾ ਹੈ। ਬਾਈਟਕੋਡ ਇੱਕ ਸੰਕੁਚਿਤ, ਮਿਆਰੀ ਨਿਰਦੇਸ਼ ਸੈੱਟ ਹੈ ਜੋ ਚਾਹੇ ਤੁਸੀਂ Windows, Linux, ਜਾਂ macOS `ਤੇ ਕੰਪਾਇਲ ਕੀਤਾ ਹੋਵੇ—ਸਮਾਨ ਰਹਿੰਦਾ ਹੈ।
ਰਨਟਾਈਮ 'ਤੇ, JVM ਉਹ ਬਾਈਟਕੋਡ ਲੋਡ ਕਰਦਾ ਹੈ, ਇਸਦੀ ਵੈਰੀਫਿਕੇਸ਼ਨ ਕਰਦਾ ਹੈ, ਅਤੇ ਇਹਨੂੰ ਚਲਾਂਦਾ ਹੈ। ਚਲਾਉਣਾ interpret ਵੀ ਹੋ ਸਕਦਾ ਹੈ, ਜਾਂ ਦੌਰਾਨ-ਦੌਰਾਨ ਕੰਪਾਇਲ ਹੋ ਸਕਦਾ ਹੈ, ਜਾਂ ਦੋਹਾਂ ਦਾ ਮਿਸ਼ਰਣ ਹੋਵੇ—JVM ਅਤੇ ਵਰਕਲੋਡ 'ਤੇ ਨਿਰਭਰ ਕਰਕੇ।
JVM ਇੱਕ OS/CPU “ਐਡਾਪਟਰ” ਵਾਂਗ
ਇਸ ਦੀ ਥਾਂ ਕਿ ਹਰ ਟਾਰਗੇਟ CPU ਅਤੇ ਓਐਸ ਲਈ ਬਿਲਡ ਸਮੇਂ ਮਸ਼ੀਨ ਕੋਡ ਬਣਾਇਆ ਜਾਵੇ, ਜਾਵਾ JVM ਨੂੰ ਟਾਰਗੇਟ করে। ਹਰ ਪਲੇਟਫਾਰਮ ਆਪਣੀ JVM ਇੰਪਲੀਮੈਂਟੇਸ਼ਨ ਦਿੰਦਾ ਹੈ ਜੋ ਜਾਣਦੀ ਹੈ ਕਿ ਕਿਵੇਂ:
- ਬਾਈਟਕੋਡ ਨੂੰ ਲੋਕਲ CPU ਲਈ ਨੈਟਿਵ ਨਿਰਦੇਸ਼ਾਂ ਵਿੱਚ ਤਬਦੀਲ ਕਰਨਾ
- ਲੋਕਲ ਓਪਰੇਟਿੰਗ ਸਿਸਟਮ ਨਾਲ ਇੰਟਰੈਕਟ ਕਰਨਾ (ਫਾਇਲ, ਨੈੱਟਵਰਕਿੰਗ, ਧਾਗੇ)
ਇਹ ਐਬਸਟ੍ਰੈਕਸ਼ਨ ਮੁੱਖ ਵਪਾਰ ਹੈ: ਤੁਹਾਡੀ ਐਪਲੀਕੇਸ਼ਨ ਇੱਕ ਸਥਿਰ ਰਨਟਾਈਮ ਨਾਲ ਗੱਲ ਕਰਦੀ ਹੈ, ਅਤੇ ਰਨਟਾਈਮ ਮਸ਼ੀਨ ਨਾਲ ਗੱਲ ਕਰਦਾ ਹੈ।
ਰਨਟਾਈਮ ਚੈੱਕ ਅਤੇ ਮੈਮੋਰੀ ਮੈਨੇਜਮੈਂਟ
ਪੋਰਟੇਬਿਲਿਟੀ ਨੂੰ ਰਨਟਾਈਮ 'ਤੇ ਲਾਗੂ ਕੀਤੀਆਂ ਗਈਆਂ ਗਾਰੰਟੀ ਵਿਰੋਧੀ ਸੁਰੱਖਿਆ ਚੈੱਕ ਵੀ ਸਹਾਇਕ ਹੁੰਦੇ ਹਨ। JVM ਬਾਈਟਕੋਡ ਵੈਰੀਫਿਕੇਸ਼ਨ ਅਤੇ ਹੋਰ ਚੈੱਕ ਕਰਦਾ ਹੈ ਜੋ ਅਸੁਰੱਖਿਅਤ ਓਪਰੇਸ਼ਨਾਂ ਨੂੰ ਰੋਕਣ ਵਿੱਚ ਮਦਦ ਕਰਦੇ ਹਨ।
ਅਤੇ ਡਿਵੈਲਪਰਾਂ ਨੂੰ ਮੈਨੁਅਲ ਤੌਰ 'ਤੇ ਮੈਮੋਰੀ ਆਲੋਕੇਟ ਅਤੇ ਫ੍ਰੀ ਕਰਨ ਦੀ ਲੋੜ ਦੇਣ ਦੀ ਥਾਂ, JVM ਆਟੋਮੈਟਿਕ ਮੈਮੋਰੀ ਮੈਨੇਜਮੈਂਟ (ਗਾਰਬੇਜ ਕਲੀਕਸ਼ਨ) ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ, ਜਿਸ ਨਾਲ ਪਲੇਟਫਾਰਮ-ਵਿਸ਼ੇਸ਼ ਕਰੈਸ਼ ਅਤੇ "works on my machine" ਬੱਗਸ ਘੱਟ ਹੁੰਦੇ ਹਨ।
ਇਹ ਕਿਉਂ ਵੱਡੀਆਂ ਫਲੀਟਾਂ 'ਤੇ ਡਿਪਲੌਇਮੈਂਟ ਨੂੰ ਸਿਦਾ ਕੀਤਾ
ਮਿਕਸਡ ਹਾਰਡਵੇਅਰ ਅਤੇ ਓਐਸਾਂ ਚਲਾਉਂਦੀਆਂ ਐਂਟਰਪ੍ਰਾਈਜ਼ਾਂ ਲਈ, ਨਤੀਜਾ ਓਪਰੇਸ਼ਨਲ ਸੀਧਾ ਸੀ: ਇੱਕੋ ਹੀ ਆਰਟੀਫੈਕਟ (JARs/WARs) ਵੱਖ-ਵੱਖ ਸਰਵਰਾਂ `ਤੇ ਭੇਜੋ, ਇੱਕ JVM ਵਰਜਨ ਤੇ ਮਿਆਰੀਕਰਨ ਕਰੋ, ਅਤੇ ਚੌੜੇ ਤੌਰ 'ਤੇ ਇੱਕਸਾਰ ਬਿਹੇਵਿਅਰ ਦੀ ਉਮੀਦ ਰੱਖੋ। WORA ਸਾਰੀਆਂ ਪੋਰਟੇਬਿਲਿਟੀ ਸਮੱਸਿਆਵਾਂ ਨਹੀਂ ਹਟਾਂਦਾ, ਪਰ ਇਹਨਾਂ ਨੂੰ ਘਟਾ ਦਿੰਦਾ—ਜਿਸ ਨਾਲ ਵੱਡੇ ਪੈਮਾਨੇ 'ਤੇ ਡਿਪਲੌਇਮੈਂਟ ਆਟੋਮੇਟ ਕਰਨ ਅਤੇ ਰੱਖ-ਰਖਾਅ ਅਸਾਨ ਹੋ ਜਾਂਦਾ ਹੈ।
ਐਂਟਰਪ੍ਰਾਈਜ਼ਾਂ ਨੇ ਜਾਵਾ ਕਿਉਂ ਤੇਜ਼ੀ ਨਾਲ ਅਪਣਾ ਲਿਆ
1990s ਦੇ ਆਖ਼ਿਰ ਅਤੇ 2000s ਦੀ ਸ਼ੁਰੂਆਤ ਵਿੱਚ ਐਂਟਰਪ੍ਰਾਈਜ਼ਾਂ ਕੋਲ ਇੱਕ ਨਿਸ਼ਚਤ ਚਾਹ ਸੀ: ਉਹ ਸਿਸਟਮ ਜੋ ਸਾਲਾਂ ਤੱਕ ਚੱਲ ਸਕਣ, ਕਰਮਚਾਰੀ ਬਦਲਾਉ ਨੂੰ ਸਹਿਣ ਕਰਨ ਅਤੇ ਇੱਕ ਗੁੰਝਲਦਾਰ ਮਿਲੀ-ਜੁਲੀ UNIX ਬਾਕਸਾਂ, Windows ਸਰਵਰਾਂ ਅਤੇ ਹੋਰ ਹਾਰਡਵੇਅਰ 'ਤੇ ਡਿਪਲੌਇ ਹੋ ਸਕਣ।
ਜਾਵਾ ਇੱਕ ਅਸਾਧਾਰਣ ਐਂਟਰਪ੍ਰਾਈਜ਼-ਫ੍ਰੈਂਡਲੀ ਕਹਾਣੀ ਲੈ ਕੇ ਆਇਆ: ਟੀਮਾਂ ਇੱਕ ਵਾਰੀ ਬਿਲਡ ਕਰ ਸਕਦੀਆਂ ਸਨ ਅਤੇ ਗਹਿਰਾਈ ਵਾਲੇ ਵੱਖਰੇ ਮਹੋਲਾਂ `ਚ ਮੁੱਖ ਤੌਰ 'ਤੇ ਇੱਕੋ ਵਰਤੀਵਾਰ ਦੀ ਉਮੀਦ ਰੱਖ ਸਕਦੀਆਂ ਸਨ—ਵੱਖ-ਵੱਖ ਓਐਸਾਂ ਲਈ ਵੱਖਰੇ ਕੋਡਬੇਸ ਬਣਾਉਣ ਦੀ ਲੋੜ ਨਹੀਂ।
ਘੱਟ ਮੁੜ-ਲਿਖਾਵਟ, ਘੱਟ QA ਚੱਕਰ
ਜਾਵਾ ਤੋਂ ਪਹਿਲਾਂ, ਐਪਲੀਕੇਸ਼ਨ ਨੂੰ ਪਲੇਟਫਾਰਮ-ਦਰ-ਪਲੇਟਫਾਰਮ ਪਰਿਵਰਤਨ ਲਈ ਅਕਸਰ ਪਲੇਟਫਾਰਮ-ਨਿਰਭਰ ਹਿੱਸਿਆਂ ਨੂੰ ਮੁੜ ਲਿਖਣਾ ਪੈਂਦਾ ਸੀ (ਧਾਗੇ, ਨੈੱਟਵਰਕਿੰਗ, ਫਾਇਲ ਪਾਥ, UI ਟੂਲਕਿਟ, ਅਤੇ ਕੰਪਾਇਲਰ ਫਰਕ)। ਹਰ ਮੁੜ-ਲਿਖਾਵਟ ਨਾਲ ਟੈਸਟਿੰਗ ਦਿਸ਼ਾਵਾਂ ਦਾ ਗੁਣਾ ਹੋ ਜਾਂਦਾ—ਅਤੇ ਐਂਟਰਪ੍ਰਾਈਜ਼ ਟੈਸਟਿੰਗ ਮਹਿੰਗੀ ਹੁੰਦੀ ਹੈ ਕਿਉਂਕਿ ਇਸ ਵਿੱਚ ਰਿਗ੍ਰੈਸ਼ਨ ਸੂਟ, ਕੰਪਲਾਇੰਸ ਜਾਂਚਾਂ ਅਤੇ "ਇਹ_PAYROLL ਨਹੀਂ ਟੁੱਟਣਾ ਚਾਹੀਦਾ" ਜਿਹੀ ਸਾਵਧਾਨੀ ਸ਼ਾਮਲ ਹੁੰਦੀ ਹੈ।
ਜਾਵਾ ਨੇ ਇਸ ਚੱਕਰ ਨੂੰ ਘਟایا। ਕਈ ਸੰਸਥਾਵਾਂ ਇੱਕੋ ਬਿਲਡ ਆਰਟੀਫੈਕਟ ਅਤੇ ਇੱਕ ਸਥਿਰ ਰਨਟਾਈਮ `ਤੇ ਮਿਆਰੀਕਰਨ ਕਰ ਸਕਦੀਆਂ ਸਨ, ਜਿਸ ਨਾਲ QA ਖਰਚੇ ਘੱਟ ਹੋਏ ਅਤੇ ਲੰਮੇ ਜੀਵਨਚੱਕਰ ਦੀ ਯੋਜਨਾ ਕਰਨਾ ਵਾਸਤੇ ਜ਼ਿਆਦਾ ਯਥਾਰਥਪੂਰਨ ਹੋ ਗਿਆ।
ਇੱਕੋ ਤਰ੍ਹਾਂ ਵਰਤੋਂ ਵਾਲੀ ਸਟੈਂਡਰਡ ਲਾਇਬ੍ਰੇਰੀ
ਪੋਰਟੇਬਿਲਿਟੀ ਸਿਰਫ਼ ਇੱਕੋ ਕੋਡ ਚਲਾਉਣ ਬਾਰੇ ਨਹੀਂ—ਇਹ ਇੱਕੋ ਰਵੱਈਏ 'ਤੇ ਨਿਰਭਰ ਕਰਨ ਬਾਰੇ ਵੀ ਹੈ। ਜਾਵਾ ਦੀਆਂ ਸਟੈਂਡਰਡ ਲਾਇਬ੍ਰੇਰੀਆਂ ਇੱਕ ਸਥਿਰ ਬੇਸਲਾਈਨ ਦਿੰਦੀਆਂ ਹਨ ਜਿਵੇਂ:
- ਨੈੱਟਵਰਕਿੰਗ ਅਤੇ ਵੈੱਬ ਪਰੋਟੋਕੋਲ
- ਡੇਟਾਬੇਸ ਕਨੈਕਟਿਵਿਟੀ (JDBC ਅਤੇ ਵੇਂਡਰ ਡ੍ਰਾਈਵਰਾਂ ਰਾਹੀਂ)
- ਸੁਰੱਖਿਆ ਪ੍ਰਿਮਿਟਿਵਜ਼
- ਧਾਗੇ ਅਤੇ concurrency ਬਿਲਡਿੰਗ ਬਲਾਕ
ਇਹ ਇੱਕਸਾਰਤਾ ਟੀਮਾਂ ਲਈ ਸਾਂਝੀ ਪ੍ਰਥਾਵਾਂ ਬਣਾਉਣ, ਡਿਵੈਲਪਰਾਂ ਨੂੰ onboard ਕਰਨ, ਅਤੇ ਤੀਜੀ-ਪੱਖੀ ਲਾਇਬ੍ਰੇਰੀਆਂ ਅਪਣਾਉਣ ਵਿੱਚ ਘੱਟ ਅਚੰਭੇ ਲਿਆਉਂਦੀ ਹੈ।
ਜਿੱਥੇ ਪੋਰਟੇਬਿਲਿਟੀ ਫੇਲ ਹੁੰਦੀ ਹੈ
"ਇੱਕ ਵਾਰੀ ਲਿਖੋ" ਦੀ ਕਹਾਣੀ ਪੂਰਨ ਨਹੀਂ ਸੀ। ਪੋਰਟੇਬਿਲਿਟੀ ਟੁੱਟ ਸਕਦੀ ਹੈ ਜਦ ਟੀਮਾਂ ਨਿਰਭਰ ਹੋਣ:
- ਨੈਟਿਵ ਲਾਇਬ੍ਰੇਰੀਆਂ (JNI) ਉੱਤੇ ਹਾਰਡਵੇਅਰ ਇੰਟੀਗ੍ਰੇਸ਼ਨ ਜਾਂ ਲੈਗੇਸੀ ਕੋਡ ਲਈ
- ਓਪਰੇਟਿੰਗ ਸਿਸਟਮ-ਵਿਸ਼ੇਸ਼ ਫਾਇਲ ਸਿਸਟਮ ਖ਼ਾਸੀਅਤਾਂ, ਫੌਂਟਸ, ਜਾਂ ਲੋਕਲਾਈਜ਼ੇਸ਼ਨ ਬਿਹੇਵਿਅਰ
- ਵੇਂਡਰ-ਵਿਸ਼ੇਸ਼ ਡੇਟਾਬੇਸ ਜਾਂ ਐਪਲੀਕੇਸ਼ਨ ਸਰਵਰ ਫੀਚਰ
ਫਿਰ ਵੀ, ਜਾਵਾ ਅਕਸਰ ਸਮੱਸਿਆ ਨੂੰ ਇੱਕ ਛੋਟਾ, ਪਰ ਪਰਿਭਾਸ਼ਿਤ ਐਜ਼ਜ਼ `ਤੇ ਲਿਆਉਂਦਾ—ਬਜਾਏ ਇਸਦੇ ਕਿ ਪੂਰੀ ਐਪਲੀਕੇਸ਼ਨ ਪਲੇਟਫਾਰਮ-ਨਿਰਭਰ ਹੋ ਜਾਵੇ।
ਐਂਟਰਪ੍ਰਾਈਜ਼ ਪਲੇਟਫਾਰਮ: ਐਪ ਸਰਵਰ ਅਤੇ Jakarta EE
ਜਦੋਂ ਜਾਵਾ ਡੈੱਸਕਟਾਪ ਤੋਂ ਕਾਰਪੋਰੇਟ ਡੇਟਾ ਸੈਂਟਰਾਂ `ਚ ਆਇਆ, ਟੀਮਾਂ ਨੂੰ ਸਿਰਫ਼ ਭਾਸ਼ਾ ਅਤੇ JVM ਦੀ ਲੋੜ ਨਹੀਂ ਸੀ—ਉਹਨਾਂ ਨੂੰ ਇੱਕ ਪੇਸ਼ਗੌਇਤ ਤਰੀਕੇ ਨਾਲ ਸ਼ੇਅਰ ਕੀਤੀ ਪਿੱਠੇ-ਪੱਖੀ ਸਮਰੱਥਾਵਾਂ ਨੂੰ ਡਿਪਲੌਇ ਅਤੇ ਆਪਰੇਟ ਕਰਨ ਲਈ ਇਕ ਮਾਡਲ ਚਾਹੀਦਾ ਸੀ। ਇਸ ਮੰਗ ਨੇ ਐਪਲੀਕੇਸ਼ਨ ਸਰਵਰ ਜਿਵੇਂ WebLogic, WebSphere, JBoss (ਅਤੇ ਹਲਕੇ ਪਾਸੇ servlet ਕੰਟੇਨਰ ਜਿਵੇਂ Tomcat) ਦੇ ਉਭਾਰ ਨੂੰ ਤੇਜ਼ ਕੀਤਾ।
ਸਟੈਂਡਰਡ ਡਿਪਲੌਇਮੈਂਟ (WAR/EAR)
ਐਪ ਸਰਵਰ ਦੇ ਤੁਰੰਤ ਫੈਲਣ ਦਾ ਇੱਕ ਕਾਰਨ ਮਿਆਰੀਕ੍ਰਿਤ ਪੈਕੇਜਿੰਗ ਅਤੇ ਡਿਪਲੌਇਮੈਂਟ ਦਾ ਵਾਅਦਾ ਸੀ। ਹਰ ਵਾਤਰਾਸ਼ਟ ਨੂੰ ਇੱਕ ਕਸਟਮ ਇੰਸਟਾਲ ਸਕ੍ਰਿਪਟ ਭੇਜਣ ਦੀ ਥਾਂ, ਟੀਮਾਂ ਇੱਕ ਐਪਲੀਕੇਸ਼ਨ ਨੂੰ WAR (web archive) ਜਾਂ EAR (enterprise archive) ਵਜੋਂ ਬੰਡਲ ਕਰਦੇ ਅਤੇ ਇੱਕ ਸਰਵਰ `ਤੇ ਦੀਯਾ ਮਾਡਲ ਨਾਲ ਡਿਪਲੌਇ ਕਰਦੇ।
ਉਸ ਮਾਡਲ ਦਾ ਮਹੱਤਵ ਐਂਟਰਪ੍ਰਾਈਜ਼ਾਂ ਲਈ ਇਸ ਗੱਲ ਵਿੱਚ ਸੀ ਕਿ ਇਹ concerns ਵੱਖ ਕਰਦਾ ਸੀ: ਡਿਵੈਲਪਰ ਬਿਜ਼ਨਸ ਕੋਡ ਤੇ ਧਿਆਨ ਦਿੰਦਿਆਂ, ਅਪਰੇਸ਼ਨਜ਼ ਐਪ ਸਰਵਰ ਤੇ ਕਾਨਫਿਗਰੇਸ਼ਨ, ਸੁਰੱਖਿਆ ਇੰਟੀਗ੍ਰੇਸ਼ਨ, ਅਤੇ ਲਾਈਫਸਾਈਕਲ ਮੈਨੇਜਮੈਂਟ ਨਿਰਭਰ ਕਰ ਸਕਦੇ ਸਨ।
ਐਂਟਰਪ੍ਰਾਈਜ਼ ਪੈਟਰਨ ਜੋ ਹਰ ਕਿਸੇ ਨੂੰ ਚਾਹੀਦੇ ਸਨ
ਐਪ ਸਰਵਰ ਨੇ ਕੁਝ ਪੈਟਰਨ ਪ੍ਰਸਿੱਧ ਕੀਤੇ ਜੋ ਲਗਭਗ ਹਰ ਗੰਭੀਰ ਬਿਜ਼ਨਸ ਸਿਸਟਮ 'ਚ ਮਿਲਦੇ ਹਨ:
- ਟ੍ਰਾਂਜ਼ੈਕਸ਼ਨਜ਼: ਕਈ ਕਦਮਾਂ ਵਾਲੀਆਂ ਕਾਰਵਾਈਆਂ (ਅਕਸਰ ਡੇਟਾਬੇਸ ਅਤੇ ਸਰਵਿਸਜ਼ 'ਚ) ਨੂੰ ਏਸ ਤਰ੍ਹਾਂ ਕੋਆਰਡੀਨੇਟ ਕਰਨਾ ਕਿ ਫੇਲ ਹੋਣ 'ਤੇ ਡੇਟਾ ਅਧੂਰਾ ਨਾ ਰਹੇ।
- ਮੇਸੇਜਿੰਗ: ਕਤਾਰਾਂ ਅਤੇ ਟਾਪਿਕਾਂ ਰਾਹੀਂ ਅਸਿੰਕ੍ਰੋਨਸ ਕੰਮ, ਜੋ ਟ੍ਰੈਫਿਕ ਸਪੀਕਸ ਨੂੰ ਸਮਤੋਲ ਕਰਦਾ ਅਤੇ ਸਿਸਟਮਾਂ ਨੂੰ ਡਿਕਪਲ ਕਰਦਾ।
- ਕਨੈਕਸ਼ਨ ਪੂਲਿੰਗ: ਮਹਿੰਗੇ ਡੇਟਾਬੇਸ ਕਨੈਕਸ਼ਨਾਂ ਦਾ ਦੁਬਾਰਾ ਉਪਯੋਗ ਕਰਨ ਦੀ ਪ੍ਰਣਾਲੀ ਇਸ ਤਰ੍ਹਾਂ ਕਿ ਹਰ ਰਿਕਵੈਸਟ ਲਈ ਨਵਾਂ ਕਨੈਕਸ਼ਨ ਨਹੀਂ ਖੁਲਦਾ।
ਇਹ "ਨਾਈਸ-ਟੂ-ਹੈਵ" ਨਹੀਂ ਸਨ—ਇਹ ਭੁਗਤਾਨ ਪ੍ਰਵਾਹ, ਆਰਡਰ ਪ੍ਰੋਸੈਸਿੰਗ, ਸਟੌਕ ਅਪਡੇਟ, ਅਤੇ ਅੰਦਰੂਨੀ ਵਰਕਫ਼ਲੋਜ਼ ਲਈ ਲਾਜ਼ਮੀ ਪਾਈਪਲਾਈਨ ਸਨ।
servlets/JSP ਤੋਂ ਆਧੁਨਿਕ ਵੈੱਬ ਬੈਕਐਂਡ ਤੱਕ
servlet/JSP ਯੁੱਗ ਇੱਕ ਮਹੱਤਵਪੂਰਨ ਪੁਲ ਸੀ। Servlets ਨੇ ਇੱਕ ਸਟੈਂਡਰਡ ਰਿਕਵੈਸਟ/ਰਿਸਪਾਂਸ ਮਾਡਲ ਸਥਾਪਿਤ ਕੀਤਾ, ਜਦਕਿ JSP ਨੇ ਸਰਵਰ-ਸਾਈਡ HTML ਜਨਰੇਸ਼ਨ ਨੂੰ ਆਸਾਨ ਬਣਾਇਆ।
ਹਾਲਾਂਕਿ ਉਦਯੋਗ ਬਾਅਦ ਵਿੱਚ APIs ਅਤੇ ਫਰੰਟ-ਐਂਡ ਫਰੇਮਵਰਕ ਵੱਲ ਵੱਲ ਵਧਿਆ, servlets ਨੇ ਅੱਜ ਦੇ ਵੈੱਬ ਬੈਕਐਂਡ ਲਈ ਅਧਾਰ ਰੱਖਿਆ: ਰਾਊਟਿੰਗ, ਫਿਲਟਰ, ਸੈਸ਼ਨ, ਅਤੇ ਇੱਕਸਾਰ ਡਿਪਲੌਇਮੈਂਟ।
Jakarta EE ਇੱਕ ਮਿਆਰਕਰਨ ਯਤਨ ਵਜੋਂ
ਵੇਲੇ ਨਾਲ, ਇਹ ਸਮਰੱਥਾਵਾਂ J2EE, ਬਾਅਦ ਵਿੱਚ Java EE, ਅਤੇ ਹੁਣ Jakarta EE ਵਜੋਂ ਰੂਪਾਂਤਰਿਤ ਹੋ ਗਈਆਂ: ਐਂਟਰਪ੍ਰਾਈਜ਼ ਜਾਵਾ APIਜ਼ ਲਈ ਇੱਕ ਸੈਟ ਸਪੈਸੀਫਿਕੇਸ਼ਨ। Jakarta EE ਦੀ ਕੀਮਤ ਇਹ ਹੈ ਕਿ ਇਹ ਇਮਪਲੀਮੈਂਟੇਸ਼ਨਾਂ ਵਿੱਚ ਇੰਟਰਫੇਸ ਅਤੇ ਬਿਹੇਵਿਅਰ ਨੂੰ ਮਿਆਰੀਕ੍ਰਿਤ ਕਰਦੀ ਹੈ, ਤਾਂ ਜੋ ਟੀਮਾਂ ਇੱਕ ਜਾਣੇ-ਪਛਾਣੇ ਕਾਂਟ੍ਰੈਕਟ `ਤੇ ਬਿਲਡ ਕਰ ਸਕਣ ਬਜਾਏ ਕਿਸੇ ਇੱਕ ਵੇਂਡਰ ਦੇ ਪ੍ਰੋਪ੍ਰਾਇਟਰੀ ਸਟੈਕ ਦੇ।
ਪ੍ਰਦਰਸ਼ਨ: JIT, GC, ਅਤੇ ਪੋਰਟੇਬਿਲਿਟੀ ਦੀ ਕੀਮਤ
ਬਿਲਡ ਤੋਂ ਪਹਿਲਾਂ ਡਿਜ਼ਾਇਨ ਕਰੋ
ਕੋਡ ਜਨਰੇਟ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ Planning Mode ਨਾਲ ਐਂਡਪੋਇੰਟ, ਡੇਟਾ ਅਤੇ ਟਾਸਕ ਨਕਸ਼ਾ ਕਰੋ।
ਜਾਵਾ ਦੀ ਪੋਰਟੇਬਿਲਿਟੀ ਨੇ ਇੱਕ ਸਵਾਲ ਉਠਾਇਆ: ਜੇ ਇੱਕੋ ਪ੍ਰੋਗਰਾਮ ਬਹੁਤ ਵੱਖ-ਵੱਖ ਮਸ਼ੀਨਾਂ `ਤੇ ਚੱਲ ਸਕਦਾ ਹੈ, ਤਾਂ ਇਹ ਤੇਜ਼ ਕਿਵੇਂ ਹੋ ਸਕਦਾ ਹੈ? ਜਵਾਬ ਉਹਨਾਂ ਰਨਟਾਈਮ ਤਕਨੀਕਾਂ ਦਾ ਸਮੂਹ ਹੈ ਜਿਨ੍ਹਾਂ ਨੇ ਸਰਵਰ ਵਰਕਲੋਡਾਂ ਲਈ ਪੋਰਟੇਬਿਲਿਟੀ ਨੂੰ ਆਮਦਨਯੋਗ ਬਣਾਇਆ।
ਗਾਰਬੇਜ ਕਲੀਕਸ਼ਨ: ਮੈਮੋਰੀ ਦਾ ਘੱਟ ਹਲ-ਚਲ ਅਤੇ ਘੱਟ ਪ੍ਰੋਡਕਸ਼ਨ ਬੱਗਸ
GC ਮਹੱਤਵਪੂਰਨ ਸੀ ਕਿਉਂਕਿ ਵੱਡੀਆਂ ਸਰਵਰ ਐਪਲੀਕੇਸ਼ਨਾਂ ਓਬਜੈਕਟਾਂ ਦੀਆਂ ਬਹੁਤ ਵੱਡੀਆਂ ਗਿਣਤੀਆਂ ਬਣਾਉਂਦੀਆਂ ਅਤੇ ਹਟਾਉਂਦੀਆਂ ਹਨ: ਰਿਕਵੈਸਟ, ਸੈਸ਼ਨ, ਕੈਸ਼ਡ ਡੇਟਾ, ਪਾਰਸ ਕੀਤੇ ਪੇਲੋਡ ਆਦਿ। ਜੇ ਭਾਸ਼ਾਵਾਂ ਨੂੰ ਮੈਨੁਅਲ ਤੌਰ 'ਤੇ ਮੈਮੋਰੀ ਮੈਨੇਜ ਕਰਨੀ ਪੈਂਦੀ, ਤਾਂ ਇਹ ਡਿਪਲੌਇਮੈਂਟ ਵਿੱਚ ਲੀਕ, ਕਰੈਸ਼, ਜਾਂ ਡੀਬੱਗ ਕਰਨ ਯੋਗ ਗੜਬੜੀਆਂ ਪੈਦਾ ਕਰ ਸਕਦਾ।
GC ਨਾਲ, ਟੀਮਾਂ ਬਿਜ਼ਨਸ ਲਾਜਿਕ 'ਤੇ ਧਿਆਨ ਦੇ ਸਕਦੀਆਂ ਹਨ ਨਾ ਕਿ "ਕੌਣ ਕਦੋਂ ਫ੍ਰੀ ਕਰਦਾ ਹੈ"। ਬਹੁਤ ਸਾਰੀਆਂ ਐਂਟਰਪ੍ਰਾਈਜ਼ਾਂ ਲਈ ਉਹ ਭਰੋਸੇਯੋਗੀ ਲਾਭ ਮਾਇਕ੍ਰੋ-ਆਪਟੀਮਾਈਜੇਸ਼ਨਾਂ ਤੋਂ ਵੱਧ ਮਹੱਤਵ ਰੱਖਦਾ ਸੀ।
JIT ਕੰਪਾਇਲੇਸ਼ਨ: ਪੋਰਟੇਬਿਲਿਟੀ ਲਈ ਪ੍ਰਦਰਸ਼ਨ ਪੁਲ
ਜਾਵਾ ਬਾਈਟਕੋਡ ਨੂੰ JVM `ਤੇ ਚਲਾਉਂਦਾ ਹੈ, ਅਤੇ JVM Just-In-Time (JIT) ਕੰਪਾਇਲੇਸ਼ਨ ਵਰਤਦਾ ਹੈ ਤਾਂ ਜੋ ਪ੍ਰੋਗਰਾਮ ਦੇ ਗਰਮ ਹਿੱਸਿਆਂ ਨੂੰ ਮੌਜੂਦਾ CPU ਲਈ ਅਪਟੀਮਾਈਜ਼ਡ ਮਸ਼ੀਨ ਕੋਡ ਵਿੱਚ ਤਬਦੀਲ ਕੀਤਾ ਜਾਵੇ।
ਇਹ ਪੁਲ ਹੈ: ਤੁਹਾਡਾ ਕੋਡ ਪੋਰਟੇਬਲ ਰਹਿੰਦਾ ਹੈ, ਜਦਕਿ ਰਨਟਾਈਮ ਉਸ ਮਹੋਲ `ਤੇ ਅਨੁਕੂਲ ਹੁੰਦਾ ਹੈ ਜਿਸ 'ਤੇ ਇਹ ਅਸਲ ਵਿੱਚ ਚੱਲ ਰਿਹਾ ਹੈ—ਅਕਸਰ ਸਮੇਂ ਦੇ ਨਾਲ ਇਹ ਕਾਰਗੁਜ਼ਾਰੀ ਵਿੱਚ ਸੁਧਾਰ ਲਿਆਉਂਦਾ ਹੈ ਕਿਉਂਕਿ ਇਹ ਦੇਖਦਾ ਹੈ ਕਿ ਕਿਹੜੇ ਮੈਥਡ ਵੱਧ ਵਰਤੋਂ ਵਿੱਚ ਹਨ।
ਤਕਰੇਬ: warm-up, ਟਿਊਨਿੰਗ, ਅਤੇ ਲੇਟੈਂਸੀ ਸੰਵੇਦਨਸ਼ੀਲਤਾ
ਇਹ ਰਨਟਾਈਮ ਚਾਲਾਕੀਆਂ ਮੁਫ਼ਤ ਨਹੀਂ ਹਨ। JIT warm-up ਸਮਾਂ ਲਿਆਉਂਦਾ ਹੈ, ਜਿਸ ਦੌਰਾਨ ਪਰਦਰਸ਼ਨ ਥੋੜ੍ਹਾ ਹੌਲੀ ਹੋ ਸਕਦਾ ਹੈ ਜਦ ਤੱਕ JVM ਕਾਫ਼ੀ ਟ੍ਰੈਫਿਕ ਵੇਖ ਕੇ ਅਪਟੀਮਾਈਜ਼ ਨਾ ਕਰ ਲਵੇ।
GC ਵੀ ਰੁਕਾਵਟ ਪੈਦਾ ਕਰ ਸਕਦਾ ਹੈ। ਆਧੁਨਿਕ ਕਲੀਕਸ਼ਰ ਇਨ੍ਹਾਂ ਨੂੰ ਬਹੁਤ ਘਟਾ ਦਿੰਦੇ ਹਨ, ਪਰ ਲੇਟੈਂਸੀ-ਸੰਵੇਦਨਸ਼ੀਲ ਸਿਸਟਮਾਂ ਨੂੰ ਜ਼ਰੂਰ ਧਿਆਨ ਅਤੇ ਟਿਊਨਿੰਗ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ (ਹੀਪ ਸਾਈਜ਼ਿੰਗ, ਕਲੀਕਸ਼ਰ ਚੋਣ, ਅਲੋਕੇਸ਼ਨ ਪੈਟਰਨ)।
ਪ੍ਰੋਫਾਇਲਿੰਗ ਜਾਵਾ ਕੰਮ ਦਾ ਸਧਾਰਨ ਹਿੱਸਾ
ਕਿਉਂਕਿ ਇਤਨਾ ਕੁ ਪ੍ਰਦਰਸ਼ਨ ਰਨਟਾਈਮ ਵਿਵਹਾਰ 'ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ, ਪ੍ਰੋਫਾਇਲਿੰਗ ਰੋਜ਼ਮਰਰਾ ਦੀ ਗੱਲ ਬਣ ਗਈ। ਜਾਵਾ ਟੀਮਾਂ ਆਮ ਤੌਰ 'ਤੇ CPU, ਅਲੋਕੇਸ਼ਨ ਦਰਾਂ, ਅਤੇ GC ਗਤੀਵਿਧੀ ਨੂੰ ਮਾਪਦੀਆਂ ਹਨ ਤਾਂ ਜੋ ਬੋਟਲਨੇਕ ਲੱਭੀਏ—JVM ਨੂੰ ਇੱਕ ਕਾਲੇ ਡੱਬੇ ਵਾਂਗ ਨਹੀਂ, ਸਗੋਂ ਇੱਕ ਚੀਜ਼ ਵਜੋਂ ਵੇਖਦੇ ਅਤੇ ਟਿਊਨ ਕਰਦੇ ਹਨ।
ਟੂਲਿੰਗ ਜੋ ਟੀਮ ਉਤਪਾਦਕਤਾ ਬਦਲੀ
ਜਾਵਾ ਨੇ ਸਿਰਫ਼ ਪੋਰਟੇਬਿਲਿਟੀ 'ਤੇ ਜਿੱਤ ਨਹੀਂ ਪ੍ਰਾਪਤ ਕੀਤੀ। ਇਹ ਇੱਕ ਟੂਲਿੰਗ ਕਹਾਣੀ ਨਾਲ ਵੀ ਆਇਆ ਜਿਸ ਨਾਲ ਵੱਡੇ ਕੋਡਬੇਸ ਟਕਸਾਲ ਰਹਿਣਯੋਗ ਬਣੇ—ਅਤੇ "ਐਂਟਰਪ੍ਰਾਈਜ਼-ਪੈਮਾਨੇ" ਦੀ ਵਿਕਾਸ ਪ੍ਰਕਿਰਿਆ ਘੱਟ ਅਣਧਿਆਨੀ ਹੋ ਗਈ।
IDEਜ਼: ਫਾਇਲਾਂ ਨੂੰ ਐਡਿਟ ਕਰਨ ਤੋਂ ਸਿਸਟਮਾਂ ਨੂੰ ਸਮਝਣ ਤੱਕ
ਆਧੁਨਿਕ ਜਾਵਾ IDEਜ਼ (ਅਤੇ ਭਾਸ਼ਾ ਫੀਚਰ ਜੋ ਉਹਨਾਂ `ਤੇ ਝੁਕਿਆ) ਰੋਜ਼ਾਨਾ ਕੰਮ ਬਦਲ ਦਿੱਤਾ: ਪੈਕੇਜਾਂ 'ਚ ਨੈਵੀਗੇਸ਼ਨ, ਸੁਰੱਖਿਅਤ ਰਿਫੈਕਟਰਿੰਗ, ਅਤੇ ਸਦਾ-ਚਾਲੂ ਸਟੈਟਿਕ ਵਿਸ਼ਲੇਸ਼ਣ।
ਮੇਥਡ ਦਾ ਨਾਮ ਬਦਲੋ, ਇੰਟਰਫੇਸ ਬਾਹਰ ਕਢੋ, ਜਾਂ ਇੱਕ ਕਲਾਸ ਨੂੰ ਮਾਡਿਊਲ ਵਿੱਚੋਂ ਦੂਸਰੇ ਵਿੱਚ ਖਿਸਕਾਓ—ਫਿਰ imports, ਕਾਲ ਸਾਈਟਾਂ, ਅਤੇ ਟੈਸਟ ਆਟੋਮੈਟਿਕ ਅਪਡੇਟ ਹੋ ਜਾਂਦੇ ਹਨ। ਟੀਮਾਂ ਲਈ ਇਹ ਮਤਲਬ ਸੀ ਘੱਟ "ਇਹ ਹਿੱਸਾ ਛੁਡੋ" ਵਾਲੇ ਖੇਤਰ, ਤੇਜ਼ ਕੋਡ ਰਿਵਿਊ, ਅਤੇ ਪ੍ਰੋਜੈਕਟ ਵੱਧਣ 'ਤੇ ਹੋਰ ਇਕਸਾਰਸ ਨਿਰਮਾਣ।
ਬਿਲਡਸ ਅਤੇ ਨਿਰਭਰਤਾਵਾਂ: Ant → Maven/Gradle
ਸ਼ੁਰੂਆਤੀ ਜਾਵਾ ਬਿਲਡ ਅਕਸਰ Ant ਤੇ ਨਿਰਭਰ ਹੁੰਦੇ ਸਨ: ਲਚਕੀਲਾ, ਪਰ ਆਸਾਨੀ ਨਾਲ ਇੱਕ ਐਸਾ ਕਸਟਮ ਸਕ੍ਰਿਪਟ ਬਣ ਜਾਂਦਾ ਜੋ ਸਿਰਫ਼ ਇਕ ਵਿਅਕਤੀ ਸਮਝਦਾ ਸੀ। Maven ਨੇ ਇੱਕ ਪਰੰਪਰਾਗਤ-ਆਧਾਰਤ ਪਹੁੰਚ ਨੂੰ ਅੱਗੇ ਵਧਾਇਆ ਜਿਸ ਵਿੱਚ ਇੱਕ ਮਿਆਰੀ ਪ੍ਰਾਜੈਕਟ ਲੇਆਊਟ ਅਤੇ ਇੱਕ dependency ਮਾਡਲ ਸੀ ਜੋ ਕਿਸੇ ਵੀ ਮਸ਼ੀਨ ਤੇ ਦੁਹਰਾਇਆ ਜਾ ਸਕਦਾ ਸੀ। Gradle ਬਾਅਦ ਵਿੱਚ ਹੋਰ ਪ੍ਰਗਟਿਤ ਬਿਲਡ ਅਤੇ ਤੇਜ਼ ਇਟਰੇਸ਼ਨ ਲਿਆਇਆ, ਜਦ ਕਿ dependency ਮੈਨੇਜਮੈਂਟ ਨੂੰ ਕੇਂਦਰ ਵਿੱਚ ਰੱਖਿਆ।
ਵੱਡਾ ਬਦਲਾਅ ਦੁਹਰਾਈਯੋਗਤਾ ਸੀ: ਇੱਕੋ ਕਮਾਂਡ, ਇੱਕੋ ਨਤੀਜਾ, ਡਿਵੈਲਪਰ ਲੈਪਟਾਪ ਅਤੇ CI `ਤੇ।
ਕਿਉਂ ਮਿਆਰੀ ਟੂਲਿੰਗ ਟੀਮਾਂ ਨੂੰ ਸਕੇਲ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕੀਤੀ
ਮਿਆਰੀ ਪ੍ਰਾਜੈਕਟ ਬਣਤਰਾਂ, dependency ਕੋਆਰਡੀਨੇਟ, ਅਤੇ ਅਨੁਮਾਨਿਤ ਬਿਲਡ ਕਦਮ ਟ੍ਰਾਈਬਲ ਨੋਲੈਜ ਘਟਾਉਂਦੇ ਹਨ। ਓਨਬੋਰਡਿੰਗ ਆਸਾਨ ਹੋ ਜਾਂਦੀ ਹੈ, ਰਿਲੀਜ਼ਜ਼ ਘੱਟ ਹੱਥੋਂ-ਹੱਥ ਹੋਦੇ ਹਨ, ਅਤੇ ਇਹ ਪ੍ਰਯੋਗਯੋਗ ਹੁੰਦਾ ਹੈ ਕਿ ਕਈ ਸਰਵਿਸਜ਼ ਵਿੱਚ ਇੱਕਸਾਰ ਗੁਣਵੱਤਾ ਨੀਤੀਆਂ (ਫਾਰਮੈਟਿੰਗ, ਚੈਕਸ, ਟੈਸਟ ਗੇਟ) ਲਾਗੂ ਕੀਤੀਆਂ ਜਾਣ।
ਆਧੁਨਿਕ ਜਾਵਾ ਪ੍ਰੋਜੈਕਟ ਲਈ ਵਿਆਵਹਾਰਿਕ ਚੈੱਕਲਿਸਟ
- ਇੱਕ ਮੌਜੂਦਾ LTS JDK ਵਰਤੋ (ਅਤੇ CI ਵਿੱਚ ਇਸਨੂੰ ਪਿਨ ਕਰੋ)।
- Maven ਜਾਂ Gradle ਚੁਣੋ; ਬਿਲਡ ਨੂੰ ਘੱਟ ਅਤੇ ਦਸਤਾਵੇਜ਼ੀ ਰੱਖੋ।
- dependency ਵਰਜਨ ਕੇਂਦਰੀਕਰਤ ਕਰੋ (BOM ਜਾਂ ਵਰਜਨ ਕੈਟਾਲੌਗ)।
- ਫਾਰਮੈਟਿੰਗ + ਸਟੈਟਿਕ ਚੈਕਸ (ਜਿਵੇਂ Checkstyle/SpotBugs) ਨੂੰ ਬਿਲਡ ਕਦਮ ਵਜੋਂ ਸ਼ਾਮਿਲ ਕਰੋ।
- ਯੂਨਿਟ ਟੈਸਟ ਲਾਜ਼ਮੀ ਕਰੋ ਅਤੇ ਕਵਰੇਜ ਰਿਪੋਰਟ ਬਣਾਓ।
- ਹਰ ਬਦਲਾਅ 'ਤੇ ਬਿਲਡ + ਟੈਸਟ ਚਲਾਉਣ ਵਾਲੀ ਦੁਹਰਣਯੋਗ CI ਪਾਈਪਲਾਈਨ ਰੱਖੋ।
- "ਕਿਵੇਂ ਲੋਕਲ ਚਲਾਉਣਾ ਹੈ" ਇਕ ਛੋਟੀ README ਵਿੱਚ ਦਸਤਾਵੇਜ਼ ਕਰੋ।
ਟੈਸਟਿੰਗ ਅਤੇ ਡੈਲੀਵਰੀ: JUnit ਤੋਂ CI/CD ਤੱਕ
ਖ਼ਿਆਲ ਤੋਂ ਐਪ ਤੱਕ ਜਾਓ
ਇੱਕ ਖ਼ਿਆਲ ਨੂੰ ਇੱਕ ਕੰਮ ਕਰਦਾ ਵੈਬ ਬੈਕਐਂਡ ਬਣਾਉ—ਬਿਨਾਂ ਪੂਰਾ ਪ੍ਰਾਜੈਕਟ ਸੈੱਟਅੱਪ ਕੀਤੇ।
ਜਾਵਾ ਟੀਮਾਂ ਨੇ ਸਿਰਫ਼ ਇੱਕ ਪੋਰਟੇਬਲ ਰਨਟਾਈਮ ਨਹੀਂ ਪਾਇਆ—ਉਹਨਾਂ ਨੇ ਇੱਕ ਸੰਸਕ੍ਰਿਤੀ ਬਦਲ ਦਿਖਾਈ: ਟੈਸਟਿੰਗ ਅਤੇ ਡੈਲੀਵਰੀ ਕੁਝ ਐਸਾ ਬਣ ਗਿਆ ਜੋ ਤੁਸੀਂ ਮਿਆਰੀਕ੍ਰਿਤ, ਆਟੋਮੇਟ ਅਤੇ ਦੁਹਰਾਉ ਸਕਦੇ ਹੋ।
JUnit ਨੇ ਯੂਨਿਟ ਟੈਸਟਾਂ ਨੂੰ "ਆਮ" ਕਿਵੇਂ ਬਣਾਇਆ
JUnit ਤੋਂ ਪਹਿਲਾਂ, ਟੈਸਟ ਅਕਸਰ ਐਡ-ਹਾਕ ਹੁੰਦੇ ਸਨ (ਜਾਂ ਮੈਨੂਅਲ) ਅਤੇ ਮੁੱਖ ਵਿਕਾਸ ਲੂਪ ਤੋਂ ਬਾਹਰ ਰਹਿੰਦੇ ਸਨ। JUnit ਨੇ ਟੈਸਟਾਂ ਨੂੰ ਪਹਿਲ-ਕਲਾਸ ਕੋਡ ਜਿਵੇਂ ਮਹਿਸੂਸ ਕਰਵਾਇਆ: ਇੱਕ ਛੋਟੀ ਟੈਸਟ ਕਲਾਸ ਲਿਖੋ, IDE ਵਿੱਚ ਚਲਾਓ, ਅਤੇ ਤੁਰੰਤ ਫੀਡਬੈਕ ਲਵੋ।
ਇਹ ਤਤਕਾਲ ਲੂਪ ਉਹਨਾਂ ਐਂਟਰਪ੍ਰਾਈਜ਼ ਸਿਸਟਮਾਂ ਲਈ ਮਾਇਨੇ ਰੱਖਦਾ ਜਿੱਥੇ ਰਿਗ੍ਰੈਸ਼ਨ ਮਹਿੰਗੀ ਹੁੰਦੀ ਹੈ। ਸਮੇਂ ਨਾਲ, "ਟੈਸਟ ਨਾਂ ਹੋਣ" ਅਜਿਹਾ ਖਾਸ ਕੇਸ ਨਹੀਂ ਰਹਿ ਗਿਆ ਅਤੇ ਜੋਖਮ ਜ਼ਿਆਦਾ ਸਪਸ਼ਟ ਹੋ ਗਿਆ।
CI ਦੇ ਫਾਇਦੇ: ਇੱਕ ਬਿਲਡ, ਬਹੁਤ ਸਾਰੇ ਮਹੋਲ
ਜਾਵਾ ਡੈਲੀਵਰੀ ਦਾ ਇਕ ਵੱਡਾ ਫਾਇਦਾ ਇਹ ਹੈ ਕਿ ਬਿਲਡ ਆਮ ਤੌਰ 'ਤੇ ਇੱਕੋ ਕਮਾਂਡ ਦੁਆਰਾ ਚਲਾਈ ਜਾਂਦੀ ਹੈ—ਡਿਵੈਲਪਰ ਲੈਪਟਾਪ, ਬਿਲਡ ਏਜੰਟ, Linux ਸਰਵਰ, Windows ਰਨਰ—ਕਿਉਂਕਿ JVM ਅਤੇ ਬਿਲਡ ਟੂਲਜ਼ ਇੱਕਸਾਰ ਵਿਵਹਾਰ ਕਰਦੇ ਹਨ।
ਅਮਲ ਵਿੱਚ, ਉਹ ਇੱਕਸਾਰਤਾ "works on my machine" ਸਮੱਸਿਆ ਨੂੰ ਘੱਟ ਕਰਦੀ ਹੈ। ਜੇ ਤੁਹਾਡਾ CI ਸਰਵਰ mvn test ਜਾਂ gradle test ਚਲਾ ਸਕਦਾ ਹੈ, ਤਾਂ ਅਕਸਰ ਤੁਹਾਨੂੰ ਵਹੀ ਨਤੀਜੇ ਮਿਲਦੇ ਹਨ ਜੋ ਪੂਰੀ ਟੀਮ ਵੇਖਦੀ ਹੈ।
ਪਾਈਪਲਾਈਨ ਵਿੱਚ ਫਿੱਟ ਹੋਣ ਵਾਲਾ ਕੋਡ ਗੁਣਵੱਤਾ ਟੂਲਿੰਗ
ਜਾਵਾ ਇਕੋਸਿਸਟਮ ਨੇ "ਕੁਆਲਟੀ ਗੇਟ" ਨੂੰ ਆਟੋਮੇਟ ਕਰਨ ਨੂੰ ਆਸਾਨ ਬਣਾਇਆ:
- ਫਾਰਮੈਟਿੰਗ: Spotless ਜਾਂ ਸਾਂਝੀ IDE ਫਾਰਮੈਟਰ ਕਾਨਫਿਗ diff ਸਾਫ਼ ਰੱਖਣ ਲਈ
- ਲਿੰਟਿੰਗ/ਸਟੈਟਿਕ ਵਿਸ਼ਲੇਸ਼ਣ: Checkstyle, PMD, SpotBugs ਆਮ ਗਲਤੀਆਂ ਲੱਭਣ ਲਈ
- ਸੁਰੱਖਿਆ ਸਕੈਨ: OWASP Dependency-Check (ਜਾਂ ਹੋਸਟ ਕੀਤੀ ਟੂਲ ਵਰਗੀ Snyk) ਜੋ ਨਾਜ਼ੁਕ ਲਾਇਬ੍ਰੇਰੀਆਂ ਨੂੰ ਫਲੈਗ ਕਰਦਾ
ਇਹ ਟੂਲ ਸਭ ਤੋਂ ਵਧੀਆ ਉਦੋਂ ਕੰਮ ਕਰਦੇ ਹਨ ਜਦੋਂ ਉਹ ਪੂਰੇ ਰੈਪੋ ਲਈ ਇੱਕੋ ਨਿਯਮ ਲਾਉਂਦੇ ਹਨ, CI ਵਿੱਚ ਲਾਗੂ ਹੁੰਦੇ ਹਨ, ਅਤੇ ਸਪਸ਼ਟ ਫੇਲ੍ਹਰ ਸੁਨੇਹੇ ਦਿੰਦੇ ਹਨ।
ਇੱਕ ਜਾਵਾ ਸਰਵਿਸ ਲਈ ਸਧਾਰਨ CI ਪਾਈਪਲਾਈਨ
ਇਸਨੂੰ ਬੋਰਿੰਗ ਅਤੇ ਦੁਹਰਾਏ ਜਾ ਸਕਣ ਯੋਗ ਰੱਖੋ:
- Checkout + ਜਾਵਾ ਵਰਜਨ ਸੈੱਟ ਕਰੋ (ਆਪਣਾ JDK ਪਿਨ ਕਰੋ)
- Build + ਯੂਨਿਟ ਟੈਸਟ (
mvn test/gradle test) - ਸਟੈਟਿਕ ਚੈਕਸ (ਫਾਰਮੈਟ, ਲਿੰਟ, ਸਿਕিউਰਿਟੀ ਸਕੈਨ)
- ਆਰਟੀਫੈਕਟ ਪੈਕੇਜ (JAR) ਅਤੇ ਇਸਨੂੰ ਸਟੋਰ ਕਰੋ
- ਇੰਟੇਗਰੇਸ਼ਨ ਟੈਸਟ (ਵਿਕਲਪਕ, ਪਰ ਕੀਮਤੀ)
- ਸਟੇਜਿੰਗ 'ਤੇ ਡਿਪਲੌਇ, ਫਿਰ ਮਨਜ਼ੂਰੀਆਂ ਨਾਲ ਪ੍ਰੋਡਕਸ਼ਨ
ਇਹ ਬਣਤਰ ਇੱਕ ਸਰਵਿਸ ਤੋਂ ਕਈ ਤੱਕ ਸਕੇਲ ਹੋ ਜਾਂਦੀ ਹੈ—ਅਤੇ ਇਹੀ ਥੀਮ ਦੁਹਰਾਉਂਦੀ ਹੈ: ਇੱਕਸਾਰ ਰਨਟਾਈਮ ਅਤੇ ਇੱਕਸਾਰ ਕਦਮ ਟੀਮਾਂ ਨੂੰ ਤੇਜ਼ ਬਣਾ ਦਿੰਦੇ ਹਨ।
Spring ਅਤੇ ਆਧੁਨਿਕ ਬੈਕਐਂਡ ਵਿਕਾਸ ਵੱਲ ਤਬਦੀਲੀ
ਜਾਵਾ ਨੇ ਐਂਟਰਪ੍ਰਾਈਜ਼ਾਂ ਵਿੱਚ ਭਰੋਸਾ ਜਿੱਤਿਆ, ਪਰ ਅਸਲੀ ਬਿਜ਼ਨਸ ਐਪਲੀਕੇਸ਼ਨਾਂ ਬਣਾਉਣਾ ਅਕਸਰ ਭਾਰੀ ਐਪ ਸਰਵਰਾਂ, verbose XML, ਅਤੇ ਕੰਟੇਨਰ-ਨਿਰਭਰ ਰਵਾਇਆਂ ਨਾਲ ਟਕਰਾਉਂਦਾ ਸੀ। Spring ਨੇ ਦੈਨੀਕ ਅਨੁਭਵ ਨੂੰ ਬਦਲ ਕੇ "ਓਪਲੈਨ" ਜਾਵਾ ਨੂੰ ਬੈਕਐਂਡ ਵਿਕਾਸ ਦਾ ਕੇਂਦਰ ਬਣਾਇਆ।
Inversion of Control: ਇਹ ਐਂਟਰਪ੍ਰਾਈਜ਼ ਜ਼ਰੂਰਤਾਂ ਨਾਲ ਕਿਵੇਂ ਫਿੱਟ ਹੋਇਆ
Spring ਨੇ inversion of control (IoC) ਨੂੰ ਲੋਕਪ੍ਰਿਯ ਕੀਤਾ: ਬਜਾਏ ਇਸਦੇ ਕਿ ਤੁਹਾਡਾ ਕੋਡ ਹਰ ਚੀਜ਼ ਨੂੰ ਹੱਥੋਂ ਬਣਾਏ ਅਤੇ ਵਾਇਰ ਕਰੇ, ਫਰੇਮਵਰਕ ਐਪਲੀਕੇਸ਼ਨ ਨੂੰ reusable ਕੰਪੋਨੈਂਟਾਂ ਤੋਂ ਜੋੜਦਾ ਹੈ।
dependency injection (DI) ਨਾਲ, ਕਲਾਸਾਂ ਆਪਣੀ ਲੋੜ ਦਾ ਘੋਸ਼ਣਾ ਕਰਦੀਆਂ ਹਨ, ਅਤੇ Spring ਇਹ ਮੁਹੱਈਆ ਕਰਦਾ ਹੈ। ਇਸ ਨਾਲ ਟੈਸਟੇਬਿਲਿਟੀ ਸੁਧਰਦੀ ਹੈ ਅਤੇ ਟੀਮਾਂ ਲਈ ਇੰਪਲੀਮੈਂਟੇਸ਼ਨਾਂ ਬਦਲਣਾ ਆਸਾਨ ਹੁੰਦਾ ਹੈ (ਉਦਾਹਰਨ ਲਈ, ਰੀਅਲ ਪੇਮੈਂਟ ਗੇਟਵੇਅ vs ਟੈਸਟ ਲਈ ਸਟਬ) ਬਿਨਾਂ ਬਿਜ਼ਨਸ ਲਾਜਿਕ ਮੁੜ-ਲਿਖੇ।
ਸਰਲ ਕੀਤਾ ਹੋਇਆ ਕਾਨਫਿਗਰੇਸ਼ਨ ਅਤੇ ਇੰਟੀਗ੍ਰੇਸ਼ਨ
Spring ਨੇ ਆਮ ਇੰਟੀਗ੍ਰੇਸ਼ਨਾਂ ਨੂੰ ਮਿਆਰੀਕ੍ਰਿਤ ਕਰਕੇ friction ਘਟਾਇਆ: JDBC ਟੈਂਪਲੇਟ, ਬਾਅਦ ਵਿੱਚ ORM ਸਹਿਯੋਗ, ਡਿਕਲੇਰੇਟਿਵ ਟ੍ਰਾਂਜ਼ੈਕਸ਼ਨ, ਸ਼ੈਡਿਊਲਿੰਗ, ਅਤੇ ਸੁਰੱਖਿਆ। ਕਾਨਫਿਗਰੇਸ਼ਨ ਲੰਬੇ, ਭੰਗੁਰੂ XML ਤੋਂ ਐਨੋਟੇਸ਼ਨ ਅਤੇ ਬਾਹਰਲੇ ਪ੍ਰਾਪਰਟੀਜ਼ ਵੱਲ ਆਇਆ।
ਇਹ ਬਦਲਾਅ ਆਧੁਨਿਕ ਡੈਲੀਵਰੀ ਨਾਲ ਵੀ ਖੁਬ ਮੇਲ ਖਾਂਦਾ ਹੈ: ਇੱਕੋ ਬਿਲਡ ਲੋਕਲ, ਸਟੇਜਿੰਗ, ਜਾਂ ਪ੍ਰੋਡਕਸ਼ਨ `ਤੇ ਚੱਲ ਸਕਦਾ ਹੈ ਸਿਰਫ਼ ਵਾਤਾਵਰਣ-ਵਿਸ਼ੇਸ਼ ਕਾਨਫਿਗਰੇਸ਼ਨ ਬਦਲ ਕੇ, ਨਾ ਕਿ ਕੋਡ।
WORA, ਪੋਰਟੇਬਿਲਿਟੀ, ਅਤੇ ਆਧੁਨਿਕ ਸਰਵਿਸ ਪੈਟਰਨ
Spring-ਅਧਾਰਤ ਸਰਵਿਸਾਂ "ਕਿਤੇ ਵੀ ਚਲਾਓ" ਦਾ ਵਾਅਦਾ عملي ਰੱਖਦੀਆਂ ਹਨ: Spring ਨਾਲ ਬਣਿਆ REST API ਬਿਨਾਂ ਬਦਲਾਅ ਦੇ ਡਿਵੈਲਪਰ ਲੈਪਟਾਪ, VM, ਜਾਂ ਕੰਟੇਨਰ `ਤੇ ਚੱਲ ਸਕਦਾ ਹੈ—ਕਿਉਂਕਿ ਬਾਈਟਕੋਡ JVM ਨੂੰ ਟਾਰਗੇਟ ਕਰਦੀ ਹੈ, ਅਤੇ ਫਰੇਮਵਰਕ ਕਈ ਪਲੇਟਫਾਰਮ ਵਿਸ਼ੇਸ਼ ਚੀਜ਼ਾਂ ਨੂੰ ਐਬਸਟ੍ਰੈਕਟ ਕਰਦਾ ਹੈ।
ਅੱਜ ਦੇ ਆਮ ਪੈਟਰਨ—REST ਐਂਡਪੋਇੰਟ, dependency injection, ਅਤੇ ਪ੍ਰਾਪਰਟੀ/ENV ਵੱਲੋਂ ਕਾਨਫਿਗਰੇਸ਼ਨ—ਅਸਲ ਵਿੱਚ Spring ਦੇ ਡਿਫ਼ੌਲਟ ਮੈਨਟਲ ਮਾਡਲ ਹਨ। ਹੋਰ ਡਿਪਲੌਇਮੈਂਟ ਹਕੀਕਤਾਂ ਲਈ ਵੇਖੋ blog/java-in-the-cloud-containers-kubernetes-and-reality.
ਕਲਾਊਡ ਵਿੱਚ ਜਾਵਾ: ਕਨਟੇਨਰ, Kubernetes, ਅਤੇ ਹਕੀਕਤ
ਜਾਵਾ ਨੂੰ ਕੰਟੇਨਰਾਂ ਵਿੱਚ ਚਲਾਉਣ ਲਈ "ਕਲਾਉਡ ਰੀਰਾਈਟ" ਦੀ ਲੋੜ ਨਹੀਂ ਸੀ। ਇੱਕ ਆਮ ਜਾਵਾ ਸਰਵਿਸ ਅਜੇ ਵੀ ਇੱਕ JAR (ਜਾਂ WAR) ਵਜੋਂ ਪੈਕੇਜ ਕੀਤੀ ਜਾਂਦੀ ਹੈ, java -jar ਨਾਲ ਲਾਂਚ ਕੀਤੀ ਜਾਂਦੀ ਹੈ, ਅਤੇ ਇੱਕ ਕੰਟੇਨਰ ਇਮੇਜ ਵਿੱਚ ਰੱਖੀ ਜਾਂਦੀ ਹੈ। Kubernetes ਫਿਰ ਉਸ ਕੰਟੇਨਰ ਨੂੰ ਕਿਸੇ ਹੋਰ ਪ੍ਰਕਿਰਿਆ ਵਾਂਗ ਸ਼ੈਡਿਊਲ ਕਰਦਾ ਹੈ: ਇਸਨੂੰ ਸ਼ੁਰੂ ਕਰੋ, ਨਿਗਰਾਨੀ ਕਰੋ, ਮੁੜ-ਸ਼ੁਰੂ ਕਰੋ, ਅਤੇ ਸਕੇਲ ਕਰੋ।
ਕੰਟੇਨਰਾਂ ਵਿੱਚ ਕੀ ਬਦਲਦਾ ਹੈ (ਭਾਵੇਂ ਤੁਹਾਡਾ ਕੋਡ ਨਾ ਬਦਲੇ)
ਵੱਡਾ ਬਦਲਾਅ JVM ਦੇ ਆਲੇ-ਦੁਆਲੇ ਵਾਲਾ ਮਹੌਲ ਹੈ। ਕੰਟੇਨਰ ਕਠੋਰ ਰੀਸੋর্স ਸਹਿਪਾ ਅਤੇ ਤੇਜ਼ ਲਾਈਫਸਾਈਕਲ ਘਟਨਾਵਾਂ ਲਿਆਉਂਦੇ ਹਨ ਜਿਨ੍ਹਾਂ ਨਾਲ ਰਵਾਇਤੀ ਸਰਵਰਾਂ ਨਾਲ ਫਰਕ ਹੁੰਦਾ ਹੈ।
ਮੇਮੋਰੀ ਲਿਮਿਟ ਪਹਿਲਾ ਵਾਸਤਵੀ ਠੋਕਰਾ ਹੈ। Kubernetes ਵਿੱਚ ਤੁਸੀਂ ਇੱਕ ਮੇਮੋਰੀ ਲਿਮਿਟ ਸੈੱਟ ਕਰਦੇ ਹੋ, ਅਤੇ JVM ਨੂੰ ਇਸਦੀ ਪਾਬੰਦੀ ਮੰਨਣੀ ਪੈਂਦੀ ਹੈ—ਨਹੀਂ ਤਾਂ ਪੋਡ kill ਹੋ ਸਕਦੀ ਹੈ। ਆਧੁਨਿਕ JVMs ਕੰਟੇਨਰ-ਅਵੇਅਰ ਹਨ, ਪਰ ਟੀਮਾਂ ਅਜੇ ਵੀ ਹੀਪ ਸਾਈਜ਼ਿੰਗ ਟਿਊਨ ਕਰਦੀਆਂ ਹਨ ਤਾਂ ਜੋ metaspace, ਧਾਗੇ, ਅਤੇ ਨੈਟਿਵ ਮੈਮੋਰੀ ਲਈ ਥਾਂ ਛੱਡੀ ਜਾਵੇ। VM `ਤੇ ਕੰਮ ਕਰਨ ਵਾਲੀ ਸੇਵਾ ਕੰਟੇਨਰ ਵਿੱਚ ਹੀਪ ਬਹੁਤ ਅਗਰੈਸਿਵ ਸੈੱਟ ਹੋਣ ਨਾਲ crash ਕਰ ਸਕਦੀ ਹੈ।
ਸਟਾਰਟਅਪ ਟਾਈਮ ਵੀ ਜ਼ਿਆਦਾ ਮਹੱਤਵਪੂਰਨ ਹੋ ਜਾਂਦਾ ਹੈ। ਓਰਕੈਸਟਰ ਬਾਰ-ਬਾਰ ਸਕੇਲ ਉੱਪ ਅਤੇ ਡਾਊਨ ਕਰਦੇ ਹਨ, ਅਤੇ ਹੌਲੀ ਕੋਲਡ-ਸਟਾਰਟਸ ਆਟੋਸਕੇਲਿੰਗ, ਰੋਲਆਊਟਸ ਅਤੇ ਇਨਸੀਡੈਂਟ ਰਿਕਵਰੀ 'ਤੇ ਪ੍ਰਭਾਵ ਪਾ ਸਕਦੀਆਂ ਹਨ।ੀਮੇਜ ਸਾਈਜ਼ ਆਪਰੇਸ਼ਨਲ ਘਸਾਈ ਬਣ ਜਾਂਦੀ ਹੈ: ਵੱਡੀਆਂ ਇਮੇਜਾਂ ਨੇਠਵਰਕ ਤੇ ਖਿੱਚਣ ਲਈ ਜ਼ਿਆਦਾ ਸਮਾਂ ਲੈਂਦੀਆਂ ਹਨ, ਡਿਪਲੌਇ ਸਮਾਂ ਵਧਾਉਂਦੀਆਂ ਹਨ, ਅਤੇ ਰਜਿਸਟਰੀ/ਨੈੱਟਵਰਕ ਬੈਂਡਵਿਡਥ ਖਰਚ ਕਰਦੀਆਂ ਹਨ।
ਜਾਵਾ ਨੂੰ ਬਿਹਤਰ ਫਿੱਟ ਕਰਨ ਦੇ ਤਰੀਕੇ: ਛੋਟਾ, ਤੇਜ਼, ਅਤੇ ਪੇਸ਼ੀਵਾਰ
ਕੁਝ ਤਰੀਕੇ ਜਿਨ੍ਹਾਂ ਨੇ ਜਾਵਾ ਨੂੰ ਕਲਾਉਡ ਡਿਪਲੌਇਮੈਂਟਾਂ ਵਿੱਚ ਜ਼ਿਆਦਾ ਕੁਦਰਤੀ ਬਣਾਇਆ:
- ਹਲਕੇ ਰਨਟਾਈਮ: ਸਲਿਮ ਬੇਸ ਇਮੇਜ ਅਤੇ
jlinkਵਰਗੇ ਟੂਲਜ਼ ਨਾਲ ਰਨਟਾਈਮ ਨੂੰ ਘਟਾਉਣਾ ਇਮੇਜ ਸਾਈਜ਼ ਕੱਟਦਾ ਹੈ। - ਤੇਜ਼ ਸਟਾਰਟਅਪ: class data sharing (CDS) ਅਤੇ dependency ਸਫਾਈ ਨਾਲ ਕੋਲਡ-ਸਟਾਰਟ ਓਵਰਹੈੱਡ ਘਟਾਇਆ ਜਾ ਸਕਦਾ ਹੈ।
- ਵਿਕਲਪਿਕ ਪੈਕੇਜਿੰਗ: ਅਹੇਡ-ਆਫ-ਟਾਈਮ ਕੰਪਾਇਲੇਸ਼ਨ (ਜੋ ਕਿ ਕੁਝ ਸਰਵਿਸਾਂ ਲਈ ਯੋਗ ਹੈ) ਕੋਲਡ-ਸਟਾਰਟ ਅਤੇ ਮੈਮੋਰੀ ਪ੍ਰੋਫਾਈਲਾਂ ਨੂੰ ਬਹੁਤ ਸੁਧਾਰ ਸਕਦੀ ਹੈ, ਮਗਰੋਂ ਇਹ ਵੱਖ-ਵੱਖ ਬਿਲਡ/ਡਿਬੱਗ ਟਰੇਡ-ਆਫਸ ਲਿਆਉਂਦੀ ਹੈ।
ਟੂਨਿੰਗ JVM ਵਿਹਾਰ ਅਤੇ ਪ੍ਰਦਰਸ਼ਨ ਟਰੇਡ-ਆਫਸ ਨੂੰ ਸਮਝਣ ਲਈ ਅਮਲਕਾਰੀ ਹਵਾਲਾ blog/java-performance-basics ਹਨ।
ਪਿਛੇਲੀ ਅਨੁਕੂਲਤਾ ਅਤੇ ਲੰਬੇ ਸਮੇਂ ਚੱਲਣ ਵਾਲੇ ਸਿਸਟਮ
ਸਿੱਖਣ ਲਈ ਕ੍ਰੈਡਿਟ ਪ੍ਰਾਪਤ ਕਰੋ
Koder.ai ਬਾਰੇ ਸਮੱਗਰੀ ਬਣਾਓ ਅਤੇ ਪਲੇਟਫਾਰਮ ਸਿੱਖਦੇ ਹੋਏ ਕ੍ਰੈਡਿਟ ਕਮਾਓ।
ਜਾਵਾ ਨੇ ਐਂਟਰਪ੍ਰਾਈਜ਼ਾਂ ਵਿੱਚ ਭਰੋਸਾ ਕਮਾਇਆ ਇੱਕ ਸਧਾਰਨ ਕਾਰਨ ਨਾਲ: ਕੋਡ ਟੀਮਾਂ, ਵੇਂਡਰਾਂ, ਅਤੇ ਉਨ੍ਹਾਂ ਦੀਆਂ ਕਾਰੋਬਾਰੀ ਰਣਨੀਤੀਆਂ ਤੋਂ ਵੀ ਬਹੁਤ ਸਮੇਂ ਜੀਉਂਦਾ ਹੈ। ਜਾਵਾ ਦੀ ਸਥਿਰ API ਅਤੇ ਪਿਛੇਲੀ ਅਨੁਕੂਲਤਾ ਦੀ ਸੰਸਕ੍ਰਿਤੀ ਦਾ ਮਤਲਬ ਇਹ ਸੀ ਕਿ ਕਈ ਵਾਰ ਲਿਖੀ ਗਈ ਐਪਲੀਕੇਸ਼ਨ OS ਅਪਗ੍ਰੇਡ, ਹਾਰਡਵੇਅਰ ਰੀਫਰੇਸ਼, ਅਤੇ ਨਵੇਂ ਜਾਵਾ ਰਿਲੀਜ਼ਾਂ ਤੋਂ ਬਾਦ ਵੀ ਮੁੜ-ਲਿਖਣ ਦੇ ਬਗੈਰ ਚੱਲਦੀ ਰਹਿ ਸਕਦੀ ਸੀ।
ਐਂਟਰਪ੍ਰਾਈਜ਼ਾਂ ਵਿੱਚ ਸਥਿਰ API ਕਿਉਂ ਮਾਇਨੇ ਰੱਖਦੇ ਹਨ
ਐਂਟਰਪ੍ਰਾਈਜ਼ਾਂ ਭਵਿੱਖਬਾਣੀਯੋਗਤਾ ਲਈ optimize ਕਰਦੀਆਂ ਹਨ। ਜਦੋਂ ਕੋਰ APIਜ਼ ਅਨੁਕੂਲ ਰਹਿੰਦੀਆਂ ਹਨ, ਤਬ ਬਦਲਾਅ ਦੀ ਲਾਗਤ ਘੱਟ ਹੁੰਦੀ ਹੈ: ਟ੍ਰੇਨਿੰਗ ਸਮੱਗਰੀ ਪ੍ਰਸੰਗਿਕ ਰਹਿੰਦੀ ਹੈ, ਆਪਰੇਸ਼ਨਲ ਰਨਬੁੱਕਾਂ ਨੂੰ ਲਗਾਤਾਰ ਲਿਖਣ ਦੀ ਲੋੜ ਨਹੀਂ ਪੈਂਦੀ, ਅਤੇ ਹਨਤਕ ਸਿਸਟਮ ਛੋਟੇ ਕਦਮਾਂ ਵਿੱਚ ਸੁਧਾਰ ਹੋ ਸਕਦੇ ਹਨ ਨਾ ਕਿ ਇਕ ਵੱਡੇ ਮਾਈਗ੍ਰੇਸ਼ਨ।
ਇਹ ਸਥਿਰਤਾ ਆਰਕੀਟੈਕਚਰ ਚੋਣਾਂ ਨੂੰ ਭੀ ਅਕਾਰ ਦਿੱਤਾ। ਟੀਮਾਂ ਵੱਡੇ ਸਾਂਝੇ ਪਲੇਟਫਾਰਮ ਅਤੇ ਅੰਦਰੂਨੀ ਲਾਇਬ੍ਰੇਰੀਆਂ ਬਣਾਉਣ ਵਿੱਚ ਆਸਾਨ ਮਹਿਸੂਸ ਕਰਦੀਆਂ ਸਨ ਕਿਉਂਕਿ ਉਨ੍ਹਾਂ ਨੂੰ ਉਮੀਦ ਸੀ ਕਿ ਇਹ ਲੰਮੇ ਸਮੇਂ ਤੱਕ ਕੰਮ ਕਰਨਗੀਆਂ।
ਲਾਇਬ੍ਰੇਰੀਆਂ, ਰਖ-ਰਖਾਅ, ਅਤੇ "ਸਦੀਵੀ" ਉਮੀਦ
ਜਾਵਾ ਦੀ ਲਾਇਬ੍ਰੇਰੀ ਇਕੋਸਿਸਟਮ (ਲੋਗਿੰਗ ਤੋਂ ਲੈ ਕੇ ਡੇਟਾਬੇਸ ਪਹੁੰਚ ਅਤੇ ਵੈੱਬ ਫਰੇਮਵਰਕ ਤੱਕ) ਇਸ ਵਿਚਾਰ ਨੂੰ ਮਜ਼ਬੂਤ ਕੀਤਾ ਕਿ ਨਿਰਭਰਤਾਵਾਂ ਲੰਬੇ ਸਮੇਂ ਦੀਆਂ ਕ਼ਮਿਟਮੈਂਟ ਹਨ। ਦੂਜੀ ਪਾਸੀ, ਇਹ ਰਖ-ਰਖਾਅ ਲਿਆਉਂਦਾ ਹੈ: ਲੰਬੇ ਸਮੇਂ ਚੱਲਣ ਵਾਲੇ ਸਿਸਟਮ ਪੁਰਾਣੀਆਂ ਵਰਜਨਾਂ, ਟ੍ਰਾਂਸਟੀਵ ਲਾਇਬ੍ਰੇਰੀਆਂ, ਅਤੇ "ਅਸਥਾਈ" ਹੱਲ ਜੋ ਕਾਇਮ ਰਹਿ ਜਾਂਦੇ ਹਨ, ਨੂੰ ਇਕੱਤਰ ਕਰ ਲੈਂਦੇ ਹਨ।
ਸੁਰੱਖਿਆ ਅੱਪਡੇਟਸ ਅਤੇ dependency ਸਫਾਈ ਇੱਕ ਲਗਾਤਾਰ ਕੰਮ ਹਨ, ਨਾ ਕਿ ਇਕ ਵਾਰੀ ਦਾ ਪ੍ਰੋਜੈਕਟ। JDK ਨੂੰ ਨਿਯਮਤ ਰੂਪ ਵਿੱਚ ਪੈਚ ਕਰਨਾ, ਲਾਇਬ੍ਰੇਰੀਆਂ ਨੂੰ ਅਪਡੇਟ ਕਰਨਾ, ਅਤੇ CVE ਟ੍ਰੈਕ ਕਰਨਾ ਖਤਰੇ ਨੂੰ ਘਟਾਉਂਦਾ ਹੈ ਬਿਨਾਂ ਪ੍ਰੋਡਕਸ਼ਨ ਨੂੰ ਅਸਥਿਰ ਕੀਤੇ—ਖ਼ਾਸ ਕਰਕੇ ਜਦ ਅਪਗ੍ਰੇਡ ਇੰਕਰੀਮੇੰਟਲ ਹੋਣ।
ਪੁਰਾਣੀਆਂ ਜਾਵਾ ਐਪਸ ਨੂੰ ਸੁਰੱਖਿਅਤ ਤਰੀਕੇ ਨਾਲ ਅਪਗ੍ਰੇਡ ਕਰਨਾ
ਇੱਕ ਵਿਆਵਹਾਰਿਕ ਤਰੀਕਾ ਹੈ ਕਿ ਅਪਗ੍ਰੇਡਜ਼ ਨੂੰ ਪ੍ਰੋਡਕਟ ਵਰਕ ਵੱਜੋਂ ਸ treat ਕਰੋ:
- ਪਹਿਲਾਂ ਅਹੰਕਾਰਿਕ ਵਰਕਫ਼ਲੋਜ਼ ਦੇ ਆਸ-ਪਾਸ ਆਟੋਮੇਟਿਕ ਟੈਸਟ ਵਧਾਓ ਜਾਂ ਬਣਾਓ।
- ਛੋਟੇ ਕਦਮਾਂ ਵਿੱਚ ਅਪਗ੍ਰੇਡ ਕਰੋ (ਉਦਾਹਰਨ ਲਈ, ਇੱਕ LTS ਲਾਈਨ ਤੋਂ ਅਗਲੇ LTS `ਤੇ) ਅਤੇ ਕੇਵਲ ਕੰਪਾਇਲੇਸ਼ਨ ਨਹੀਂ, ਪ੍ਰਦਰਸ਼ਨ ਅਤੇ ਮੈਮੋਰੀ ਨੂੰ ਵੀ ਮਾਪੋ।
- ਸਟੇਜਿੰਗ ਵਿੱਚ ਪੁਰਾਣੀ ਅਤੇ ਨਵੀਂ ਵਰਜਨ ਇੱਕ-ਸਾਥ ਚਲਾਓ, ਅਤੇ ਰੋਲਬੈਕ ਯੋਜਨਾਵਾਂ ਸਪਸ਼ਟ ਰੱਖੋ।
- ਪਹਿਲਾਂ dependency ਦੀ ਇਨਵੈਂਟਰੀ ਬਣਾਓ; ਕਈ "Java ਅਪਗ੍ਰੇਡਜ਼" ਫੇਲ ਹੁੰਦੇ ਹਨ ਕਿਉਂਕਿ ਇੱਕ ਮਹੱਤਵਪੂਰਨ ਲਾਇਬ੍ਰੇਰੀ abandoned ਹੋ ਚੁੱਕੀ ਹੁੰਦੀ ਹੈ।
ਪਿਛੇਲੀ ਅਨੁਕੂਲਤਾ ਹਰ ਚੀਜ਼ ਨੂੰ ਬੇਕਦਰ ਨਹੀਂ ਬਣਾਉਂਦੀ—ਪਰ ਇਹ ਇੱਕ ਬੁਨਿਆਦ ਹੈ ਜੋ ਧੀਰੇ-ਧੀਰੇ, ਘੱਟ-ਖਤਰੇ ਵਾਲੀ ਮਾਡਰਨਾਈਜ਼ੇਸ਼ਨ ਨੂੰ ਸੰਭਵ ਬਣਾਉਂਦਾ ਹੈ।
ਅੱਜ ਦੀਆਂ ਬੈਕਐਂਡ ਟੀਮਾਂ ਲਈ ਮੁੱਖ ਸਬਕ
WORA ਨੇ ਅਸਲ ਵਿੱਚ ਕੀ ਦਿੱਤਾ (ਅਤੇ ਕੀ ਨਹੀਂ)
WORA ਸਭ ਤੋਂ ਵਧੀਯਾ ਉਸ ਪੱਧਰ ਤੇ ਕੰਮ ਕਰਦਾ ਹੈ ਜੋ ਜਾਵਾ ਨੇ ਵਾਅਦਾ ਕੀਤਾ: ਇੱਕੋ ਕੰਪਾਇਲ ਕੀਤਾ ਬਾਈਟਕੋਡ ਕਿਸੇ ਵੀ ਪਲੇਟਫਾਰਮ ਤੇ ਅਨੁਕੂਲ JVM ਨਾਲ ਚੱਲ ਸਕਦਾ ਹੈ। ਇਸ ਨੇ ਕਈ ਨੈਟਿਵ ਪਰਿਸਥਿਤੀ ਵਾਲੇ ਇਕੋਸਿਸਟਮਾਂ ਨਾਲੋਂ ਸਰਵਰ ਡਿਪਲੌਇਮੈਂਟ ਅਤੇ ਵੇਂਡਰ-ਨਿਰਭਰ ਪੈਕੇਜਿੰਗ ਨੂੰ ਕਾਫ਼ੀ ਆਸਾਨ ਬਣਾਇਆ।
ਜਿੱਥੇ ਇਹ ਘੱਟzor ਸੀ ਉਹ JVM ਸੀਮਾ ਦੇ ਆਲੇ-ਦੁਆਲੇ ਦੀਆਂ ਚੀਜ਼ਾਂ ਸਨ। ਓਐਸ, ਫਾਇਲਸਿਸਟਮ, ਨੈੱਟਵਰਕਿੰਗ ਡਿਫੌਲਟ, CPU ਆਰਕੀਟੈਕਚਰ, JVM ਫਲੈਗ, ਅਤੇ ਤੀਜੀ-ਪੱਖੀ ਨੈਟਿਵ ਨਿਰਭਰਤਾਵਾਂ ਅਜੇ ਵੀ ਮਾਇਨੇ ਰੱਖਦੀਆਂ ਹਨ। ਅਤੇ ਪ੍ਰਦਰਸ਼ਨ ਪੋਰਟੇਬਿਲਿਟੀ ਕਦੇ ਆਟੋਮੈਟਿਕ ਨਹੀਂ ਰਹੀ—ਤੁਸੀਂ ਕਿਤੇ ਵੀ ਚਲ ਸਕਦੇ ਹੋ, ਪਰ ਇਹ ਅਜੇ ਵੀ ਦੇਖਣਾ ਅਤੇ ਟਿਊਨ ਕਰਨਾ ਪੈਦਾ ਹੈ ਕਿ ਇਹ ਕਿਵੇਂ ਚੱਲ ਰਿਹਾ ਹੈ।
ਟੀਮਾਂ ਲਈ ਪ੍ਰਾਇਗਮੈਟਿਕ ਸਿੱਖਿਆਵਾਂ ਜੇ ਅੱਜ ਜਾਵਾ ਚੁਣ ਰਹੇ ਹੋ
ਜਾਵਾ ਦਾ ਸਭ ਤੋਂ ਵੱਡਾ ਲਾਭ ਕੋਈ ਇਕ ਫੀਚਰ ਨਹੀਂ; ਇਹ ਸਥਿਰ ਰਨਟਾਈਮ, ਮਹਿਰਦਮ ਟੂਲਿੰਗ, ਅਤੇ ਵੱਡਾ ਭਰਤੀ ਪੂਲ ਦਾ ਮਿਲਾਪ ਹੈ।
ਕੁਝ ਟੀਮ-ਸਤਹ ਦੇ ਸਬਕ ਜੋ ਅੱਗੇ ਲੈ ਜਾਣੇ ਯੋਗ ਹਨ:
- JVM ਨੂੰ ਇੱਕ ਪਲੇਟਫਾਰਮ ਵਾਂਗ ਸਮਝੋ: ਇੱਕ ਸਪੋਰਟ ਕੀਤੀ JDK ਡਿਸਟ੍ਰිබਿਊਸ਼ਨ ਚੁਣੋ, ਵਰਜਨ ਮਿਆਰੀਕਰਨ ਕਰੋ, ਅਤੇ ਯੋਜਨਾਬੱਧ ਤਰੀਕੇ ਨਾਲ ਅਪਗ੍ਰੇਡ ਕਰੋ।
- ਬੋਰਿੰਗ ਡਿਫੌਲਟ ਨੂੰ ਤਰਜੀਹ ਦਿਓ: ਬਿਲਡ, ਲੌਗਿੰਗ, ਮੈਟ੍ਰਿਕਸ, ਅਤੇ dependency ਮੈਨੇਜਮੈਂਟ ਸੇਵਾ-ਵਾਰ ਇੱਕਸਾਰ ਰੱਖੋ।
- অপਰੇਬਿਲਿਟੀ ਲਈ ਡਿਜ਼ਾਇਨ ਕਰੋ: ਸ਼ੁਰੂਆਤ ਵਿੱਚ ਹੀ ਮਾਨੀਟਰਨਗ, ਸੁਰੱਖਿਅਤ ਕਾਨਫਿਗ, ਅਤੇ ਪੇਸ਼ੀਵਾਰ ਮੈਮੋਰੀ/GC ਵਿਹਾਰ 'ਤੇ ਨਿਵੇਸ਼ ਕਰੋ।
- ਇਕੋਸਿਸਟਮ ਤੇ ਨਿਰਭਰ ਰਵਾਇਆਂ ਔਨ-ਅਰਥ: ਫਰੇਮਵਰਕ ਅਤੇ ਲਾਇਬ੍ਰੇਰੀਆਂ ਸਮਾਂ ਬਚਾਉਂਦੀਆਂ ਹਨ, ਪਰ dependency ਫੈਲਾ ਹੋਣ ਅਤੇ ਸੁਰੱਖਿਆ ਅਪਡੇਟ ਨੂੰ ਆਡੀਟ ਕਰੋ।
ਫੈਸਲਾ-ਗ੍ਰਹਣ ਲਈ ਤੱਤ: ਕਦੋਂ ਜਾਵਾ ਸਹੀ ਚੋਣ ਹੈ
ਜਦੋਂ ਤੁਹਾਡੀ ਟੀਮ ਲੰਬੇ ਸਮੇਂ ਰੱਖ-ਰਖਾਅ, ਮਜ਼ਬੂਤ ਲਾਇਬ੍ਰੇਰੀ ਸਮਰਥਨ, ਅਤੇ ਭਰੋਸੇਯੋਗ ਪ੍ਰੋਡਕਸ਼ਨ ਓਪਰੇਸ਼ਨ ਨੂੰ ਅਹਿਮ ਸਮਝਦੀ ਹੈ ਤਾਂ ਜਾਵਾ ਚੁਣੋ।
ਇਹ ਤੱਤ ਚੈੱਕ ਕਰੋ:
- ਟੀਮ ਸਖ਼ਲਤਾਂ: ਕੀ ਤੁਹਾਡੇ ਕੋਲ ਪਹਿਲਾਂ ਹੀ Java/Spring ਅਨੁਭਵ ਹੈ, ਜਾਂ ਤੁਹਾਨੂੰ ਸ਼ੁਰੂ ਤੋਂ ਸਿਖਾਉਣਾ ਪਵੇਗਾ?
- ਰਨਟਾਈਮ ਸੀਮਾਵਾਂ: ਕੀ startup ਸਮਾਂ ਅਤੇ ਮੈਮੋਰੀ ਫੁਟਪਰਿੰਟ ਨੁਹਾਂਤੀਆਂ ਹਨ (ਕੁਝ ਵਰਕਲੋਡ Go/Node ਨੂੰ ਤਰਜੀਹ ਦਿੰਦੇ ਹਨ), ਜਾਂ throughput ਅਤੇ ਸਥਿਰਤਾ ਪ੍ਰਾਥਮਿਕਤਾ ਹੈ?
- ਇਕੋਸਿਸਟਮ ਦੀ ਲੋੜਾਂ: ਕੀ ਤੁਹਾਨੂੰ ਪ੍ਰਸਿੱਧ ਮੇਸੇਜਿੰਗ, ਡੇਟਾਬੇਸ ਡਰਾਈਵਰ, ਅਬਜ਼ਰਵੇਬਿਲਿਟੀ, ਜਾਂ ਐਂਟਰਪ੍ਰਾਈਜ਼ ਇੰਟੀਗਰੇਸ਼ਨ ਦੀ ਲੋੜ ਹੈ?
- ਲੰਬੀ ਉਮਰ: ਕੀ ਇਹ ਸਿਸਟਮ ਸਾਲਾਂ ਤੱਕ ਘੱਟ ਮੁੜ-ਲਿਖੇ ਰਹੇਗਾ?
ਅਗਲੇ ਕਦਮ
ਜੇ ਤੁਸੀਂ ਨਵੇਂ ਬੈਕਐਂਡ ਜਾਂ ਮਾਡਰਨਾਈਜ਼ੇਸ਼ਨ ਪ੍ਰਯੋਗ ਲਈ ਜਾਵਾ ਦਾ ਮੁੱਲਾਂਕਣ ਕਰ ਰਹੇ ਹੋ, ਤਾਂ ਇੱਕ ਛੋਟੇ ਪਾਇਲਟ ਸਰਵਿਸ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ, ਇੱਕ ਅਪਗ੍ਰੇਡ/ਪੈਚਿੰਗ ਨੀਤੀ ਪਰਿਭਾਸ਼ਿਤ ਕਰੋ, ਅਤੇ ਫਰੇਮਵਰਕ ਬੇਜ਼ਲਾਈਨ 'ਤੇ ਸਹਿਮਤੀ ਕਰੋ। ਜੇ ਤੁਸੀਂ ਉਨ੍ਹਾਂ ਚੋਣਾਂ ਦੀ ਸਕੋਪਿੰਗ 'ਚ ਮਦਦ ਚਾਹੁੰਦੇ ਹੋ, ਤਾਂ contact ਪੇਜ਼ ਰਾਹੀਂ ਸੰਪਰਕ ਕਰਨ ਦੇ ਵਿਕਲਪ 'ਤੇ ਵਿਚਾਰ ਕਰੋ।
ਜੇ ਤੁਸੀਂ ਮੌਜੂਦਾ ਜਾਵਾ ਵਿਰਾਸਤ ਦੇ ਇਰਗਿਰਾਓਂ ਵੱਲ ਤੇਜ਼ੀ ਨਾਲ "ਸਾਇਡਕੈਰ" ਸਰਵਿਸਜ਼ ਜਾਂ ਅੰਦਰੂਨੀ ਟੂਲਜ਼ ਬਣਾਉਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰ ਰਹੇ ਹੋ, ਤਾਂ Koder.ai ਵਰਗੇ ਪਲੇਟਫਾਰਮ ਤੁਹਾਨੂੰ ਚੈਟ ਰਾਹੀਂ ਇੱਕ ਵਿਚਾਰ ਤੋਂ ਕੰਮ ਕਰਦੇ ਵੈਬ/ਸਰਵਰ/ਮੋਬਾਈਲ ਐਪ ਤੱਕ ਲੈ ਜਾ ਸਕਦੇ ਹਨ—ਪ੍ਰੋਟੋਟਾਈਪਿੰਗ ਲਈ ਉਪਯੋਗ। Koder.ai ਸੋਰਸ ਕੋਡ ਐਕਸਪੋਰਟ, ਡਿਪਲੌਇ/ਹੋਸਟਿੰਗ, ਕਸਟਮ ਡੋਮੇਨ, ਅਤੇ ਸਨੈਪਸ਼ੌਟ/ਰੋਲਬੈਕ ਸਹਿਯੋਗ ਕਰਦਾ ਹੈ, ਜੋ ਜਾਵਾ ਟੀਮਾਂ ਦੀਆਂ ਹੀ ਓਪਰੇਸ਼ਨਲ ਸੋਚਾਂ ਨਾਲ ਸੁਮੇਿਲ ਹੈ: ਦੁਹਰਾਏ ਜਾਂਦੇ ਬਿਲਡ, ਇਕਸਾਰ ਮਹੋਲ, ਅਤੇ ਸੁਰੱਖਿਅਤ ਇਟਰੇਸ਼ਨ।