ਕੁਆਰਕਸ ਵਿੱਚ ਮੂਲ ਸੰਕਲਨ - ਇਹ ਮਹੱਤਵਪੂਰਨ ਕਿਉਂ ਹੈ

ਸਾਰਿਆਂ ਨੂੰ ਸਤਿ ਸ਼੍ਰੀ ਅਕਾਲ! ਇਹ ਕੁਆਰਕਸ 'ਤੇ ਸਾਡੀ ਲੜੀ ਦੀ ਦੂਜੀ ਪੋਸਟ ਹੈ - ਅੱਜ ਅਸੀਂ ਮੂਲ ਸੰਕਲਨ ਬਾਰੇ ਗੱਲ ਕਰਾਂਗੇ।

ਕਵਾਕਰਸ ਲਈ ਤਿਆਰ ਕੀਤਾ ਗਿਆ ਜਾਵਾ ਸਟੈਕ ਹੈ ਕਬਰਨੇਟਿਸ. ਹਾਲਾਂਕਿ ਇੱਥੇ ਨਿਸ਼ਚਿਤ ਤੌਰ 'ਤੇ ਹੋਰ ਬਹੁਤ ਕੁਝ ਕਰਨ ਲਈ ਹੈ, ਅਸੀਂ JVM ਅਤੇ ਕਈ ਫਰੇਮਵਰਕ ਨੂੰ ਅਨੁਕੂਲ ਬਣਾਉਣ ਸਮੇਤ ਬਹੁਤ ਸਾਰੇ ਪਹਿਲੂਆਂ 'ਤੇ ਬਹੁਤ ਵਧੀਆ ਕੰਮ ਕੀਤਾ ਹੈ। ਕੁਆਰਕਸ ਦੀ ਇੱਕ ਵਿਸ਼ੇਸ਼ਤਾ ਜਿਸ ਨੇ ਡਿਵੈਲਪਰਾਂ ਦੀ ਵਧੀ ਹੋਈ ਦਿਲਚਸਪੀ ਨੂੰ ਆਕਰਸ਼ਿਤ ਕੀਤਾ ਹੈ, ਜਾਵਾ ਕੋਡ ਨੂੰ ਇੱਕ ਖਾਸ ਓਪਰੇਟਿੰਗ ਸਿਸਟਮ (ਅਖੌਤੀ "ਨੇਟਿਵ ਕੰਪਾਈਲੇਸ਼ਨ") ਲਈ ਐਗਜ਼ੀਕਿਊਟੇਬਲ ਫਾਈਲਾਂ ਵਿੱਚ ਬਦਲਣ ਲਈ ਇਸਦਾ ਵਿਆਪਕ, ਸਹਿਜ ਪਹੁੰਚ ਹੈ, C ਅਤੇ C++ ਦੇ ਸਮਾਨ, ਜਿੱਥੇ ਅਜਿਹੇ ਸੰਕਲਨ ਆਮ ਤੌਰ 'ਤੇ ਬਿਲਡ, ਟੈਸਟ, ਅਤੇ ਡਿਪਲਾਇਮੈਂਟ ਦੇ ਚੱਕਰ ਦੇ ਅੰਤ 'ਤੇ ਹੁੰਦਾ ਹੈ।

