java.net по сравнению с java.nio
Исключение нулевого указателя - это индикатор того, что вы используете объект, не инициализируя его.
Например, ниже - класс ученика, который будет использовать его в нашем коде.
public class Student {
private int id;
public int getId() {
return this.id;
}
public setId(int newId) {
this.id = newId;
}
}
Приведенный ниже код дает вам исключение с нулевым указателем.
public class School {
Student obj_Student;
public School() {
try {
obj_Student.getId();
}
catch(Exception e) {
System.out.println("Null Pointer ");
}
}
}
Поскольку вы используете Obj_Student, но вы забыли инициализировать его, как в правильном коде, показанном ниже:
public class School {
Student obj_Student;
public School() {
try {
obj_Student = new Student();
obj_Student.setId(12);
obj_Student.getId();
}
catch(Exception e) {
System.out.println("Null Pointer ");
}
}
}
4 ответа
Масштабируемость будет, вероятно, управлять Вашим выбором пакета. java.net потребует одного потока на сокет. Кодирование его будет значительно легче. java.nio является намного более эффективным, но может быть волосатым для кодирования вокруг.
я спросил бы себя, сколько соединений Вы ожидаете обрабатывать. Если это - относительно немногие (скажите, < 100), я пошел бы с java.net.
Избегайте NIO, если у Вас нет серьезного основания использовать ее. Это не много забавы и не может быть так выгодно, как Вы думали бы . Можно получить лучшую масштабируемость, после того как Вы имеете дело с десятками тысяч соединений, но в более низких числах Вы, вероятно, получите лучшую пропускную способность с блокированием IO. Как всегда, хотя, сделайте свои собственные измерения перед согласием на что-то, о чем Вы могли бы сожалеть.
Что-то еще для рассмотрения - то, что, если Вы хотите использовать SSL, NIO делает его чрезвычайно болезненным.
Количество соединений, о которых Вы говорите, говорит мне, что необходимо использовать java.net. Действительно, нет никакой причины усложнить Вашу задачу с неблокированием ввода-вывода. (Если Ваши удаленные системы не являются недостаточно мощными, но затем почему Вы используете Java на них?)
Смотрят на XML-RPC Apache пакет. Это просто в использовании, полностью скрывает сетевой материал от Вас и работает по старому доброму HTTP. Никакая потребность волноваться о протоколе не выходит..., он будет все похож на вызовы метода Вас на обоих концах.
Учитывая небольшое количество соединений включил, java.net походит на правильное решение.
Другие плакаты говорили об использовании XML-RPC. Это - хороший выбор, если объемы поставляемых данных являются маленькими, однако у меня были неудачные опыты с основанными на XML протоколами при записи межпроцессных взаимодействий, которые поставляют большие объемы данных (например, большой запрос/ответы или частые небольшие объемы данных). Стоимость парсинга XML обычно является порядками величины выше, чем более оптимизированные проводные форматы (например, ASN.1).
Для низких приложений регулятора громкости простота XML-RPC должна перевесить затраты на производительность. Для передачи данных большого объема может быть лучше использовать более эффективный проводной протокол.