Sun a finalement annoncé le passage prochain de son langage Java, en
Open Source.
L'hésitation porte à l'heure actuelle sur le type exact de licence, Sun
voulant garder la main sur le langage.
Quoiqu'il en soit le code de Java sera ouvert.
Cela va t-il sonner le glas pour les techno .NET ?
Le Sun, 21 May 2006 21:26:05 +0200, Prodejeu a écrit :
Ouais c'est marrant, parce que moi c'est exactement l'inverse. Je trouve la syntaxe de Java beaucoup moins verbeuse, que celle des langages qui forcent à séparer les entêtes des corps (de classes, méthodes, fonctions, ...). ;-)
C'est sûrr que c'est moins verbeux que l'assembleur, aussi, si on va par là. Mais c'est très verbeux comparé aux autres langages de haut-niveau.
Prend l'exemple suivant: http://penguin.ewu.edu/class/cscd326/KoffmanWolfgang/CH11/RedBlackTree.java Est-ce que tu crois que c'est rééllement tellement plus verbeux que dans un autre langage? Je crois que ça a l'air plus verbeux pour un Hello World! mais ça devient à peu prés pareil que le reste dés que le programme est un tout petit peu plus conséquent. Evidemment ça ne sera jamais aussi concis que du Perl.
--
Michel TALON
Emmanuel Florac <eflorac@imaginet.fr> wrote:
Le Sun, 21 May 2006 21:26:05 +0200, Prodejeu a écrit :
Ouais c'est marrant, parce que moi c'est exactement l'inverse. Je trouve
la syntaxe de Java beaucoup moins verbeuse, que celle des langages qui
forcent à séparer les entêtes des corps (de classes, méthodes,
fonctions, ...). ;-)
C'est sûrr que c'est moins verbeux que l'assembleur, aussi, si on va par
là. Mais c'est très verbeux comparé aux autres langages de haut-niveau.
Prend l'exemple suivant:
http://penguin.ewu.edu/class/cscd326/KoffmanWolfgang/CH11/RedBlackTree.java
Est-ce que tu crois que c'est rééllement tellement plus verbeux que dans un
autre langage? Je crois que ça a l'air plus verbeux pour un Hello World!
mais ça devient à peu prés pareil que le reste dés que le programme est un
tout petit peu plus conséquent. Evidemment ça ne sera jamais aussi concis
que du Perl.
Le Sun, 21 May 2006 21:26:05 +0200, Prodejeu a écrit :
Ouais c'est marrant, parce que moi c'est exactement l'inverse. Je trouve la syntaxe de Java beaucoup moins verbeuse, que celle des langages qui forcent à séparer les entêtes des corps (de classes, méthodes, fonctions, ...). ;-)
C'est sûrr que c'est moins verbeux que l'assembleur, aussi, si on va par là. Mais c'est très verbeux comparé aux autres langages de haut-niveau.
Prend l'exemple suivant: http://penguin.ewu.edu/class/cscd326/KoffmanWolfgang/CH11/RedBlackTree.java Est-ce que tu crois que c'est rééllement tellement plus verbeux que dans un autre langage? Je crois que ça a l'air plus verbeux pour un Hello World! mais ça devient à peu prés pareil que le reste dés que le programme est un tout petit peu plus conséquent. Evidemment ça ne sera jamais aussi concis que du Perl.
--
Michel TALON
Remi THOMAS
Remi THOMAS wrote:
J'ai également précisé que je ne sais pas comment cela fonctionne dans la JVM que je ne connais pas assez bien. Si quelqu'un peut préciser.
Java fourni plusieurs couche de sécurité, la première étant la vérification à la compilation (impossibilité d'utiliser des variables non initalisée,...), la seconde étant la vérification à l'exécution (vérification des classes au chargement...), la troisième étant l'API de sécurité qui permet de définir ce qu'un programme java est autorisé à faire.
Exemple d'utilisation de l'API de sécurité :
public class SystemPropertyReader {
public static void main(String[] pArgs) {
try { System.out.println("système d'exploitation ["+System.getProperty("os.name","inconnu")+"]"); System.out.println("n° répertoire home en ["+System.getProperty("user.home","inconnu")+"]"); } catch(Exception e) { System.out.println("ERROR => "+e.toString()); } } }
Par défaut, les applications java ne dispose d'aucun gestionnaire de sécurité, c'est pourquoi l'exécution tel quel du code ci-dessus se terminera normalement.
A contrario, si l'on rattache un SécurityManager à ce même programme en l'exécutant via un "java -Djava.security.manager SystemPropertyReader" , une SecurityException sera levée lors de la tentative de lecture de la propriété "user.home", l'accès à celle-ci n'étant pas autorisé dans le fichier de police (java.policy) par défaut.
Voilà, j'espère avoir plus où moins répondu à ta question.
Oui merci, Je pense que tu peux ajouter la sécurité lors de l'exécution, par exemple une exception est levée si tu veux aller au delà de la taille d'un tableau.
La différence remarquable c'est l'équivalent du SecurityManager qui est actif par défaut dans .NET. C'est pour cela qu'il n'a pas de nom.
Rémi
Remi THOMAS wrote:
J'ai également précisé que je ne sais pas comment cela fonctionne dans la
JVM que je ne connais pas assez bien. Si quelqu'un peut préciser.
Java fourni plusieurs couche de sécurité, la première étant la
vérification à
la compilation (impossibilité d'utiliser des variables non
initalisée,...), la seconde
étant la vérification à l'exécution (vérification des classes au
chargement...), la troisième
étant l'API de sécurité qui permet de définir ce qu'un programme
java est autorisé à faire.
Exemple d'utilisation de l'API de sécurité :
public class SystemPropertyReader {
public static void main(String[] pArgs) {
try {
System.out.println("système d'exploitation
["+System.getProperty("os.name","inconnu")+"]");
System.out.println("n° répertoire home en
["+System.getProperty("user.home","inconnu")+"]");
} catch(Exception e) {
System.out.println("ERROR => "+e.toString());
}
}
}
Par défaut, les applications java ne dispose d'aucun gestionnaire de
sécurité, c'est
pourquoi l'exécution tel quel du code ci-dessus se terminera
normalement.
A contrario, si l'on rattache un SécurityManager à ce même programme
en l'exécutant via
un "java -Djava.security.manager SystemPropertyReader" , une
SecurityException sera
levée lors de la tentative de lecture de la propriété "user.home",
l'accès à celle-ci n'étant
pas autorisé dans le fichier de police (java.policy) par défaut.
Voilà, j'espère avoir plus où moins répondu à ta question.
Oui merci,
Je pense que tu peux ajouter la sécurité lors de l'exécution, par
exemple une exception est levée si tu veux aller au delà de la taille
d'un tableau.
La différence remarquable c'est l'équivalent du SecurityManager qui est
actif par défaut dans .NET. C'est pour cela qu'il n'a pas de nom.
J'ai également précisé que je ne sais pas comment cela fonctionne dans la JVM que je ne connais pas assez bien. Si quelqu'un peut préciser.
Java fourni plusieurs couche de sécurité, la première étant la vérification à la compilation (impossibilité d'utiliser des variables non initalisée,...), la seconde étant la vérification à l'exécution (vérification des classes au chargement...), la troisième étant l'API de sécurité qui permet de définir ce qu'un programme java est autorisé à faire.
Exemple d'utilisation de l'API de sécurité :
public class SystemPropertyReader {
public static void main(String[] pArgs) {
try { System.out.println("système d'exploitation ["+System.getProperty("os.name","inconnu")+"]"); System.out.println("n° répertoire home en ["+System.getProperty("user.home","inconnu")+"]"); } catch(Exception e) { System.out.println("ERROR => "+e.toString()); } } }
Par défaut, les applications java ne dispose d'aucun gestionnaire de sécurité, c'est pourquoi l'exécution tel quel du code ci-dessus se terminera normalement.
A contrario, si l'on rattache un SécurityManager à ce même programme en l'exécutant via un "java -Djava.security.manager SystemPropertyReader" , une SecurityException sera levée lors de la tentative de lecture de la propriété "user.home", l'accès à celle-ci n'étant pas autorisé dans le fichier de police (java.policy) par défaut.
Voilà, j'espère avoir plus où moins répondu à ta question.
Oui merci, Je pense que tu peux ajouter la sécurité lors de l'exécution, par exemple une exception est levée si tu veux aller au delà de la taille d'un tableau.
La différence remarquable c'est l'équivalent du SecurityManager qui est actif par défaut dans .NET. C'est pour cela qu'il n'a pas de nom.
Rémi
Prodejeu
Ouais c'est marrant, parce que moi c'est exactement l'inverse. Je trouve la syntaxe de Java beaucoup moins verbeuse, que celle des langages qui forcent à séparer les entêtes des corps (de classes, méthodes, fonctions, ...). ;-)
C'est sûrr que c'est moins verbeux que l'assembleur, aussi, si on va par là. Mais c'est très verbeux comparé aux autres langages de haut-niveau.
En comparaison avec du Delphi, où comme en C/C++ chaque fonction/méthode
doit posséder une entête déclarée séparément du corps, et où la déclaration d'un objet doit se faire indépendamment de son instanciation, je trouve qu'il est possible de faire des programmes plus court en Java. Mais évidement comme le dit M.Talon, pour un Hello, World c'est pas le mieux, puisque Java essaye d'être le plus objet possible.
C'est sûr qu'en Python un Hello, World c'est plus court : print "Hello, World"
Ouais c'est marrant, parce que moi c'est exactement l'inverse. Je trouve
la syntaxe de Java beaucoup moins verbeuse, que celle des langages qui
forcent à séparer les entêtes des corps (de classes, méthodes,
fonctions, ...). ;-)
C'est sûrr que c'est moins verbeux que l'assembleur, aussi, si on va par
là. Mais c'est très verbeux comparé aux autres langages de haut-niveau.
En comparaison avec du Delphi, où comme en C/C++ chaque fonction/méthode
doit posséder une entête déclarée séparément du corps, et où la
déclaration d'un objet doit se faire indépendamment de son
instanciation, je trouve qu'il est possible de faire des programmes plus
court en Java.
Mais évidement comme le dit M.Talon, pour un Hello, World c'est pas le
mieux, puisque Java essaye d'être le plus objet possible.
C'est sûr qu'en Python un Hello, World c'est plus court :
print "Hello, World"
Ouais c'est marrant, parce que moi c'est exactement l'inverse. Je trouve la syntaxe de Java beaucoup moins verbeuse, que celle des langages qui forcent à séparer les entêtes des corps (de classes, méthodes, fonctions, ...). ;-)
C'est sûrr que c'est moins verbeux que l'assembleur, aussi, si on va par là. Mais c'est très verbeux comparé aux autres langages de haut-niveau.
En comparaison avec du Delphi, où comme en C/C++ chaque fonction/méthode
doit posséder une entête déclarée séparément du corps, et où la déclaration d'un objet doit se faire indépendamment de son instanciation, je trouve qu'il est possible de faire des programmes plus court en Java. Mais évidement comme le dit M.Talon, pour un Hello, World c'est pas le mieux, puisque Java essaye d'être le plus objet possible.
C'est sûr qu'en Python un Hello, World c'est plus court : print "Hello, World"
seb666fr2
Emmanuel Florac wrote:
C'est sûrr que c'est moins verbeux que l'assembleur, aussi, si on va par là. Mais c'est très verbeux comparé aux autres langages de haut-niv eau.
Avant de considérer un langage en fonction de sa (non) verbosité, tu devrais peut être prendre en considération les API standards qu'il fournit parce que à ce niveau là, que ce soit Java ou .NET, il n' y a pas photo, leurs API sont d'une richesse sans commune mesure.
Emmanuel Florac wrote:
C'est sûrr que c'est moins verbeux que l'assembleur, aussi, si on va par
là. Mais c'est très verbeux comparé aux autres langages de haut-niv eau.
Avant de considérer un langage en fonction de sa (non) verbosité, tu
devrais
peut être prendre en considération les API standards qu'il fournit
parce que à
ce niveau là, que ce soit Java ou .NET, il n' y a pas photo, leurs API
sont d'une
richesse sans commune mesure.
C'est sûrr que c'est moins verbeux que l'assembleur, aussi, si on va par là. Mais c'est très verbeux comparé aux autres langages de haut-niv eau.
Avant de considérer un langage en fonction de sa (non) verbosité, tu devrais peut être prendre en considération les API standards qu'il fournit parce que à ce niveau là, que ce soit Java ou .NET, il n' y a pas photo, leurs API sont d'une richesse sans commune mesure.
Emmanuel Florac
Le Mon, 22 May 2006 00:23:36 -0700, seb666fr2 a écrit :
que ce soit Java ou .NET, il n' y a pas photo, leurs API sont d'une richesse sans commune mesure.
Sans commune mesure avec quoi ? Les API dispo en C/C++? ou CPAN?
-- Ce qu'il y a d'enivrant dans le mauvais goût c'est le plaisir aristocratique de déplaire. C. Baudelaire.
Le Mon, 22 May 2006 00:23:36 -0700, seb666fr2 a écrit :
que ce soit Java ou .NET, il n' y a pas photo, leurs API
sont d'une
richesse sans commune mesure.
Sans commune mesure avec quoi ? Les API dispo en C/C++? ou CPAN?
--
Ce qu'il y a d'enivrant dans le mauvais goût c'est le plaisir
aristocratique de déplaire.
C. Baudelaire.
que ce soit Java ou .NET, il n' y a pas photo, leurs API sont d'une richesse sans commune mesure.
Sans commune mesure avec quoi ? Les API dispo en C/C++? ou CPAN?
Je parle des *APIs standard* de n'importe quel langage.
Stéphane Zuckerman
On Mon, 22 May 2006, wrote:
Emmanuel Florac wrote:
que ce soit Java ou .NET, il n' y a pas photo, leurs API sont d'une richesse sans commune mesure.
Sans commune mesure avec quoi ? Les API dispo en C/C++? ou CPAN?
Je parle des *APIs standard* de n'importe quel langage.
Perl vient fourni avec une pléthore de modules préinstallés. Au moins autant qu'en Java (si si). Et en plus, pour installer de nouveaux modules, j'ai rarement vu aussi simple que CPAN.
-- "Je deteste les ordinateurs : ils font toujours ce que je dis, jamais ce que je veux !" "The obvious mathematical breakthrough would be development of an easy way to factor large prime numbers." (Bill Gates, The Road Ahead)
On Mon, 22 May 2006, seb666fr2@yahoo.fr wrote:
Emmanuel Florac wrote:
que ce soit Java ou .NET, il n' y a pas photo, leurs API
sont d'une
richesse sans commune mesure.
Sans commune mesure avec quoi ? Les API dispo en C/C++? ou CPAN?
Je parle des *APIs standard* de n'importe quel langage.
Perl vient fourni avec une pléthore de modules préinstallés. Au moins
autant qu'en Java (si si). Et en plus, pour installer de nouveaux modules,
j'ai rarement vu aussi simple que CPAN.
--
"Je deteste les ordinateurs : ils font toujours ce que je dis, jamais ce
que je veux !"
"The obvious mathematical breakthrough would be development of an easy
way to factor large prime numbers." (Bill Gates, The Road Ahead)
que ce soit Java ou .NET, il n' y a pas photo, leurs API sont d'une richesse sans commune mesure.
Sans commune mesure avec quoi ? Les API dispo en C/C++? ou CPAN?
Je parle des *APIs standard* de n'importe quel langage.
Perl vient fourni avec une pléthore de modules préinstallés. Au moins autant qu'en Java (si si). Et en plus, pour installer de nouveaux modules, j'ai rarement vu aussi simple que CPAN.
-- "Je deteste les ordinateurs : ils font toujours ce que je dis, jamais ce que je veux !" "The obvious mathematical breakthrough would be development of an easy way to factor large prime numbers." (Bill Gates, The Road Ahead)
talon
wrote:
Emmanuel Florac wrote:
C'est sûrr que c'est moins verbeux que l'assembleur, aussi, si on va par là. Mais c'est très verbeux comparé aux autres langages de haut-niveau.
Avant de considérer un langage en fonction de sa (non) verbosité, tu devrais peut être prendre en considération les API standards qu'il fournit parce que à ce niveau là, que ce soit Java ou .NET, il n' y a pas photo, leurs API sont d'une richesse sans commune mesure.
Emmanuel aime bien perl, et la richesse des bibliothèques de perl est trés grande aussi. Je me garderais bien de dire laquelle est la plus complète.
seb666fr2@yahoo.fr wrote:
Emmanuel Florac wrote:
C'est sûrr que c'est moins verbeux que l'assembleur, aussi, si on va par
là. Mais c'est très verbeux comparé aux autres langages de haut-niveau.
Avant de considérer un langage en fonction de sa (non) verbosité, tu
devrais
peut être prendre en considération les API standards qu'il fournit
parce que à
ce niveau là, que ce soit Java ou .NET, il n' y a pas photo, leurs API
sont d'une
richesse sans commune mesure.
Emmanuel aime bien perl, et la richesse des bibliothèques de perl est trés
grande aussi. Je me garderais bien de dire laquelle est la plus complète.
C'est sûrr que c'est moins verbeux que l'assembleur, aussi, si on va par là. Mais c'est très verbeux comparé aux autres langages de haut-niveau.
Avant de considérer un langage en fonction de sa (non) verbosité, tu devrais peut être prendre en considération les API standards qu'il fournit parce que à ce niveau là, que ce soit Java ou .NET, il n' y a pas photo, leurs API sont d'une richesse sans commune mesure.
Emmanuel aime bien perl, et la richesse des bibliothèques de perl est trés grande aussi. Je me garderais bien de dire laquelle est la plus complète.
talon
wrote:
Emmanuel Florac wrote:
que ce soit Java ou .NET, il n' y a pas photo, leurs API sont d'une richesse sans commune mesure.
Sans commune mesure avec quoi ? Les API dispo en C/C++? ou CPAN?
Je parle des *APIs standard* de n'importe quel langage.
Ce qui ne veut absolument rien dire. Il suffit de dire que tout CPAN est standard dans perl.
seb666fr2@yahoo.fr wrote:
Emmanuel Florac wrote:
que ce soit Java ou .NET, il n' y a pas photo, leurs API
sont d'une
richesse sans commune mesure.
Sans commune mesure avec quoi ? Les API dispo en C/C++? ou CPAN?
Je parle des *APIs standard* de n'importe quel langage.
Ce qui ne veut absolument rien dire. Il suffit de dire que tout CPAN est
standard dans perl.
