فك جافاي

Question

لدينا تطبيق Java EE لم يعد بائعًا موجودًا (بسبب الإفلاس). لسوء الحظ ، يتعين علينا إجراء بعض التغييرات على وظائف التطبيق ، وهذا يعني عكس هندسة تطبيق Javaee.

نستخدم JD-Gui لعكس الهندسة حوالي 70 ٪ من التطبيق/الفصول ، ثم قم بتعديلها يدويًا للبناء في Eclipse.

ومع ذلك ، ليس من السهل بناء المساند لأنها تنتجها المولنات؟ ما هي الأدوات التي يمكنني استخدامها للمساعدة بشكل أكبر؟

يحرر:

هذا مثال على الصعوبات:

return ((SchemaTypeSystem)Class.forName(
    "org.apache.xmlbeans.impl.schema.SchemaTypeSystemImpl",
    true,
    class$schema$system$s322D2AAD7A06BA82525CDB874D86D59A$TypeSystemHolder.getClassLoader())
        .getConstructor(new Class[] { Class.class })
        .newInstance(new Object[] { TypeSystemHolder.class }));

من الصعب معرفة ما هو

class$schema$system$s322D2AAD7A06BA82525CDB874D86D59A$TypeSystemHolder.getClassLoader())

Answer 1

أعط جاد (http://www.varaneckas.com/jad) محاولة.

الرمز الإشكالي الذي تظهره يعادل ما يلي:

1) Class class$schema$system$s322D2AAD7A06BA82525CDB874D86D59A$TypeSystemHolder;
2) ClassLoader loader = class$schema$system$s322D2AAD7A06BA82525CDB874D86D59A$TypeSystemHolder.getClassLoader();
3) Class type = Class.forName("org.apache.xmlbeans.impl.schema.SchemaTypeSystemImpl", true, loader);
4) Constructor ctor = type.getConstructor(Class.class);
5) Object obj = ctor.newInstance(TypeSystemHolder.class);
6) SchemaTypeSystem result = (SchemaTypeSystem) obj;
7) return result;

الجزء الذي تواجهه مشكلة هو السطر 1 ، والذي يمثل متغيرًا محليًا أو حقلًا (ربما ثابتًا). يقوم برنامج التحويل البرمجي Java بتحويل تعبير "TypeSystemholder.class" إلى استدعاء من GetClass لتخزين النتيجة في مجال ثابت. يحدث هذا التهيئة مرة واحدة في كل فئة تشير إلى "typestystemholder.class" ويستبدل المترجم كل مكالمات تستخدم هذا التعبير مع الوصول إلى الحقل.

تفشل معظم decompilers في ترجمة هذا المصطلح مرة أخرى إلى المكالمة الأصلية إلى "typestystemholder.class" لكن Jad يتعامل مع هذا بشكل جيد. بالإضافة إلى ذلك ، هناك مكون إضافي يدمج Jad (وغيرها) في Eclipse (http://jadclipse.sourceforge.net).

لسوء الحظ ، لا تتعامل decompilers مع كل تسلسل رمز تم إنشاؤه بواسطة برنامج التحويل البرمجي ، لذا فإن بعض إعادة كتابة اليدوي مطلوب دائمًا. على سبيل المثال ، يجوز لمرجم Java إنشاء رمز لمجموعة معالجة استثناء واحد تتداخل مع رمز لمجموعة معالجة استثناء أخرى. لا تستطيع Decompilers فصل هذا مرة أخرى إلى كتلتين الصيد. في هذه الحالة ، يرى المرء عادةً أن عبارات GOTO تتناثر فيها عبر الكود (غير صالح Java) أو Decompiler ببساطة تتخلى عن هذه الطريقة.

أيضًا ، أنت محق في أن هذا رمز تم إنشاؤه. على وجه التحديد ، إنه من برنامج التحويل البرمجي XMLBeans ، والذي يوسع مخطط XN XML ويولد فئات ملزمة لـ Java ؛ السماح للمرء بتطوير مستندات XML وتجاهلها وتوافق مع هذا المخطط. إذا كان لديك إمكانية الوصول إلى المخطط ، فسيكون من الأفضل دمج XMLBeans في بنيتك بدلاً من إلغاء تجميع هذه الفئات.

Answer 2

ألق نظرة على السخام. لا يفسد رمز مصدر Java ، ولكنه يستخدم طبقة وسيطة يمكن تجميعها. على الرغم من أن لغة أخرى تتعلمها ، إلا أنك ستحصل على المرونة التي تحتاجها.

بالإضافة إلى ذلك ، إذا كنت تقوم بعمل تعديلات صغيرة فقط ، فيمكنك فقط مهاجمة الملفات بشكل فردي وترك الباقي سليمة.