JDay registration opened

Всі хто хоче відвідати конференцію, почути доповіді від розробників джави чи спрінга, взяти участь у воркшопі від амазона - заходьте та реєструйтесь.

Udacity. Introduction to Programming. Java

Udacity розпочинає курс Introduction to Programming. Java.

Якщо Ви маєте знайомих, які б хотіли почити програмувати - це дуже вдаллий час розпочати!

Посилання на курс тут

Обзор java.util.concurrent.*

В повседневной работе не так уж часто приходится сталкиваться с пакетом для многопоточности java.util.concurrent. Иногда существуют проектные ограничения по использованию java 1.4.2, где нет данного пакета, но чаще всего хватает обычной синхронизации и не требуется ничего сверхъестественного. К счастью, периодически возникают задачи, заставляющие немного пораскинуть мозгами и либо написать велосипед, либо порыться в javadoc'ах и найти что-то более подходящее. С велосипедом проблем нет — просто берешь и пишешь, благо ничего суперсложного в многопоточности нет. С другой стороны, меньше кода — меньше багов. Тем более, что на многопоточность никто в здравом уме юнит тестов не пишет, т.к. это уже полноценные интеграционные тесты получаются со всеми вытекающими последствиями.

Что выбрать для конкретного случая? В условиях запарки и deadline'ов довольно сложно охватить весь java.util.concurrent. Выбирается что то похожее и вперед! Так, постепенно, в коде появляются ArrayBlockingQueue, ConcurrentHashMap, AtomicInteger, Collections.synchronizedList(new LinkedList()) и другие интересности. Иногда правильно, иногда нет. В какой то момент времени начинаешь осознавать, что более 95% стандартных классов в java вообще не используются при разработке продукта. Коллекции, примитивы, перекладывание байтиков с одного места на другое, hibernate, spring или EJB, еще какая то библиотека и, вуаля, приложение готово.

Чтобы хоть как то упорядочить знания и облегчить вхождение в тему, ниже идет обзор классов для работы с многопоточностью. Пишу прежде всего как шпаргалку для себя. А если еще кому сгодится — вообще замечательно. 

Learning Scala by example

Друзі, дехто з вас висловив бажання почитати про мову Scala в якомусь більш практичному середовищі - наприклад, розробка веб-аплікації з нуля. Я почав серію блог постів (англійською) на цю тему, вона доступна за лінкою.

Буду вдячний за питання, коментарі і пропозиції

400 Пост JUG L'viv

Минулої п'ятниці відбулася знакова подія для нашого блогу ми пересікли позначку в 400 постів.
Цим постом став пост про нашу конференцію: http://jug-lviv.blogspot.com/2013/05/jday-lviv.html

ПС. Маєте бажання долучитись до досягнення наступного великого числа? Пишіть!
ПС2. Капітан очевидність.... :)

Five advanced Java Synchronizers you probably don’t know

Besides the common synchronize which is based in the lock bit that every Java object has, you have more sophisticated synchronizers in java, such as:

• Semaphore – Use the concept of a permit to indicate a max number of allowed threads in a place. When you use the value 1, the behavior its similar to synchronize, also called binary semaphore. There is however a big difference here, you acquire a permit on the semaphore, not a locking object,its just a variable to count when a thread acquires a permit and when a thread releases a permit, some kind of a counter. The only thing you really have are threads locking until a permit be available. In the example below, we define 3 as the number of permits, so after 3 acquires the 4 thread will wait for a release before continue its execution.

// Define the semaphore to control 3 permits. 
// 3 Threads can acquire the mySemaphore 
Semaphore mySemaphore = new Semaphore(3, true);

// 3 threads can execute this line of code. The 4 thread must wait for a release
mySemaphore.acquire();

// .. somewhere in the code a thread releases the mySemaphore, 
// and now the next waiting thread can acquire
mySemaphore.release();

Amazon WS workshop at JDay

Сьогодні Amazon долучився до JDay.

Представники Amazon проведуть воркшоп по AWS.
Детальний опис буде зовсім скоро. А поки що, прошу всіх небайдужих відповісти на запитання тут.
Пам'ятайте, ваша відповідь важлива.

Скоро JDay Lviv

