Le meilleur moyen de vraiment Java-ME pour un gars en C # [fermé]

Question

J'ai récemment commencé à développer des applications pour le Blackberry. En conséquence, j'ai dû passer à Java-ME et apprendre cela ainsi que ses outils associés. La syntaxe est facile, mais je continue à avoir des problèmes avec divers pièges et de l'environnement.

Par exemple, quelque chose qui me surprend et me fait perdre beaucoup de temps est l’absence de propriétés réelles sur un objet de classe (quelque chose que j’imaginais dans tous les langages POO). Il y a beaucoup de pièges. Je suis allé à divers endroits où la syntaxe Java est comparée à la syntaxe C #, mais il ne semble pas exister de site Web proposant des éléments à surveiller lors du passage à Java.

L’environnement est un tout autre problème. L'IDE Blackberry est simplement horrible. Le look me rappelle Borland C ++ pour Windows 3.1 - il est obsolète. Parmi les autres problèmes, mentionnons l'intellisense irrégulière, le débogage faible, etc. Blackberry dispose d'une version bêta du plug-in Eclipse, mais sans l'aide du débogage, il ne s'agit que d'un éditeur doté d'outils de refactoring sophistiqués.

Alors, un conseil pour intégrer Java-ME?

Answer 1

Ce gars ici devait faire l'inverse. transition. Il a donc répertorié les 10 principales différences entre Java et C #. Je vais prendre ses sujets et montrer comment il est fait en Java:

Gotcha # 10 - Donnez-moi ma sortie standard!

Pour imprimer sur la sortie standard en Java:

System.out.println("Hello");

Gotcha # 9 - Espaces de nommage == Liberté

En Java, vous n’avez pas la liberté d’espaces de noms. La structure de dossiers de votre classe doit correspondre au nom du package. Par exemple, une classe du package org.test doit figurer dans le dossier org / test

.

Gotcha # 8 - Qu'est-il arrivé à super?

En Java, pour faire référence à la superclasse, utilisez le mot réservé super au lieu de base

Gotcha # 7 - Chaînage de constructeurs vers un constructeur de base

Vous n'avez pas cela en Java. Vous devez appeler le constructeur vous-même

Gotcha # 6 - Dagnabit, comment sous-classer une classe existante?

Pour sous-classer une classe en Java, procédez comme suit:

public class A extends B {
}

Cela signifie que la classe A est une sous-classe de la classe B . En C # serait classe A: B

Gotcha # 5 - Pourquoi les constantes ne restent-elles pas constantes?

Pour définir une constante en Java, utilisez le mot-clé final au lieu de const

.

Gotcha # 4 - Où se trouve ArrayList , Vecteur ou Hashtable ?

Les structures de données les plus utilisées en Java sont HashSet , ArrayList et HashMap . Ils implémentent Set , List et Map . Bien sûr, il y en a beaucoup plus. En savoir plus sur les collections ici

Gotcha # 3 - Des accesseurs et des mutateurs (Getters et Setters)

Vous n'avez pas la propriété properties en Java. Vous devez déclarer les objets obtenus et définis les méthodes vous-même. Bien sûr, la plupart des IDE peuvent le faire automatiquement.

Gotcha # 2 - Je ne peux pas remplacer??

Il n'est pas nécessaire de déclarer une méthode virtual en Java. Toutes les méthodes, à l'exception de celles déclarées final - peuvent être remplacées en Java.

Et le n ° 1 s'est fait avoir…

En Java, les types primitifs int , float , double , char et long ne sont pas Object comme dans C #. Tous ont une représentation d'objet respective, telle que Integer , Float , Double , etc.

C'est ça. N'oubliez pas de voir le lien d'origine , il y a une discussion plus détaillée.

Answer 2

Java n'est pas très différent de C #. À un niveau purement syntaxique, voici quelques conseils qui vous aideront à passer la journée:

1. En Java, vous avez deux familles d'exceptions: java.lang.Exception et tout ce qui en découle, et RuntimeException . Cela est significatif car, en Java, les exceptions sont vérifiées ; Cela signifie que pour lever toute exception non liée à l'exécution, vous devez également ajouter une annotation renvoie à la déclaration de votre méthode. Par conséquent, toute méthode utilisant la vôtre devra intercepter cette exception ou déclarer que elle lève également la même exception. De nombreuses exceptions que vous prenez pour acquises, telles que NullPointerException ou IllegalArgumentException , dérivent en fait de RuntimeException et vous n'avez donc pas besoin de déclarer leur. Les exceptions cochées sont un point de discorde entre deux disciplines. Je vous recommande donc de les essayer vous-même et de voir si cela vous aide ou vous agace. Personnellement, je pense que les exceptions vérifiées améliorent considérablement la factorisation du code et la robustesse.