ਅਤੇ ਜਦੋਂ ਕਿ ਮੂਲ ਸੰਕਲਨ ਮਹੱਤਵਪੂਰਨ ਹੈ, ਜਿਵੇਂ ਕਿ ਅਸੀਂ ਹੇਠਾਂ ਦਿਖਾਵਾਂਗੇ, ਇਹ ਨੋਟ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ ਕਿ ਕੁਆਰਕਸ ਸਭ ਤੋਂ ਆਮ ਜਾਵਾ ਮਸ਼ੀਨ, ਓਪਨਜੇਡੀਕੇ ਹੌਟਸਪੌਟ 'ਤੇ ਅਸਲ ਵਿੱਚ ਚੰਗੀ ਤਰ੍ਹਾਂ ਚੱਲਦਾ ਹੈ, ਪ੍ਰਦਰਸ਼ਨ ਸੁਧਾਰਾਂ ਲਈ ਧੰਨਵਾਦ ਜੋ ਅਸੀਂ ਪੂਰੇ ਸਟੈਕ ਵਿੱਚ ਲਾਗੂ ਕੀਤੇ ਹਨ। ਇਸ ਲਈ, ਮੂਲ ਸੰਕਲਨ ਨੂੰ ਇੱਕ ਵਾਧੂ ਬੋਨਸ ਵਜੋਂ ਮੰਨਿਆ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ ਜੋ ਲੋੜੀਂਦੇ ਜਾਂ ਲੋੜੀਂਦੇ ਤੌਰ 'ਤੇ ਵਰਤਿਆ ਜਾ ਸਕਦਾ ਹੈ। ਵਾਸਤਵ ਵਿੱਚ, ਜਦੋਂ ਮੂਲ ਚਿੱਤਰਾਂ ਦੀ ਗੱਲ ਆਉਂਦੀ ਹੈ ਤਾਂ ਕੁਆਰਕਸ ਓਪਨਜੇਡੀਕੇ 'ਤੇ ਬਹੁਤ ਜ਼ਿਆਦਾ ਨਿਰਭਰ ਕਰਦਾ ਹੈ। ਅਤੇ ਡਿਵੈਲਪਰਾਂ ਦੁਆਰਾ ਗਰਮਜੋਸ਼ੀ ਨਾਲ ਸਵੀਕਾਰ ਕੀਤਾ ਗਿਆ dev ਮੋਡ, ਹੌਟਸਪੌਟ ਵਿੱਚ ਲਾਗੂ ਕੀਤੇ ਗਤੀਸ਼ੀਲ ਕੋਡ ਐਗਜ਼ੀਕਿਊਸ਼ਨ ਦੀਆਂ ਉੱਨਤ ਸਮਰੱਥਾਵਾਂ ਦੇ ਕਾਰਨ ਤਬਦੀਲੀਆਂ ਦੀ ਲਗਭਗ ਤਤਕਾਲ ਜਾਂਚ ਨੂੰ ਯਕੀਨੀ ਬਣਾਉਂਦਾ ਹੈ। ਇਸ ਤੋਂ ਇਲਾਵਾ, ਮੂਲ GraalVM ਚਿੱਤਰ ਬਣਾਉਣ ਵੇਲੇ, OpenJDK ਕਲਾਸ ਲਾਇਬ੍ਰੇਰੀ ਅਤੇ ਹੌਟਸਪੌਟ ਸਮਰੱਥਾਵਾਂ ਦੀ ਵਰਤੋਂ ਕੀਤੀ ਜਾਂਦੀ ਹੈ।

ਇਸ ਲਈ ਤੁਹਾਨੂੰ ਮੂਲ ਸੰਕਲਨ ਦੀ ਲੋੜ ਕਿਉਂ ਹੈ ਜੇਕਰ ਸਭ ਕੁਝ ਪਹਿਲਾਂ ਹੀ ਪੂਰੀ ਤਰ੍ਹਾਂ ਅਨੁਕੂਲ ਹੈ? ਅਸੀਂ ਹੇਠਾਂ ਇਸ ਸਵਾਲ ਦਾ ਜਵਾਬ ਦੇਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਾਂਗੇ.

ਆਉ ਸਪੱਸ਼ਟ ਨਾਲ ਸ਼ੁਰੂ ਕਰੀਏ: Red Hat ਕੋਲ ਪ੍ਰੋਜੈਕਟ ਵਿਕਾਸ ਦੌਰਾਨ JVM, ਸਟੈਕ ਅਤੇ ਫਰੇਮਵਰਕ ਨੂੰ ਅਨੁਕੂਲ ਬਣਾਉਣ ਦਾ ਵਿਆਪਕ ਅਨੁਭਵ ਹੈ। ਜੇਬੌਸ, ਸਮੇਤ:

