Το Eclipse άλλαξε με τρόπους ασύμβατους μεταξύ της έκδοσης 3.1 και της 3.2 όσον αφορά τους τρόπους που επηρεάζουν τις πρόσθετες λειτουργίες. Οι ακόλουθες καταχωρήσεις περιγράφουν τις περιοχές που άλλαξαν και παρέχουν οδηγίες για τη μετάβαση των πρόσθετων λειτουργιών της εκδοχής 3.1 στην εκδοχή 3.2. Σημειώστε ότι χρειάζεστε μόνο να ανατρέξετε εδώ μόνο εφόσον παρουσιάζονται προβλήματα κατά την εκτέλεση των πρόσθετων λειτουργιών της εκδοχής 3.1 στην εκδοχή 3.2.
Τι επηρεάζεται:Οι πελάτες του API της IWorkspace
που θεωρούν ότι οι πόροι αποθηκεύονται
στο τοπικό σύστημα αρχείων.
Περιγραφή: Πριν το Eclipse 3.2, κάθε υπάρχουσα IResource
διέθετε ένα αντίστοιχο αρχείο ή
κατάλογο σε ένα σύστημα αρχείων στο οποίο υπάρχει πρόσβαση μέσω του java.io.File
. Στο Eclipse 3.2, προστέθηκε
υποστήριξη για τη δημιουργία πόρων των οποίων τα περιεχόμενα αποθηκεύονται σε ένα αυθαίρετο εφεδρικό σύστημα αρχείων. Οι
πόροι που χρησιμοποιούν αυτή την υποστήριξη δεν μπορούν να αναπαριστώνται απευθείας ως java.io.File.
Απαιτούμενη ενέργεια: Η παλαιά μέθοδος IResource.getLocation() επιστρέφει τη διαδρομή του τοπικού συστήματος αρχείων ενός πόρου. Αυτή η μέθοδος επιστρέφει την τιμή "null" για τους πόρους που δεν είναι αποθηκευμένοι στο τοπικό σύστημα σύστημα αρχείων. Τα περισσότερα στοιχεία υποβολής κλήσης της getLocation() λειτουργούσαν με αυτόν τον τρόπο με σκοπό τη λήψη μιας χρήσης του java.io.File, που δεν μπορεί πλέον να χρησιμοποιηθεί για πόρους οι οποίοι δεν είναι αποθηκευμένοι στο τοπικό σύστημα αρχείων.
Η νέα πρόσθετη λειτουργία org.eclipse.core.filesystem παρέχει ένα γενικό API συστήματος αρχείου το οποίο μπορεί να χρησιμοποιηθεί αντί του java.io.File. Ειδικότερα, μια χρήση της org.eclipse.core.filesystem.IFileStore παρέχει τις περισσότερες από τις ίδιες μεθόδους που διατίθενται στο java.io.File. Το ακόλουθο τμήμα κώδικα λαμβάνει μια χρήση της IFileStore για κάποιο δεδομένο πόρο:
IResource resource = ...;//some resource IFileStore store = EFS.getStore(resource.getLocationURI());
Ο πίνακας που ακολουθεί παρέχει αντίστοιχες μεθόδους στη IFileStore για λειτουργίες που συνήθως πραγματοποιούνται με το java.io.File:
java.io.File | IFileStore |
---|---|
delete | delete |
getName | getName |
getParent | getParent |
list | childNames |
mkdir | mkdir(EFS.SHALLOW, null) |
mkdirs | mkdir(EFS.NONE, null) |
renameTo | move |
new FileInputStream(file) | openInputStream |
new FileOutputStream(file) | openOutputStream |
Στο API της IFileStore, οι περισσότερες πληροφορίες σχετικά με ένα αρχείο αποθηκεύονται σε μια δομή που ονομάζεται IFileInfo και λαμβάνεται από την κλήση της IFileStore.fetchInfo(). Αυτό το σχέδιο επιτρέπει μεγαλύτερη βελτιστοποίηση του κώδικα με τη χρήση του java.io.File επειδή πολλά γνωρίσματα σχετικά με ένα αρχείο μπορούν συχνά να ληφθούν με μια μοναδική κλήση συστήματος αρχείων. Σημειώστε ότι οι πληροφορίες στην IFileInfo συχνά γίνονται ανενεργές αν αλλάξει το υποκείμενο αρχείο, συνεπώς οι χρήσεις πρέπει να διατηρούνται μόνο για όσο χρονικό διάστημα απαιτούνται. Παρατίθενται ορισμένες μέθοδοι στο java.io.File που διαθέτουν αντίστοιχες μεθόδους στην IFileInfo:
java.io.File | IFileInfo |
---|---|
canWrite | isReadOnly |
exists | exists |
getName | getName |
isDirectory | isDirectory |
isFile | !isDirectory() |
isHidden | isHidden |
lastModified | getLastModified |
length | getLength |
setLastModified | setLastModified |
setReadOnly | setAttribute(EFS.ATTRIBUTE_READ_ONLY, true) |
Ένα απτό παράδειγμα είναι ότι ο κώδικας που παλαιότερα καλούσε την java.io.File.exists() μπορεί πλέον να καλεί την IFileStore.fetchInfo().exists(). Όταν τροποποιηθεί μια IFileInfo, το αποτέλεσμα πρέπει να αποθηκευτεί με τη χρήση της μεθόδου IFileStore.putInfo. Για παράδειγμα, αυτό το τμήμα κώδικα αντιστρέφει το γνώρισμα μόνο για ανάγνωση ενός αρχείου
IFileStore store = ...;//some file store IFileInfo info = store.fetchInfo(); boolean readOnly = info.getAttribute(EFS.ATTRIBUTE_READ_ONLY); info.setAttribute(EFS.ATTRIBUTE_READ_ONLY, !readOnly); store.putInfo(info, EFS.SET_ATTRIBUTES, null);
Όπως συμβαίνει και με τη μέθοδο getLocation(), η θέση της περιγραφής του έργου δεν μπορεί πλέον να βρίσκεται στο τοπικό σύστημα αρχείων. Η μέθοδος IProjectDescription.getLocationURI() μπορεί να χρησιμοποιηθεί για τη λήψη της θέσης ενός πόρου σε ένα αυθαίρετο σύστημα αρχείων.
Ορισμένοι πελάτες πρέπει οπωσδήποτε να διαθέτουν μια τοπική αναπαράσταση ενός αρχείου. Για παράδειγμα, μπορεί να πραγματοποιούν εκκίνηση ενός ενσωματωμένου εργαλείου σε αυτό το αρχείο ή να χρησιμοποιούν βιβλιοθήκες που δεν λαμβάνουν υπόψη τους το Eclipse οι οποίες μπορούν να χειριστούν μόνο πόρους του συστήματος αρχείων (όπως το java.util.zip.ZipFile). Σε αυτές τις περιπτώσεις, μπορείτε να ζητήσετε από μια μέθοδο IFileStore μα επιστρέψει ένα τοπικό αντίγραφο των περιεχομένων της αποθηκευμένο στην λανθάνουσα μνήμη:
IFileStore store = ...;//some file store //see if it can directly be represented as a local file java.io.File local = store.toLocalFile(EFS.NONE, null); //if not, ask for a cached local copy of the file if (local == null) local = store.toLocalFile(EFS.CACHE, null);
Σημειώστε ότι μόλις ληφθεί ένα αντίγραφο αρχείου αποθηκευμένο στη λανθάνουσα μνήμη, δεν παραμένει σε συγχρονισμό με το πραγματικό σύστημα αρχείων από το οποίο προήλθε. Η τροποποίηση του αντιγράφου που είναι αποθηκευμένο στη λανθάνουσα μνήμη δεν προκαλεί την τροποποίηση του υποκείμενου αρχείου.
Οι πελάτες που δεν μπορούν να χειριστούν πόρους εκτός του τοπικού συστήματος αρχείων μπορεί να επιθυμούν την προσαρμογή του κώδικά τους έτσι ώστε να αποτυγχάνει ομαλά. Οι πελάτες μπορούν να ελέγχουν εάν ένας πόρος βρίσκεται στο τοπικό σύστημα αρχείων και είτε να αγνοούν τον πόρο είτε να ειδοποιούν το χρήστη όταν συναντήσουν έναν πόρο που δεν μπορούν να χειριστούν. Για να καθοριστεί εάν ένας πόρος βρίσκεται στο τοπικό σύστημα αρχείων, πρέπει να βρείτε το σχήμα του συστήματος αρχείων του. Αυτό μπορεί να ληφθεί από τον πόρο ως εξής:
IResource resource = ...;//some resource URI uri = resource.getLocationURI(); if (uri != null && EFS.SCHEME_LOCAL.equals(uri.getScheme())) { //file is in local file system } else { //file is not in the local file system }
Αν διαθέτετε μια χρήση της IFileStore, μπορείτε να λάβετε το σχήμα ως εξής:
IFileStore store = ...;//a file store store.getFileSystem().getScheme();
Τι επηρεάζεται: Οι πελάτες οι οποίοι καλούν τη μέθοδο MultiPageEditorSite.progressStart()
ή τη μέθοδο MultiPageEditorSite.progressEnd()
.
Περιγραφή: Κατά τη διάρκεια της ανάπτυξης του Eclipse 3.0, αυτές οι μέθοδοι προστέθηκαν ως τμήμα του έργου υποστήριξης προόδου. Πριν την έκδοση 3.0, ο τρόπος με τον οποίον γινόταν ο χειρισμός της προόδου άλλαξε και αυτή η μέθοδος δεν ήταν πλέον απαραίτητη. Λόγω σφάλματος προγραμματιστή, αυτές οι δημόσιες μέθοδοι διατηρήθηκαν στην εκδοχή 3.0. Αυτές οι δύο μέθοδοι δεν εξυπηρετούσαν ποτέ καμία λειτουργία σε μια εκδοχή του Eclipse και συνεπώς διαγράφηκαν.
Απαιτούμενη ενέργεια: Οι πελάτες που καλούν την
MultiPageEditorSite.progressStart()
ή την
MultiPageEditorSite.progressEnd()
πρέπει αντί αυτών να χρησιμοποιούν την
IWorkbenchSiteProgressService
.
Τι επηρεάζεται: Οι πελάτες οι οποίοι διαθέτουν ένα προσαρμοσμένο αρχείο config.ini και μεταβιβάζουν την εφαρμογή τους στο 3.2.
Περιγραφή: Πριν την εκδοχή 3.2, η τυπική τιμή του osgi.bundles που περιέχεται στο config.ini ήταν
org.eclipse.core.runtime@2:start, org.eclipse.update.configurator@3:start
.
Λόγω της βελτιστοποίησης δομής του περιβάλλοντος εκτέλεσης, αυτή η τιμή πρέπει
να ενημερωθεί για την επιτυχή εκκίνηση της εφαρμογής.
Απαιτούμενη ενέργεια: Αλλάξτε την τιμή του osgi.bundles έτσι ώστε να περιλαμβάνει τα
org.eclipse.equinox.common@2:start, org.eclipse.update.configurator@3:start, org.eclipse.core.runtime@start.
Τι επηρεάζεται: Οι πελάτες που διανέμουν εφαρμογές RCP και καθορίζουν μια τιμή για το osgi.bundles.
Περιγραφή: Πριν την εκδοχή 3.2, η τυπική τιμή του osgi.bundles που περιέχεται στο κύριο αρχείο jnlp
ήταν org.eclipse.core.runtime@2:start, org.eclipse.update.configurator@3:start
.
Λόγω της βελτιστοποίησης δομής του περιβάλλοντος εκτέλεσης, αυτή η τιμή πρέπει
να ενημερωθεί, διαφορετικά ενδέχεται να προκύψουν εξαιρέσεις NullPointerException
οι οποίες θα αποτρέπουν την
εκκίνηση της εφαρμογής.
Απαιτούμενη ενέργεια: Αλλάξτε την τιμή του osgi.bundles έτσι ώστε να περιλαμβάνει τα
org.eclipse.equinox.common@2:start, org.eclipse.update.configurator@3:start, org.eclipse.core.runtime@start.
WΤι επηρεάζεται: Οι πελάτες οι οποίοι καλούν την Bundle.start()
.
Περιγραφή:
Στο Eclipse μια δέσμη καθορίζεται ως δέσμη αργής έναρξης
χρησιμοποιώντας την κεφαλίδα Eclipse-LazyStart
(ή την καταργημένη
κεφαλίδα Eclipse-AutoStart
). Στο Eclipse 3.1, η μέθοδος
org.osgi.framework.Bundle.start()
δεν επεσήμανε τις δέσμες αργής έναρξης ότι εκκινούν μόνιμα. Εφόσον οι
δέσμες αργής έναρξης δεν έφεραν επισήμανση ότι πρέπει να εκκινούν μόνιμα, δεν γινόταν αυτόματη εκκίνησή τους κατά την
επανεκκίνηση του Eclipse. Το javadoc της Bundle.start()
δηλώνει ότι πρέπει να λάβουν χώρα τα ακόλουθα
κατά την κλήση της μεθόδου:
"Μόνιμη καταγραφή της εκκίνησης της δέσμης. Κατά την επανεκκίνηση του πλαισίου, πρέπει να γίνει αυτόματα εκκίνηση αυτής της δέσμης."
Στο Eclipse 3.2 η μέθοδος Bundle.start()
έχει διορθωθεί έτσι ώστε να επισημαίνει σωστά τη δέσμη ως δέσμη
μόνιμης έναρξης, ακόμα και αν η δέσμη είναι μια δέσμη αργής έναρξης. Αυτή η επιδιόρθωση ήταν απαιτούμενη για συμμόρφωση με
την προδιαγραφή OSGi Framework. Κατά συνέπεια, τα στοιχεία υποβολής κλήσης της Bundle.start()
αναγκάζουν την
εκκίνηση της δέσμης κατά την επανεκκίνηση του Eclipse.
Γενικά, αυτό θεωρείται κακή πρακτική επειδή θα έχει ως συνέπεια την ενεργοποίηση περιττών δεσμών κάθε φορά που γίνεται
εκκίνηση του Eclipse. Σε ορισμένες περιπτώσεις, μπορεί να προκαλέσει μη αναμενόμενα αποτελέσματα όπως
το σφάλμα 134412.
Απαιτούμενη ενέργεια: Οι πελάτες της Bundle.start()
χρειάζεται να εκτιμήσουν εάν η
πρόθεσή τους είναι η μόνιμη ενεργοποίηση της δέσμης σε κάθε επανεκκίνηση. Αν δεν είναι αυτή η πρόθεσή τους, τότε οι
πελάτες πρέπει να αναζητήσουν άλλο τρόπο για την ενεργοποίηση της δέσμης. Στις περισσότερες περιπτώσεις, οι κλήσεις της
Bundle.start()
μπορούν να αποφευχθούν επιτρέποντας απλά την αργή ενεργοποίηση της δέσμης στόχος όταν γίνεται
φόρτωση κλάσεων από αυτές. Αυτά αποτελούν σπάνια σενάρια τα οποία απαιτούν τη δυναμική ενεργοποίηση μιας δέσμης αργής
έναρξης αλλά όχι την επισήμανση μόνιμης ενεργοποίησης σε επανεκκίνηση. Αυτά τα είδη σεναρίων πρέπει να χρησιμοποιούν την
Bundle.loadClass()
για τη φόρτωση κλάσης από τη δέσμη που πρέπει να ενεργοποιηθεί αντί μιας κλήσης της
Bundle.start()
.
Στο Eclipse 3.0, η χρήση του χαρακτήρα υπογραμμής ('_') στο τμήμα προσδιοριστικού μιας ταυτότητας εκδοχής δεν
υποστηριζόταν αλλά επίσης δεν επιβαλλόταν. Αν κάποια ταυτότητα εκδοχής πρόσθετης λειτουργίας περιείχε ένα χαρακτήρα
υπογραμμής στο προσδιοριστικό, τότε αυτός ο χαρακτήρας μετατρεπόταν σε παύλα ('-') κατά την εξαγωγή της πρόσθετης
λειτουργίας στο σύστημα αρχείων και επίσης κατά την εγκατάσταση της πρόσθετης λειτουργίας από ένα δικτυακό τόπο ενημέρωσης.
Στο Eclipse 3.1 οι κανόνες των χαρακτήρων επέτρεπαν στα προσδιοριστικά να είναι περισσότερο ευέλικτα έτσι ώστε να
περιλαμβάνουν το χαρακτήρα υπογραμμής, συνεπώς κατά την εξαγωγή ή την εγκατάσταση μιας πρόσθετης λειτουργίας που προκαλεί
προβλήματα, δεν γινόταν τροποποίηση του προσδιοριστικού από την αρχική του κατάσταση.
Αυτή η μικρή αλλαγή παραλήφθηκε κατά λάθος από τον οδηγό μετάβασης από την εκδοχή 3.0 στην εκδοχή 3.1.
Στη συνέχεια (και όσον αφορά το Eclipse 3.2) διατηρείται η συμβατότητα με το Eclipse 3.1 και οι πρόσθετες λειτουργίες που
χρησιμοποιούν χαρακτήρες υπογραμμής στα προσδιοριστικά εκδοχής τους πρέπει να λάβουν υπόψη τους τις παραπάνω αλλαγές όταν
χειρίζονται παλαιές εκδοχές πρόσθετων λειτουργιών (τόσο κατά την εξαγωγή όσο και όταν βρίσκονται σε δικτυακούς τόπους
ενημέρωσης). Αυτό σημαίνει, για παράδειγμα, ότι οι παροχείς πρόσθετων λειτουργιών που διαθέτουν παλαιές εκδοχές της
πρόσθετης λειτουργίας τους σε ένα δικτυακό τόπο ενημέρωσης πρέπει να διασφαλίζουν ότι το όνομα στο σύστημα αρχείων συμφωνεί
με το όνομα της πρόσθετης λειτουργίας.