2. Bien que Java prenne en charge la substitution automatique depuis un certain temps, il existe encore de nombreuses différences entre les implémentations C # et Java que vous devez connaître. Alors qu'en C #, vous pouvez utiliser indifféremment int comme type de valeur et type de référence, en Java, ils ne sont littéralement pas du même type: vous obtenez le type de valeur primitif int le type de référence de la bibliothèque java.lang.Integer . Cela se manifeste de deux manières communes: vous ne pouvez pas utiliser les types de valeur comme paramètre de type générique (vous utiliserez donc ArrayList < Integer > au lieu de ArrayList < int > ), et les méthodes utilitaires (telles que parse ou toString ) sont implémentées de manière statique dans le type de référence (donc ce n'est pas int a; a.toString (); mais plutôt int a; Integer.toString (a); ).

3. Java a deux types distincts de classes imbriquées, C # n'en a qu'un. En Java, une classe statique qui n'est pas déclarée avec le modificateur static est appelée une classe intérieure et dispose d'un accès implicite à l'instance de la classe englobante. Ceci est un point important car, contrairement à C #, Java n’a pas de concept de délégué et que les classes internes sont très souvent utilisées pour obtenir le même résultat avec relativement peu de peine syntaxique.

4. Les génériques en Java sont implémentés de manière radicalement différente de C #; lorsque les génériques ont été développés pour Java, il a été décidé que les modifications seraient purement syntaxiques, sans support d'exécution, afin de conserver la compatibilité avec les versions antérieures avec les anciennes machines virtuelles. En l'absence de prise en charge directe des génériques au moment de l'exécution, Java les implémente à l'aide d'une technique appelée type. effacement . Il existe de nombreux inconvénients à l'effacement des types par rapport à l'implémentation générique de C #, mais le point le plus important à retenir est que les types génériques paramétrés en Java n'ont pas de types d'exécution différents . En d'autres termes, après la compilation, les types ArrayList & Intger > et ArrayList < Chaîne > sont équivalents . Si vous travaillez beaucoup avec des génériques, vous rencontrerez ces différences beaucoup plus tôt que vous ne le pensez.

À mon avis, il est très difficile pour un développeur C # de maîtriser le langage. Autre que cela, il y a les outils de développement et la bibliothèque de classes.

1. En Java, il existe une corrélation directe entre le paquet (espace de nom), le nom de la classe et le nom du fichier. Sous un répertoire racine commun, les classes com.example.SomeClass et org.apache.SomeOtherClass seront littéralement trouvées dans com / exemple / SomeClass.class et org / apache / SomeOtherClass.class respectivement. Méfiez-vous des tentatives de définition de plusieurs classes dans un seul fichier Java (c'est possible pour les classes privées, mais cela n'est pas recommandé) et respectez cette structure de répertoires jusqu'à ce que vous soyez plus à l'aise avec l'environnement de développement.

2. En Java, vous avez les concepts de class-path et de class-loader qui ne mappent pas facilement vers C # (il existe des équivalents grossiers qui ne sont pas utilisés couramment par la plupart des développeurs .NET). Classpath indique à la machine virtuelle Java où se trouvent les bibliothèques et les classes (les vôtres et les bibliothèques partagées du système!), Et vous pouvez considérer les chargeurs de classes comme le contexte dans lequel vos types évoluent. Les chargeurs de classes sont utilisés pour charger des types (fichiers de classe) à partir de divers emplacements (disque local, Internet, fichiers de ressources, etc.), mais limitent également l'accès à ces fichiers. Par exemple, un serveur d'applications tel que Tomcat aura un chargeur de classe pour chaque application ou contexte enregistré; cela signifie qu'une classe statique dans l'application A ne sera pas identique à une classe statique dans l'application B, même si elles portent le même nom et même si elles partagent le même codebase. Les domaines d'application fournissent des fonctionnalités quelque peu similaires dans .NET.

3. La bibliothèque de classes Java est similaire à BCL. beaucoup de différences sont esthétiques, mais il suffit de vous lancer pour la documentation (et / ou Google) encore et encore. Malheureusement, je pense qu'il n'y a rien à faire ici & # 8212; vous allez simplement vous familiariser avec les bibliothèques au fur et à mesure.

En bout de ligne: le seul moyen de parler de Java est de l’utiliser. La courbe d’apprentissage n’est pas raide, mais préparez-vous à être surpris et frustré assez souvent au cours des deux ou trois premiers mois d’utilisation.

Answer 3

La réponse courte est que cela va être agaçant, mais pas difficile.

Java et C # ont tous les mêmes concepts sous-jacents, et beaucoup de bibliothèques sont très proches les unes des autres, mais vous allez continuer à cogner à travers diverses différences.

Si vous parlez de propriétés de classe, Java les possède. La syntaxe est

public class MyClass {
    public static int MY_CLASS_PROPERTY = 12;
}

Je vous recommanderais sérieusement d’obtenir un meilleur IDE. Tous les Netbeans, Eclipse, IDEA, JBuider vont rendre votre transition beaucoup plus agréable.