• ਪਲੇਟਫਾਰਮ 'ਤੇ ਕਲਾਉਡ ਵਿੱਚ ਕੰਮ ਕਰਨ ਵਾਲਾ ਪਹਿਲਾ ਐਪਲੀਕੇਸ਼ਨ ਸਰਵਰ ਰੈੱਡ ਹੈੱਟ ਓਪਨ ਸ਼ੀਫਟ.
• ਕੰਪਿਊਟਰਾਂ 'ਤੇ ਚੱਲਣ ਲਈ ਪਹਿਲਾ ਐਪਲੀਕੇਸ਼ਨ ਸਰਵਰ ਪਲੱਗ ਪੀਸੀ.
• ਚਲਾਉਣ ਲਈ ਪਹਿਲਾ ਐਪਲੀਕੇਸ਼ਨ ਸਰਵਰ ਰਾਸਬ੍ਰੀ ਪੀ.
• ਡਿਵਾਈਸਾਂ 'ਤੇ ਚੱਲ ਰਹੇ ਪ੍ਰੋਜੈਕਟਾਂ ਦੀ ਇੱਕ ਸ਼੍ਰੇਣੀ ਛੁਪਾਓ.

ਅਸੀਂ ਕਈ ਸਾਲਾਂ ਤੋਂ ਕਲਾਉਡ ਵਿੱਚ ਜਾਵਾ ਐਪਲੀਕੇਸ਼ਨਾਂ ਨੂੰ ਚਲਾਉਣ ਦੀਆਂ ਚੁਣੌਤੀਆਂ ਨਾਲ ਨਜਿੱਠ ਰਹੇ ਹਾਂ ਅਤੇ ਸਰੋਤ-ਪ੍ਰਤੀਬੰਧਿਤ ਡਿਵਾਈਸਾਂ (ਪੜ੍ਹੋ: IoT) ਤੇ ਪ੍ਰਦਰਸ਼ਨ ਅਤੇ ਮੈਮੋਰੀ ਅਨੁਕੂਲਤਾ ਦੇ ਰੂਪ ਵਿੱਚ JVM ਤੋਂ ਵੱਧ ਤੋਂ ਵੱਧ ਪ੍ਰਾਪਤ ਕਰਨਾ ਸਿੱਖਿਆ ਹੈ। ਹੋਰ ਬਹੁਤ ਸਾਰੇ ਲੋਕਾਂ ਵਾਂਗ, ਅਸੀਂ ਲੰਬੇ ਸਮੇਂ ਤੋਂ ਜਾਵਾ ਐਪਲੀਕੇਸ਼ਨਾਂ ਦੇ ਮੂਲ ਸੰਕਲਨ ਨਾਲ ਕੰਮ ਕਰ ਰਹੇ ਹਾਂ ਜੀ.ਸੀ.ਜੇ., ਏਵੀਅਨ, ਐਕਸਲਜ਼ੀਅਰ ਜੇ.ਈ.ਟੀ ਅਤੇ ਵੀ ਡਾਲਕੀ ਅਤੇ ਅਸੀਂ ਇਸ ਪਹੁੰਚ ਦੇ ਚੰਗੇ ਅਤੇ ਨੁਕਸਾਨਾਂ ਤੋਂ ਚੰਗੀ ਤਰ੍ਹਾਂ ਜਾਣੂ ਹਾਂ (ਉਦਾਹਰਨ ਲਈ, "ਇੱਕ ਵਾਰ ਬਣਾਓ - ਕਿਤੇ ਵੀ ਚਲਾਓ" ਦੀ ਸਰਵਵਿਆਪਕਤਾ ਵਿੱਚ ਚੋਣ ਕਰਨ ਦੀ ਦੁਬਿਧਾ ਅਤੇ ਇਹ ਤੱਥ ਕਿ ਕੰਪਾਇਲ ਕੀਤੀਆਂ ਐਪਲੀਕੇਸ਼ਨਾਂ ਛੋਟੀਆਂ ਹਨ ਅਤੇ ਤੇਜ਼ੀ ਨਾਲ ਚੱਲਦੀਆਂ ਹਨ)।