Залишилось ледь більше місяця до конференції JDay Lviv. Це знакова подія, яка сподіваємось дасть поштовх для розвитку нашої групи та й загалом для розвитку львівського IT. Приємно, що в гості  приїдуть доповідачі з Oracle, Amazon, SpringSource, JFrog, Jetbrains та інших компаній.
Спасибі всім хто долучився до організації ну і звичайно спасибі спонсорам.
В наступний понеділок відкриється реєстрація на JDay Lviv.
Вартість конференції складе 350 гривень для early birds.
Хочу також оголосити, що 50 гривень з кожного квитка JUG Lviv віддасть на благочинність.

Ще раз всім велике дякую!

Most popular JVM memory configurations

For the task at hand we dug into the 1,024 environments we had gathered statistics from. 662 out of those had overridden the default maximum heap size by setting the -Xmxparameter. Also, 414 had felt that the permanent generation is not properly sized and had specified -XX:MaxPermSize by themselves. 

We found some interesting aspects from this data:

• 70% of the heaps were sized between 512MB and 4GB
• Only 4% of the heaps were larger than this. 
• Maximum heap we discovered from this dataset was 42GB
• 40% of the users specifying maximum size to the permgen set it to 256MB. 
• ... but there are two guys who either are bad at maths or have done some fine-tuning and set it to 258MB

Interesting?  Read more at: http://plumbr.eu/blog/most-popular-memory-configurations

IntelliJ IDEA покладена в основу нової Android Studio

На  Google I/O було оголошено про перехід з eclipse на IntelliJ IDEA.

Доречі, триває Google конференція. Виступи можне подивитись тут

10 Exception handling Best Practices in Java Programming

Exception Handling Java Best Practices

Here is my collection of 10 Java best practices to write Exception handling code in Java. There have been both applause and criticism of checked Exception in Java, which is a language feature to force dealing with Exceptions. In this article, we will look to minimize use of checked Exception and learn when to use checked vs unchecked exceptions in Java as well.

1) Use Checked Exception for Recoverable error and Unchecked Exception for programming error.

Choosing between checked and unchecked exception is always been confusing for Java programmers. Checked exceptions ensures that you provide exception handling code for error conditions, which is a way from language to enforcing you for writing robust code, but same time it also add lots of clutter into code and makes it unreadable. Also, it seems reasonable to catch exception and do something if you have alternatives or recovery strategies.  See checked vs unchecked exceptions for more information on choosing between checked and RuntimeException in Java.

2) Close or release resource in finally block

This is a well known best practice in Java and quite a standard, while dealing with networking and IO classes. Closing resources in finally block guarantees that precious and scarce resource released properly in case of normal and aborted execution, guaranteed by finally block. From Java 7, language has a more interesting automatic resource management or ARM blocks, which can do this for you. Nevertheless, always remember to close resources in finally block, which is important to release limited resources like FileDescriptors, used in case of both socket and files.

3) Including cause of Exception in stack-trace

Many times Java library and open source code wraps one Exception into another, when one exception is thrown due to result of another exception. Its become extremely important to log or print cause of root exception. Java Exception class provides getCause() method to retrieve cause which can be used to provide more information about root cause of Exception. This Java best practice helps a lot while debugging or troubleshooting an issue. Always remember to pass original Exception, into constructor of new Exception, if you are wrapping one exception into another.

4) Always provide meaning full message on Exception

message of Exception is the most important place, where you can point out cause of problem because this is the first place every programmer looks upon. Always try to provide precise and factual information here. For example, compare these two Exception messages for IllegalArgumentException :

message 1: "Incorrect argument for method"

message 2: "Illegal value for ${argument}: ${value}

first one just says that argument is illegal or incorrect, but second one include both name of argument and its illegal value which is important to point out cause of error. Always follow this Java best practice, when writing code for handling exceptions and errors in Java.

5) Avoid overusing Checked Exception

Checked Exception has there advantage in terms of enforcement, but at same time it also litters the code and makes it unreadable by obscuring business logic. You can minimize this by not overusing checked Exception which result in much cleaner code. You can also use newer Java 7 features like one catch block for multiple exceptions and automatic resource management, to remove some duplication.

