J'utilise une bibliothèque 3ème partie qui crée essentiellement un répertoire de sortie avec différents types de fichiers et de sous-répertoires à l'intérieur. J'aimerais pouvoir rédiger des tests d'unité pour confirmer que la sortie est correcte.
J'aimerais pouvoir utiliser la lib avec un disque RAM, de sorte que rien ne touche de la part de la bibliothèque ne touche de quelque manière que ce soit. L'idée est de rendre les tests très rapidement à courir et à nettoyer (Drop Ram Disk?).
Les deux options les plus importantes disponibles pour moi sont Commons VFS et JSR 203 . Le premier n'est pas utile pour moi parce que je veux que les choses fonctionnent de manière transparente à l'aide de Java.IO. * API et non les classes de la Common VFS. Le plus tard ne le coupait pas parce que je dois faire avec JDK 6 (c'est censé faire partie de JDK 7) et je ne sais pas si cela fonctionnera de manière transparente avec Java.io. * Quoi qu'il en soit (je ne le ferais pas parier dessus).
Il y a Autres solutions également, mais je ne peux pas les utiliser pour le même raison que je ne peux pas utiliser les Commons VFS. Se moqueurs sont hors de question en raison de la complexité de la bibliothèque en question.
sur ma machine Linux, je peux facilement créer un lecteur de RAM et utiliser l'API Java.IO. * API de la même manière que je serais avec des fichiers sur disque. La chose est que je veux qu'il soit multiplate-forme et plus spécifiquement, pour faire de la configuration de disque une partie de la procédure de test, plutôt que quelque chose d'externe.
Voilà donc un moyen d'enregistrer un lecteur de RAM en Java qui serait utilisable avec la norme Java.IO. * API?
3 Réponses :
Voilà donc un moyen d'enregistrer un lecteur de RAM en Java qui serait utilisable avec la norme Java.IO. * API?
Pas avec une JVM Java 6 ou précédente. Java 6 et plus tôt ne fournissez aucun SPI pour enregistrer des systèmes de fichiers ni des types de système de fichiers. Donc, pour mettre en œuvre une RAM FS qu'une application utiliserait comme une FS normale impliquerait de modifier le comportement d'un certain nombre de
Java.io. * classes.Je pense que la meilleure chose que vous puissiez faire serait d'utiliser un RAM FS implémenté par le système d'exploitation hôte. Vous devriez pouvoir accéder à celui de Java comme s'il s'agissait d'un système de fichiers normal. Cependant, les E / S impliqueraient des appels système, de sorte qu'il ne serait donc pas aussi rapide que si le système de fichiers RAM a été conservé dans la mémoire gérée JVM.
Merci pour une réponse claire et précise. Comme il se trouve, je vais probablement modifier les tests aux tests d'intégration et travailler avec ceux-ci.
Théoriquement Stephen a raison. Mais je peux vous suggérer un tour. Vous pouvez implémenter votre propre fichierInputStream et FileOutPutStream et les mettre en bootclasspath. Votre implémentation implémentera, par exemple, Open (), Lecture () et Readbytes () (qui sont une méthode natale dans FileInputStream ordinaire.)
Ceci est une solution pure Java pour votre problème. Son inconvénient est que vous devez exécuter vos tests dans une instance séparée de JVM.
Ce n'est pas vraiment "pure java" dans la mesure où la modification des classes système n'est pas dans la portée des spécifications Java, c'est-à-dire que cela pourrait travailler sur certaines implémentations Java, mais ne fonctionnera pas sur les autres.
Je crois comprendre qu'il ne peut pas faire cela, même s'il veut. Il dit "[T], il ne le coupa plus tard, car je dois faire avec JDK 6" . S'il remplace java.io. * classes avec des versions personnalisées, ce n'est plus Java 6. (En effet, techniquement ce n'est pas du tout Java!)
En outre, remplacer les classes Java standard n'est définitivement pas une "pure java"; Voir ce lien - Javacoffeakebreak.com/faq/faq0006.html . Selon un JVM piraté, rend automatiquement votre code non portable, et donc pas "pure java", imo.
Merci pour la suggestion, Alex. Mise en œuvre de ces classes pour travailler à l'aide d'un lecteur de RAM et de gérer différentes versions de JVMS semble un peu de travail et a une sensation pirate. Depuis les articles que j'ai lus, mon cas d'utilisation est assez fréquent, alors j'avais espéré quelque chose de plus simple, d'autant plus que je ne peux pas allouer trop de temps à un problème d'optimisation. : \ Cela pourrait très bien être une approche valide pour faire le travail, néanmoins: je vais le laisser pour une personne ayant un horaire lâche pour enquêter.
@Stephen: Modification d'un petit ensemble sélectionné de classes JDK 6 pour pouvoir exécuter des tests unitaires (c'est-à-dire pas à utiliser en production) serait plus acceptable pour moi que d'utiliser par exemple. JDK 7 qui est différent à travers le tableau. Le problème pour moi est qu'il semble que cela semble nécessiter des jours plutôt que des heures de travail, que je ne peux pas me permettre dès maintenant.
Le problème de base que vous cherchez à surmonter est que les API d'origine Les classes s'étendant après leur conception peuvent être une mauvaise conception (il suffit de regarder Les propriétés Rien ne vous empêche d'étendre le EDIT : Toutefois, il y a des choses qui vont probablement échouer sous cette approche - par exemple, à l'aide des constructeurs qui prennent un fichier edit 2 : Eh bien, je commencerais avec quelque chose comme ça: comme pour la raison pour laquelle le fichier Alors, vous êtes - Cela nécessiterait un peu de travail non trivial et il y a une chance significative que la bibliothèque ne fonctionne de toute façon pas être attendue. Java.IO ne sont pas flexibles (ils se réfèrent tous aux classes de béton). La seule façon de mettre une fonctionnalité différente dans, par exemple java.io.file , consiste à étendre la classe de base. classe) - C'est pourquoi vous ne trouverez probablement pas une bibliothèque qui le fait. java.io.file classe vous-même et proxy toutes les méthodes à, par exemple, un fileObject de la commune VFS API. parent . (fichier, chaîne) constructeur ne fonctionnerait pas avec cette configuration: ce constructeur ne s'attend pas à une implémentation du fichier pour casser le contrat de la classe - que nous faisons lorsque nous appelons uniforme équivalent)
Pourriez-vous élaborer un peu comment vous feriez des appels de proxy contre Java.IO.File à par exemple. A FileObject et quel serait le problème du constructeur de fichiers (fichier)?
Merci pour une clarification plutôt approfondie, Jean. Malheureusement, je ne vois pas comment il améliore la situation par rapport à la simple utilisation des Commons VFS. La bibliothèque tierce que j'utilise ne connaisse pas d'une classe virtuelle et serait (bien sûr) pas l'utiliser. S'il était écrit pour utiliser une couche d'abstraction comme celle que vous avez décrite, cela aurait pu me donner quelque chose à travailler avec. Il semble que je vais être bloqué avec des fichiers sur disque, pour le moment.
@Tomislav: Je ne savais pas combien de contrôle vous aviez sur la bibliothèque - ou peut-être que vous pourriez peut-être fournir un fichier de base à la bibliothèque.
Pourquoi aucun look à l'extérieur de Java. Créez un disque RAM au niveau du système d'exploitation (outils existez pour Windows et Linux) et donnez simplement à votre bibliothèque comme chemin.
J'ai déjà expliqué pourquoi: j'ai idéalement voulu que la procédure soit indépendante de la plate-forme. De plus, je préférerais que tout code nécessaire soit en Java, plutôt que d'écrire des scripts externes pour mettre en place et disposer d'un disque RAM dans un environnement ou un autre.
Avez-vous trouvé une solution? Pour Java 7 ou Java 8.
@ JUS12 Désolé, je n'ai pas entendu parler d'une solution dans l'intervalle.