ਇਨ੍ਹਾਂ ਫ਼ਾਇਦੇ ਅਤੇ ਨੁਕਸਾਨਾਂ 'ਤੇ ਵਿਚਾਰ ਕਰਨਾ ਮਹੱਤਵਪੂਰਨ ਕਿਉਂ ਹੈ? ਕਿਉਂਕਿ ਕੁਝ ਸਥਿਤੀਆਂ ਵਿੱਚ ਉਹਨਾਂ ਦਾ ਅਨੁਪਾਤ ਨਿਰਣਾਇਕ ਬਣ ਜਾਂਦਾ ਹੈ:

• ਉਦਾਹਰਨ ਲਈ, ਸਰਵਰ ਰਹਿਤ/ਇਵੈਂਟ-ਸੰਚਾਲਿਤ ਵਾਤਾਵਰਣ ਵਿੱਚ ਜਿੱਥੇ ਸੇਵਾਵਾਂ ਨੂੰ ਸਿਰਫ਼ ਸ਼ੁਰੂ ਕਰਨਾ ਹੋਵੇਗਾ ਘਟਨਾਵਾਂ ਦਾ ਜਵਾਬ ਦੇਣ ਲਈ ਸਮਾਂ ਪ੍ਰਾਪਤ ਕਰਨ ਲਈ (ਸਖਤ ਜਾਂ ਨਰਮ) ਅਸਲ ਸਮੇਂ ਵਿੱਚ. ਲੰਬੇ ਸਮੇਂ ਤੱਕ ਚੱਲਣ ਵਾਲੀਆਂ ਨਿਰੰਤਰ ਸੇਵਾਵਾਂ ਦੇ ਉਲਟ, ਇੱਥੇ ਇੱਕ ਕੋਲਡ ਸਟਾਰਟ ਦੀ ਮਿਆਦ ਇੱਕ ਬੇਨਤੀ ਦੇ ਜਵਾਬ ਦੇ ਸਮੇਂ ਨੂੰ ਗੰਭੀਰ ਰੂਪ ਵਿੱਚ ਵਧਾਉਂਦੀ ਹੈ। JVM ਨੂੰ ਅਜੇ ਵੀ ਸ਼ੁਰੂ ਹੋਣ ਵਿੱਚ ਕਾਫ਼ੀ ਸਮਾਂ ਲੱਗਦਾ ਹੈ, ਅਤੇ ਜਦੋਂ ਕਿ ਇਸਨੂੰ ਕੁਝ ਮਾਮਲਿਆਂ ਵਿੱਚ ਸ਼ੁੱਧ ਹਾਰਡਵੇਅਰ ਤਰੀਕਿਆਂ ਦੁਆਰਾ ਘਟਾਇਆ ਜਾ ਸਕਦਾ ਹੈ, ਇੱਕ ਸਕਿੰਟ ਅਤੇ 5 ਮਿਲੀਸਕਿੰਟ ਦਾ ਅੰਤਰ ਜੀਵਨ ਅਤੇ ਮੌਤ ਵਿੱਚ ਅੰਤਰ ਹੋ ਸਕਦਾ ਹੈ। ਹਾਂ, ਇੱਥੇ ਤੁਸੀਂ ਜਾਵਾ ਮਸ਼ੀਨਾਂ ਦਾ ਇੱਕ ਗਰਮ ਰਿਜ਼ਰਵ ਬਣਾਉਣ ਦੇ ਨਾਲ ਖੇਡ ਸਕਦੇ ਹੋ (ਜੋ, ਉਦਾਹਰਨ ਲਈ, ਅਸੀਂ ਇਸ ਨਾਲ ਕੀਤਾ ਸੀ ਓਪਨਵਿਸਕ ਨੂੰ ਨੇਟਿਵ ਵਿੱਚ ਪੋਰਟ ਕਰਨਾ), ਪਰ ਇਹ ਆਪਣੇ ਆਪ ਵਿੱਚ ਇਹ ਗਾਰੰਟੀ ਨਹੀਂ ਦਿੰਦਾ ਹੈ ਕਿ ਲੋਡ ਸਕੇਲ ਦੇ ਰੂਪ ਵਿੱਚ ਬੇਨਤੀਆਂ ਦੀ ਪ੍ਰਕਿਰਿਆ ਕਰਨ ਲਈ ਲੋੜੀਂਦੇ JVM ਹੋਣਗੇ। ਅਤੇ ਆਰਥਿਕ ਦ੍ਰਿਸ਼ਟੀਕੋਣ ਤੋਂ, ਇਹ ਸ਼ਾਇਦ ਸਭ ਤੋਂ ਸਹੀ ਵਿਕਲਪ ਨਹੀਂ ਹੈ.
• ਇਸ ਤੋਂ ਇਲਾਵਾ, ਇਕ ਹੋਰ ਪਹਿਲੂ ਹੈ ਜੋ ਅਕਸਰ ਸਾਹਮਣੇ ਆਉਂਦਾ ਹੈ: ਮਲਟੀਟੇਨੈਂਸੀ। ਇਸ ਤੱਥ ਦੇ ਬਾਵਜੂਦ ਕਿ ਜੇਵੀਐਮ ਆਪਣੀਆਂ ਸਮਰੱਥਾਵਾਂ ਵਿੱਚ ਓਪਰੇਟਿੰਗ ਸਿਸਟਮਾਂ ਦੇ ਬਹੁਤ ਨੇੜੇ ਆ ਗਏ ਹਨ, ਉਹ ਅਜੇ ਵੀ ਉਹ ਕਰਨ ਦੇ ਸਮਰੱਥ ਨਹੀਂ ਹਨ ਜੋ ਅਸੀਂ ਲੀਨਕਸ ਵਿੱਚ ਇੰਨੇ ਆਦੀ ਹਾਂ - ਅਲੱਗ ਕਰਨ ਵਾਲੀਆਂ ਪ੍ਰਕਿਰਿਆਵਾਂ. ਇਸ ਲਈ, ਇੱਕ ਥਰਿੱਡ ਦੀ ਅਸਫਲਤਾ ਪੂਰੀ ਜਾਵਾ ਮਸ਼ੀਨ ਨੂੰ ਹੇਠਾਂ ਲਿਆ ਸਕਦੀ ਹੈ. ਬਹੁਤ ਸਾਰੇ ਲੋਕ ਅਸਫਲਤਾ ਦੇ ਨਤੀਜਿਆਂ ਨੂੰ ਘੱਟ ਕਰਨ ਲਈ ਹਰੇਕ ਉਪਭੋਗਤਾ ਦੀ ਐਪਲੀਕੇਸ਼ਨ ਲਈ ਇੱਕ ਵੱਖਰਾ JVM ਸਮਰਪਿਤ ਕਰਕੇ ਇਸ ਕਮੀ ਨੂੰ ਪੂਰਾ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦੇ ਹਨ। ਇਹ ਕਾਫ਼ੀ ਤਰਕਪੂਰਨ ਹੈ, ਪਰ ਸਕੇਲਿੰਗ ਦੇ ਨਾਲ ਚੰਗੀ ਤਰ੍ਹਾਂ ਫਿੱਟ ਨਹੀਂ ਬੈਠਦਾ।
• ਇਸ ਤੋਂ ਇਲਾਵਾ, ਕਲਾਉਡ-ਅਧਾਰਿਤ ਐਪਲੀਕੇਸ਼ਨਾਂ ਲਈ, ਇੱਕ ਮਹੱਤਵਪੂਰਨ ਸੂਚਕ ਹੋਸਟ 'ਤੇ ਸੇਵਾਵਾਂ ਦੀ ਘਣਤਾ ਹੈ। ਕਾਰਜਪ੍ਰਣਾਲੀ ਵਿੱਚ ਤਬਦੀਲੀ 12 ਐਪਲੀਕੇਸ਼ਨ ਕਾਰਕ, ਮਾਈਕ੍ਰੋ ਸਰਵਿਸਿਜ਼ ਅਤੇ ਕੁਬਰਨੇਟਸ ਪ੍ਰਤੀ ਐਪਲੀਕੇਸ਼ਨ ਜਾਵਾ ਮਸ਼ੀਨਾਂ ਦੀ ਗਿਣਤੀ ਵਧਾਉਂਦੇ ਹਨ। ਭਾਵ, ਇੱਕ ਪਾਸੇ, ਇਹ ਸਭ ਲਚਕੀਲਾਤਾ ਅਤੇ ਭਰੋਸੇਯੋਗਤਾ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ, ਪਰ ਉਸੇ ਸਮੇਂ ਸੇਵਾ ਦੇ ਰੂਪ ਵਿੱਚ ਬੇਸ ਮੈਮੋਰੀ ਦੀ ਖਪਤ ਵੀ ਵਧਦੀ ਹੈ, ਅਤੇ ਇਹਨਾਂ ਵਿੱਚੋਂ ਕੁਝ ਖਰਚੇ ਹਮੇਸ਼ਾ ਸਖਤੀ ਨਾਲ ਜ਼ਰੂਰੀ ਨਹੀਂ ਹੁੰਦੇ ਹਨ. ਸਥਿਰ ਤੌਰ 'ਤੇ ਕੰਪਾਇਲ ਕੀਤੀਆਂ ਐਗਜ਼ੀਕਿਊਟੇਬਲ ਫਾਈਲਾਂ ਨੂੰ ਵੱਖ-ਵੱਖ ਅਨੁਕੂਲਨ ਤਕਨੀਕਾਂ, ਜਿਵੇਂ ਕਿ ਘੱਟ-ਪੱਧਰ ਦੇ ਡੈੱਡ-ਕੋਡ ਦੇ ਖਾਤਮੇ ਦੇ ਕਾਰਨ ਇੱਥੇ ਫਾਇਦਾ ਹੁੰਦਾ ਹੈ, ਜਦੋਂ ਅੰਤਿਮ ਚਿੱਤਰ ਵਿੱਚ ਫਰੇਮਵਰਕ ਦੇ ਸਿਰਫ਼ ਉਹ ਹਿੱਸੇ ਸ਼ਾਮਲ ਹੁੰਦੇ ਹਨ (ਜੇਡੀਕੇ ਸਮੇਤ) ਜੋ ਸੇਵਾ ਅਸਲ ਵਿੱਚ ਵਰਤਦੀ ਹੈ। ਇਸ ਲਈ, ਕੁਆਰਕਸ ਨੇਟਿਵ ਕੰਪਾਈਲੇਸ਼ਨ ਸੁਰੱਖਿਆ ਨਾਲ ਸਮਝੌਤਾ ਕੀਤੇ ਬਿਨਾਂ ਹੋਸਟ 'ਤੇ ਸੇਵਾ ਉਦਾਹਰਨਾਂ ਨੂੰ ਸੰਘਣੀ ਰੱਖਣ ਵਿੱਚ ਮਦਦ ਕਰਦਾ ਹੈ।