6) Converting Checked Exception into RuntimeException

This is one of the technique used to limit use of checked Exception in many of frameworks like Spring ,where most of checked Exception, which stem from JDBC is wrapped into DataAccessException, an unchecked Exception. This Java best practice provides benefits, in terms of  restricting specific exception into specific modules, like SQLException into DAO layer and throwing meaningful RuntimeException to client layer.

7) Remember Exceptions are costly in terms of performance

One thing which is worth remembering is that Exceptions are costly, and can slow down your code. Suppose you have method which is reading from ResultSet and often throws SQLException than move to next element, will be much slower than normal code which doesn't throw that Exception. So minimizing catching unnecessary Exception and moving on, without fixing there root cause. Don’t just throw and catch exceptions, if you can use boolean variable to indicate result of operation, which may result in cleaner and performance solution. Avoid unnecessary Exception handling by fixing root cause.

8) Avoid empty catch blocks

Nothing is more worse than empty catch block, because it not just hides the Errors and Exception, but also may leave your object in unusable or corrupt state. Empty catch block only make sense, if you absolutely sure that Exception is not going to affect object state on any ways, but still its better to log any error comes during program execution. This is not a Java best practice, but a most common practice, while writing Exception handling code in Java.

9) Use Standard Exceptions

Our ninth Java best practice advise on using standard and inbuilt Java Exceptions. Using standard Exception instead of creating own Exception every now and then is much better in terms of maintenance and consistency. Reusing standard exception makes code more readable, because most of  Java developers are familiar with standard RuntimeException from JDK like, IllegalStateException, IllegalArgumentException or NullPointerException, and they will immediately be able to know purpose of Exception, instead of looking out another place on code or docs to find out purpose of user defined Exceptions.

10) Document Exception thrown by any method

Java provides throw and throws keyword to throw exception and in javadoc you have @throw to document possible Exception thrown by any method. This becomes increasingly important if you are writing API or public interface. With proper documentation of Exception thrown by any method you can potentially alert anyone who is using it.

That's all on Java best practices to follow while handing Exceptions in Java. Do let us know what practices you follow while  writing Exception handling code in Java.

Оригінал: http://javarevisited.blogspot.com/2013/03/0-exception-handling-best-practices-in-Java-Programming.html#ixzz2TA89IMP9

Java EE 7 Approved!

Java EE 7 is officially done as of this week.  Linda DeMichiel just announced on the Oracle blog that the Java EE 7 Platform JSR, as well as the more compact Web Profile JSR for this EE version, have both been approved by the Java Community Process.

Here's the complete list of 14 JSRs and 9 MRs (maintenance releases):

JSRs:

• Java Platform, Enterprise Edition 7 (JSR 342) 
• Concurrency Utilities for Java EE 1.0 (JSR 236) (New to JEE!)
• Java Persistence 2.1 (JSR 338)
• JAX-RS: The Java API for RESTful Web Services 2.0 (JSR 339)
• Java Servlet 3.1 (JSR 340)
• Expression Language 3.0 (JSR 341)
• Java Message Service 2.0 (JSR 343)
• JavaServer Faces 2.2 (JSR 344)
• Enterprise JavaBeans 3.2 (JSR 345)
• Contexts and Dependency Injection for Java EE 1.1 (JSR 346)
• Bean Validation 1.1 (JSR 349)
• Batch Applications for the Java Platform 1.0 (JSR 352) (New to JEE!)
• Java API for JSON Processing 1.0 (JSR 353) (New to JEE!)
• Java API for WebSocket 1.0 (JSR 356) (New to JEE!)

JUG 20 foto

Добрий день всім. нещодавно проходила наша 20 зустріч.
Цього разу нас приймала компанія N-iX. Врахувавши попередній досвід. Цього разу ми припинили реєстрацію швидше і нас зібралось приблизно 60-70 людей.
В подальшому будемо намагатись шукати більші приміщення і ще більше цікавих дем для обговорення.

Video з конференції Jpoint

Відео з конференції Jpoint, яка відбулася 5 квітня в С. Петербурзі

Відео тут

Git Explained: For Beginners

Посилання на блог з описом: http://juristr.com/blog/2013/04/git-explained/