ਵਾਸਤਵ ਵਿੱਚ, ਉਪਰੋਕਤ ਦਲੀਲਾਂ ਕੁਆਰਕਸ ਪ੍ਰੋਜੈਕਟ ਭਾਗੀਦਾਰਾਂ ਦੇ ਦ੍ਰਿਸ਼ਟੀਕੋਣ ਤੋਂ ਮੂਲ ਸੰਕਲਨ ਦੀ ਤਰਕ ਨੂੰ ਸਮਝਣ ਲਈ ਪਹਿਲਾਂ ਹੀ ਕਾਫੀ ਹਨ। ਹਾਲਾਂਕਿ, ਇੱਕ ਹੋਰ, ਗੈਰ-ਤਕਨੀਕੀ, ਪਰ ਇਹ ਵੀ ਮਹੱਤਵਪੂਰਨ ਕਾਰਨ ਹੈ: ਹਾਲ ਹੀ ਦੇ ਸਾਲਾਂ ਵਿੱਚ, ਬਹੁਤ ਸਾਰੇ ਪ੍ਰੋਗਰਾਮਰ ਅਤੇ ਵਿਕਾਸ ਕੰਪਨੀਆਂ ਨੇ ਨਵੀਂ ਪ੍ਰੋਗਰਾਮਿੰਗ ਭਾਸ਼ਾਵਾਂ ਦੇ ਹੱਕ ਵਿੱਚ ਜਾਵਾ ਨੂੰ ਛੱਡ ਦਿੱਤਾ ਹੈ, ਇਹ ਮੰਨਦੇ ਹੋਏ ਕਿ ਜਾਵਾ, ਇਸਦੇ JVM, ਸਟੈਕ ਅਤੇ ਫਰੇਮਵਰਕ ਦੇ ਨਾਲ, ਬਹੁਤ ਬਣ ਗਿਆ ਹੈ. ਯਾਦਦਾਸ਼ਤ ਦੀ ਭੁੱਖ, ਬਹੁਤ ਹੌਲੀ, ਆਦਿ

ਹਾਲਾਂਕਿ, ਕਿਸੇ ਵੀ ਸਮੱਸਿਆ ਨੂੰ ਹੱਲ ਕਰਨ ਲਈ ਉਸੇ ਸਾਧਨ ਦੀ ਵਰਤੋਂ ਕਰਨ ਦੀ ਆਦਤ ਹੈ ਇਹ ਹਮੇਸ਼ਾ ਸਹੀ ਨਹੀਂ ਹੁੰਦਾ. ਕਈ ਵਾਰ ਇੱਕ ਕਦਮ ਪਿੱਛੇ ਹਟਣਾ ਅਤੇ ਕੁਝ ਹੋਰ ਲੱਭਣਾ ਬਿਹਤਰ ਹੁੰਦਾ ਹੈ। ਅਤੇ ਜੇਕਰ ਕੁਆਰਕਸ ਲੋਕਾਂ ਨੂੰ ਰੋਕਦਾ ਹੈ ਅਤੇ ਸੋਚਦਾ ਹੈ, ਤਾਂ ਇਹ ਪੂਰੇ ਜਾਵਾ ਈਕੋਸਿਸਟਮ ਲਈ ਚੰਗਾ ਹੈ। ਕੁਆਰਕਸ ਇੱਕ ਨਵੀਨਤਾਕਾਰੀ ਦ੍ਰਿਸ਼ ਨੂੰ ਦਰਸਾਉਂਦਾ ਹੈ ਕਿ ਕਿਵੇਂ ਵਧੇਰੇ ਕੁਸ਼ਲ ਐਪਲੀਕੇਸ਼ਨਾਂ ਨੂੰ ਬਣਾਉਣਾ ਹੈ, ਜਾਵਾ ਨੂੰ ਸਰਵਰ ਰਹਿਤ ਵਰਗੇ ਨਵੇਂ ਐਪਲੀਕੇਸ਼ਨ ਆਰਕੀਟੈਕਚਰ ਲਈ ਵਧੇਰੇ ਢੁਕਵਾਂ ਬਣਾਉਂਦਾ ਹੈ। ਇਸ ਤੋਂ ਇਲਾਵਾ, ਇਸਦੀ ਵਿਸਤ੍ਰਿਤਤਾ ਦੇ ਕਾਰਨ, ਕੁਆਰਕਸ ਵਿੱਚ ਉਮੀਦ ਹੈ ਕਿ ਜਾਵਾ ਐਕਸਟੈਂਸ਼ਨਾਂ ਦਾ ਇੱਕ ਪੂਰਾ ਈਕੋਸਿਸਟਮ ਹੋਵੇਗਾ, ਜੋ ਕਿ ਫਰੇਮਵਰਕ ਦੀ ਸੰਖਿਆ ਵਿੱਚ ਮਹੱਤਵਪੂਰਨ ਵਾਧਾ ਕਰੇਗਾ ਜੋ ਬਾਕਸ ਦੇ ਬਾਹਰ ਐਪਲੀਕੇਸ਼ਨਾਂ ਵਿੱਚ ਮੂਲ ਸੰਕਲਨ ਦਾ ਸਮਰਥਨ ਕਰੇਗਾ।

ਸਰੋਤ: www.habr.com