Crow 1.1.0 released

Несмотря на то, что все фичи к релизу были подготовлены уже давно, акт выпуска новой версии произошел только сегодня.

Скачать можно отсюда.

В релиз 1.1.0 были включены 5 новых фич:

• 3364079 Export Traceability Matrix to Excel
• любой Traceability Report теперь можно сохранить в Excel-файл. Используется библиотека Apache POI.
• 3313584 Add filtering capabilities to Traceabilty tab
•  в окно "добавить трассировку" были добавлены текстовые поля для динамического поиска нужных элементов. Выглядит это так:

• 3300468 Filter Perforce changelists by description
•  аналогично предыдущей фиче, в окне добавления Perforce changelists теперь можно делать дополнительную фильтрацию по описанию:

• 3294913 Support new trace type DD2TRS
• несмотря на то, что ASPICE запрещает прямую трассировку TRS на детальный дизайн, бывают ситуации, когда описание архитектуры недоступно, и в этом случае установить необходимые трассы нельзя. Поэтому был добавлен новый тип связи, позволяющий трейсить TRS непосредственно на детальный дизайн и обратно.
• 2946382 Mark some CRS as "should not be traced"
• иногда в базе CRS есть отклоненные (rejected) или устаревшие требования, которые намеренно не покрыты TRSами, дизайном, кодом и т.д. Чтобы в отчете о трассировке эти CRS не светились красным цветом, появилась возможность обозначать их как "не трассируемые". В отчете это выглядит, например, вот так:

За реализацию фильтров и нового типа трассировки отдельное спасибо Саше Кондратюку!

Приятной работы!

Кстати, в этом релизе мы попробовали CodeStriker - бесплатный инструмент для проведения peer code review. По сравнению с Crucible - ужасно: неудобный интерфейс, корявое отображение исходников, для просмотра комментариев необходимо кликать на закладки (нет режима отображения кода вместе с комментариями).

Is Data a Software?

Сегодня инициировал, а затем полтора часа участвовал в дискуссии, смысл которой можно свести к вопросу "можно ли входные данные, обрабатываемые программой, также называть Software"?

По завершении дискуссии, нашел интересную статью Peter Suber, "What is Software?" Несколько цитат из глав 9 и 11:

To compile a program written in a high level language, it must be treated as data by another program, the compiler. It must passively be worked upon, so that later it may actively do work. Without this step, the programmer might as well have spoken in English. Programs written originally in the binary code readable by the machine do not require this translation, and hence need not be treated as data. But virtually all programs written today are written in higher level languages.
Apart from this critical step in the very functioning of software, programs are treated as data for the purpose of copying (publishing) and transmitting them. Even if a program were originally written in machine language, chances are good that if we are using it, its code has once been treated as data by another program.

Software may essentially be pattern, but how is it to be distinguished from patterns that are used as data rather than software? How does it take the position of natura naturata and then natura naturans? This seems to be the central mystery. How can pattern be read as instructions? How can mere pattern rise from passivity to activity? Why isn't sheer syntactical pattern always inert, perpetually data and never software?

 ...

We can approach answers to these questions by saying that software is pattern in a controlling position, while the same pattern in a different position will be data (and the same pattern under different language conventions will be noise). But what is this "position"? The first thing to observe about it is that it is not part of the pattern. It is the use to which the pattern is put, or the relation between the software-pattern and other patterns that are currently functioning as data. In this, to assume the "controlling position" is similar to meeting the physical requirement of readability; it leaves the pattern unchanged and occurs independently of the syntactic and semantic content of the pattern.

It is this "position" or use of the software pattern that enables its binary code to be taken as code for instructions that are to be executed. The matter is simpler than it may appear. If we write down on one piece of paper directions for copying a page of text, and on another piece of paper directions for erasing or shredding a page of text, then we may give them to a stranger and ask that the top sheet be read and applied to the bottom sheet. It does not matter how they are shuffled; each can apply to the other as it can apply to itself. One is put in a controlling position if the "hardware" (here the stranger) reads one first and one second. Odysseus may command his men to tie him to the mast as his ship passes the island of sirens, and to ignore any commands to be released that he might issue. If his men obey this command, then it "poisons the well" for future commands and causes them to be interpreted as data. But the commands to be released are like the directions written to the stranger: fully satisfactory and "authoritative" as commands. Whether they function as commands or data is a matter of whether they are taken up earlier or later than other contenders.

Вкратце: data также является software. IEEE также считает данные подмножеством software.

Комментарии к методам

Очень понравилась фраза из SQLite coding style; не могу удержаться, чтобы не скопировать сюда:

31. Function header comment defines the behavior of the function in sufficient detail to allow the function to be reimplemented from scratch without reference to the original code.

Проблемы документирования software design

Сегодня на постмортеме решали, как менять существующий процесс документирования дизайна. Проблемы очевидны:

• дизайн-документы хранятся в морально устаревшем формате Word, низкая прозрачность
• сложный шаблон документа как результат стремления покрыть все требования к дизайну из ASPICE L3 HIS scope
• непонятно, актуально ли описание дизайна, или уже устарело - к коду доверия больше.

Как перестать писать дизайн "из-под палки" и что вообще делать - мне пока непонятно. Нашел вот цитату из David Parnas and Paul Clements. "A Rational Design Process: How and Why to Fake It" in Software State-of-the-Art: Selected Papers. Dorset House, 1990, pg. 353-355:

It should be clear that documentation plays a major role in the design process that we are describing. Most programmers regard documentation as necessary evil, written as an afterthought only because some bureaucrat requires it. They do not expect it to be useful.
This is a self-fulfilling prophesy; documentation that has not been used before it is published, documentation that is not important to its author, will always be poor documentation.
Most of that documentation is incomplete and inaccurate, but those are not the main problems. If those were the main problems, the documents could be easily corrected by adding or correcting information. In fact, there are underlying organizational problems that lead to incompleteness and incorrectness and those problems, which are listed below, are not easily repaired.
1) Poor Organization: Most documentation today can be characterized as "stream of consciousness" and "stream of execution." "Stream of consciousness" writing puts information at the point in the text that the author was writing when the thought occurred to him. "Stream of execution" writing describes the system in the order things will happen when it runs. The problem with both of these documentation styles is that subsequent readers cannot find the information they seek. It will therefore not be easy to determine that facts are missing, or to correct them when they are wrong. It will not be easy to find all the parts of the document that should be changed when the software is changed. The documentation will be expensive to maintain and, in most cases, will not be maintained.
2) Boring Prose: Lots of words are used to say what could be said by a single programming language statement, a formula, or a diagram. Certain facts are repeated in many different sections. This increases the cost of the documentation and its maintenance. More importantly it leads to inattentive reading and undiscovered errors.
3) Confusing and Inconsistent Terminology: Any complex system requires the invention and definition of new terminology. Without it the documentation would be far too long. However, the writers of software documentation often fail to provide precise definitions for the terms they use. As a result, there are many terms used for the same concept and many similar but distinct concepts described with the same term.
4) Myopia: Documentation that is written when the project is nearing completion is written by people ho have lived with the system for so long that they take major decisions for granted. They document the small details that they think they will forget. Unfortunately, the result is a document useful to people who know the system well, but impenetrable for newcomers.
Documentation in the ideal design process meets the needs of the initial developers as well as the needs of the programmers who come later. Each of the documents mentioned above records requirements or design decisions and is used as a reference document for the rest of the design. However, they also provide the information that the maintainers will need. Because the documents are used as reference manuals throughout the building of the software, they will be mature and ready to use in later work. The documentation in this design process is not an afterthought; it is viewed as one of the primary products of the project. Some systematic checks can be applied to increase completeness and consistency. [...]
"Stream of consciousness" and "stream of execution" documentation is avoided by designing the structure of each document. Each document is designed by stating the questions that it must answer and refining the questions until each defines the content of an individual section. There must be one, and only one, place for every fact that will be in the document. The questions are answered, i.e., the document is written, only after the structure of the document has been defined. When there are several documents of a certain kind, a standard organization is written for those documents. Every document is designed in accordance with the same principle that guides our software design: separation of concerns. Each aspect of the system is described in exactly one section and nothing else is described in that section. When documents are reviewed, they are reviewed for adherence to the documentation rules as well as for accuracy.
The resulting documentation is not easy or relaxing reading, but it is not boring. It makes use of tables, formulas, and other formal notation to increase the density of information. The organizational rules prevent the duplication of information. The result is documentation that must be read very attentively, but rewards its reader with detailed and precise information. [...]
No matter how often we stumble on our way, the final documentation will be rational and accurate. Even mathematics, the discipline that many of us regard as the most rational of all follows this procedure. [...] Analogous reasoning applies to software. Those who read the software documentation want to understand the programs, not relive their discovery. By presenting rationalized documentation we provide what they need.
Our documentation differs from the ideal documentation in one important way. We make a policy of recording all of the design alternatives that we considered and rejected. For each, we explain why it was considered and why it was finally rejected. Months, weeks, or even hours later, when we wonder why we did what we did, we can find out. Years from now, the maintainer will have many of the same questions and will find his answers in our documents.

"Толстые" дороги в SLD

Для отрисовки карт в нащих плагинах к uDig, мы используем Styled Layer Decorator (SLD).

На прошлой неделе я решал проблему отрисовки дорог шириной более 1 пикселя. Вот как оно выглядело изначально:



Очевидные проблемы:

1. Отрисовка перекрестков. На перекрестках дорог видно не соединенные между собой окончания сегментов.
   
2. Взаимное наложение дорог. При слишком близком расположении, дороги хаотически взаимно перекрываются. Особенно это заметно, опять же, на перекрестках. Кроме того, в левом верхнем углу заметно, что сегменты двух дорог (со стрелочками) также поочередно перекрываются.

SLD обеспечивает настройку правил для отрисовки дорог с помощью LineSymbolizer:

<sld:LineSymbolizer>
 <sld:Stroke>
  <sld:CssParameter name="stroke">#00ff00</sld:CssParameter>
  <sld:CssParameter name="stroke-opacity">1</sld:CssParameter>
  <sld:CssParameter name="stroke-width">1</sld:CssParameter>
  <sld:CssParameter name="stroke-linejoin">round</sld:CssParameter>
  <sld:CssParameter name="stroke-linecap">round</sld:CssParameter>
 </sld:Stroke>
</sld:LineSymbolizer>

Предполагается, что, управляя параметрами linejoin (miter, round, bevel) и linecap (butt, square, round), можно добиться желаемого эффекта. Например, в статье "GeoServer render OpenStreetMap" приводится реальный SLD-стиль, использующийся для отрисовки OSM. Как видно из примеров, хороших результатов удалось добиться только для мелких масштабов; при приближении становятся видны артефакты перекрестков и назойливые "сосисочные" окончания дорожных сегментов.

Продолжив поиски и поэкспериментировав с параметрами LineSymbolizer, я сделал вывод, что возможностей SLD для отрисовки таких "толстых" дорог, какие у нас были изначально (8-14 пикс.) попросту недостаточно. Уменьшив ширину до 2-6 пикселей и выставив linecap = butt, linejoin = miter, я получил такой результат:



Цвета я поменял на более близкие к Google Maps, но это не принципиально.

Кроме этого, заметил следующее:

1. Для отрисовки направлений движения GeoServer в стиле tiger.sld использует TextSymbolizer, печатающий "стрелочку":
   

   
   <sld:Label>
       <ogc:Literal>←</ogc:Literal>
   </sld:Label>
   

   
   Однако, я столкнулся с тем, что стрелочка у меня непредсказуемо переворачивается (очевидно, это зависит от направления вектора, представляющего дорогу, относительно базовой точки). Поэтому направление движения я задаю с помощью LineSymbolizer, отрисовывающего стрелочку попиксельно.
   
2. Управлять порядком отрисовки дорог с помощью разных Rule внутри одного FeatureTypeStyle толком нельзя, поскольку GeoTools применяет эти правила в непредсказуемом порядке. Я вынес правило для отрисовки каждого из типа дорог в отдельный FeatureTypeStyle, после чего они стали отрисовываться в порядке, указанном в моем SLD.

На этом я пока что и остановился.

Смешной код

Несколько смешных участков кода из нескольких проектов:

1. Магический скрипт

private final String magicScript = "\nif(8==8)return;";

2. Глубокая иерархия

public void dragEnter(DropTargetDragEvent arg0) {                                                            
   ((DropTargetListener)getParent().getParent().getParent()
      .getParent().getParent()).dragEnter(arg0);        
}                                                                                                            
                                                                                                             
public void dragExit(DropTargetEvent arg0) {                                                                 
   ((DropTargetListener)getParent().getParent().getParent()
      .getParent().getParent()).dragExit(arg0);         
                                                                                                             
}                                                                                                            
                                                                                                             
public void dragOver(DropTargetDragEvent arg0) {                                                             
   ((DropTargetListener)getParent().getParent().getParent()
      .getParent().getParent()).dragOver(arg0);         
                                                                                                             
}                                                                                                            
                                                                                                             
public void drop(DropTargetDropEvent arg0) {                                                                 
   ((DropTargetListener)getParent().getParent().getParent()
      .getParent().getParent()).drop(arg0);             
}                                                                                                            
                                                                                                             
public void dropActionChanged(DropTargetDragEvent arg0) {                                                    
   ((DropTargetListener)getParent().getParent().getParent()
      .getParent().getParent()).dropActionChanged(arg0);
}                                                                                    

3. Магические вычисления

int ww0 = getWidth() ;//- 40;                          
int hh0 = getHeight();// - 40;                         
int sz = Math.min(ww0, hh0);                           
                                                       
sz = sz/4*3;                                           
                                                       
                                                       
int y0 = (hh0 - sz) / 2;                               
                                                       
                                                       
                                                       
int x0 = 0;                                            
int h = sz / 2;                                        
int dh = sz / 4;                                       
                                                       
int y = y0 + h;                                        
                                                       
int hh = (int)Math.sqrt(h*h - h*h/4);                  
y0 = y - hh;                                           
                                                       
                                                       
Rectangle rect = new Rectangle(x0, y0 , sz,  hh + hh );
                                                       
int arrX[] = {x0 + dh, x0 + 3*dh, x0 + sz,             
              x0 + 3*dh   , x0 + dh, x0};              
int arrY[] = {y0 , y0 , y ,                            
               y0 + hh + hh, y0 + hh + hh, y};         
                                                       
Polygon poly = new Polygon(arrX, arrY, 6);             
                                                       
return poly;                                           

CROW: Control the Development Workflow

Начало истории - см. здесь.

Сегодня выложил на SourceForge.net исходники и snapshot-релиз своего нового Java-проекта CROW (Control the development workflow).

CROW - это ASPICE-совместимая система, предназначенная для управления и мониторинга:

• требований заказчика
• технических требований
• описания архитектуры
• детального дизайна
• ревизий кода в системе версионного контроля
• тестов

В настоящее время программа позволяет:

• добавлять/удалять/редактировать все артефакты, перечисленные выше
• устанавливать зависимости между ними (например, "changelist #800 реализует техническое требование REQ-007-DAT-DragAndDrop, которое описывает требование заказчика Support drag&drop of DAT-files")
• строить матрицу трассировки (RTM, Requirements Traceability Matrix), показывающую описанные выше отношения, в т.ч. транзитивные, т.е. связь между CRS и тестом через код, детальный дизайн, архитектуру и TRS программа вам покажет)
• создавать метки и присваивать их различным артефактам, что позволяет определять и фиксировать т.н. baseline для требований, ревизий, тестов и пр.
  

Немного о реализации:

• JRE 1.6, в более старых не тестировал и не хочу.
  
• GUI в виде Swing-клиента. Пишу для Windows, но в Linux тоже проверял - явных косяков нет.
• База - через Hibernate. В текущей реализации используется PostgreSQL.
• Использую docking framework VLDocking, чтобы все окошки можно было перетаскивать как нравится.
• Пишу все сам, тестировщиков также нет. Добровольцы призываются!
  

Адрес проекта на SourceForge - http://sourceforge.net/projects/opencrow/.

Баг в JTable: теряется множественный selection при начале DnD

Пишу класс, перегружающий JTable, и снова вижу баг, который видел еще под JRE 1.4.2 году в 2006-м.

Ссылка на баг: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6195469.

Ошибка заключается в том, что, если в JTable выделить несколько ячеек и попытаться их перетащить (drag & drop), то, сразу же после нажатия кнопки мыши, selection сбрасывается со всех ячеек, кроме той, на которую непосредстенно нажали.

Воркараунд, приведенный по ссылке выше, по крайней мере в 1.6 не работает. Поэтому выкладываю свой класс FixedTableUI, которым можно подменить тот класс, который предлагается в воркараунде. Работает с 1.4 по 1.6 включительно:

   /**
    * This internal helper class helps to solve two bugs:
    * The first is disable row selection with mouse drag
    * The second is allow handling of multiple selected rows without need to
    * hold a Shift key.
    */   
   private class FixedTableUI extends BasicTableUI {
      private MouseInputHandler handler = new MouseInputHandler() {
         
         private boolean isShiftDownInMousePressed = false;

         
         public void mouseDragged(MouseEvent e) {
            // Do nothing here!
         }
         
         public void mousePressed(MouseEvent e) {
            isShiftDownInMousePressed = e.isShiftDown();             
            int row = rowAtPoint(e.getPoint());
            if (!getSelectionModel().isSelectedIndex(row)) {
               super.mousePressed(e);
            } else {                
               if (e.isControlDown()) {
                  if (getSelectionModel().isSelectedIndex(row)) {
                     getSelectionModel().removeSelectionInterval(row, row);
                  }
               }
            }
         }
         
         public void mouseReleased(MouseEvent e) {
            super.mouseReleased(e);
            int row = rowAtPoint(e.getPoint());
            int col = columnAtPoint(e.getPoint());
            int[] selRows = getSelectedRows();
            if (selRows.length > 0) {
               if (!e.isControlDown() && !e.isShiftDown() &&
                     !isShiftDownInMousePressed) {             
                  getSelectionModel().setSelectionInterval(row, row);
               }
            }
         }
      };
      
      protected MouseInputListener createMouseInputListener() {
         return handler;
      }     
   }

java.io.tmpdir в Windows и Linux

Только что попробовал запустить в Убунту программу, разработанную под Windows. Ну что сказать - был удивлен.

System.getProperty("java.io.tmpdir") в Windows возвращает что-то наподобие:

C:\Windows\Temp\

А в Linux мне приходит вот что:

/tmp

Обратите внимание - в первом случае завершающий слеш есть, а во втором - нет, что требует дополнительной проверки в коде.

"Java: написано однажды - тестируем везде" (c)

JTabbedPane и фокус в ней

Сегодня нашел новый (для меня, разумеется) баг в Swing. Проблема заключается в том, что если на панели есть JTabbedPane, а в ней лежит компонент, который должен получить фокус после того, как происходит переключение на соответствующий таб, то фокус этот он не получит.

Вот неработающий код:

tabPane.addChangeListener(new ChangeListener() {
  public void stateChanged(ChangeEvent e) {
    txtName.requestFocusInWindow();
  }    
});

Баг #5089436 (а ему уже около 5 лет) предлагает воркэраунд, связанный с обрамлением вызова requestFocusInWindow() в  invokeLater():

tabPane.addChangeListener(new ChangeListener() {
  public void stateChanged(ChangeEvent e) {
    EventQueue.invokeLater(new Runnable() {    
      public void run() {
        txtName.requestFocusInWindow();
      });
  }    
});

А в остальном Свинг по-прежнему хорош.

На пути к оптимизации

Только что наткнулся на такой вот участок кода в нашем приложении:

// This method produces a HUGE overhead
//TreeNodesUpdater.updateComponentTreeUI(this);
  
// This works, but cuts end part of lines in bold (produces "...")
/*this.invalidate();
this.validate();
this.repaint();*/
  
// So, we just switch the renderer to null and back to the original one,
// which revalidates the sizes
setCellRenderer(null);
TreeCellRenderer renderer = createCellRenderer();

setCellRenderer(renderer); 

А за каждой из этих строчек - целая история...

Я - хороший PHP-программист!

Эх, помнят руки-то))

Война подчеркивания и дефиса: разные стандарты именования в Maven и Eclipse PDE

В одном из наших Eclipse-проектов сборка происходит следующим образом:

1. Сначала мы собираем target-платформу для системы uDig (user-friendly Internet GIS) - набор OSGi-bundles. Состоит она из:

• GeoAPI и ее зависимостей
• GeoTools и ее зависимостей
  

Сборка GeoAPI и GeoTools выпоняется с помощью Apache Maven, который автоматически скачивает нужные зависимости с прописанных репозиториев, запускает компилятор, генерирует MANIFEST.MF для OSGi-бандлов - короче, делает все. В результате мы имеем папку с набором JAR-файлов примерно следующего содержания:
...
java3d.osgi.vecmath-1.3.1.jar
javax.media.jai.osgi.jai_imageio-1.1.0.jar
net.opengis.ows-2.6.0-SNAPSHOT.jar
...

Эта папка - не что иное, как target platform для компиляции uDig, которая делается через PDE.

2. Мы запускаем Eclispe PDE batch build и компилируем uDig. В результате мы получаем продукт uDig, в папке plugins которого, среди прочих, оказываются уже такие файлы:
...
java3d.osgi.vecmath_1.3.1.jar
javax.media.jai.osgi.jai_imageio_1.1.0.jar
net.opengis.ows_2.6.0_SNAPSHOT.jar
...

Первый вывод уже очевиден:

Maven использует "-" (дефис) для отделения номера версии от имени бандла, в то время как PDE использует для этого "_" (подчеркивание)

3. Для того, чтобы собрать наш проект, нам нужна платформа в составе:

• OSGi-бандлы из папки plugins системы uDig
• наши проприетарные модули и их зависимости
  

Причем сборка второго пункта также выполняется с помощью Maven. Соответственно, нам очень удобно использовать модули, уже находящиеся в локальном m2-репозитории - такие, как, например, java3d.osgi.vecmath-1.3.1.jar. Однако, когда мы пытаемся добавить к нашим плагинам плагины из uDig, начинаются проблемы, поскольку в uDig, как мы помним, соответствующая библиотека называется уже java3d.osgi.vecmath_1.3.1.jar (подчеркивание вместо дефиса). Поэтому в результате простого копирования файлов получаем следующую картину:
...
java3d.osgi.vecmath_1.3.1.jar
java3d.osgi.vecmath-1.3.1.jar
javax.media.jai.osgi.jai_imageio_1.1.0.jar
javax.media.jai.osgi.jai_imageio-1.1.0.jar
net.opengis.ows_2.6.0_SNAPSHOT.jar
net.opengis.ows_2.6.0-SNAPSHOT.jar
...
Т.е. набор идентичных по смылу OSGi-бандлов, но продублированных в файлах с разными именами.

Пока что, чтобы решить эту проблему, я стал используюVBS-скрипт, который переименовывает файлы по заданному регулярному выражению с тем, чтобы заменить подчеркивание на дефис. Хотя, наверное, нужно делать это прямо в PDE-сборке и заменять наоборот - дефис на подчеркивание...

А война дефиса и подчеркивания, между прочим, разгорелась нешуточная. В мейл-листах Maven утверждают, что единственно верный разделитель - это дефис. Эклипс пока что понимает только подчеркивание, хотя в 3.5 обещают это исправить (в 3.5 М4, вроде, уже вставили соответствующий патч).

Системы управления требованиями: ReqHeap и OSRMT

Вчера попользовал две системы управления требованиями: Reqheap (http://reqheap.sourceforge.net/) и OSRMT (Open Source Requirement Management Tool, http://osrmt.com). Сказать имею следующее:

ReqHeap сделан на связке PHP+MySQL, поднимается легко, мыслит в терминах проектов, подпроектов, требований и тест-кейсов. Поддерживает много пользователей и разграничение прав. Однако, проследить traceability, скажем, от требований к тестам, построить матрицу и пр. не представляется возможным - нет средств. Короче, просто удобная хранилка всего вышеперечисленного.

OSRMT - могучая вещь, имеющая как Swing-интерфейс, так и веб-клиента. Сделана на Java. Ее словарь, вкратце, таков:

• Requirement
• Feature
• Design
• Implementation
• Test

Система позволяет строить traceability matrix от всего ко всему, рисовать диаграммы зависимостей и пр. Из недостатков можно отметить убогость веб-клиента (например, вводишь текст требования в Swing-приложение, форматируешь его там, а потом смотришь в веб - а оно все сплошняком порет. Уж хотя бы <pre>-теги ставило... Кроме того, странным кажется то, что веб-клиент и Swing-клиент по умолчанию использую разные БД, находящиеся в разных папках.

И зачем было так делать?

Короче, вопрос поиска (бесплатной) подходящей системы управления требованиями, позволяющей отслеживать их до дизайна, имплементации, тестов и обратно, пока остается открытым.

Как JComboBox всех зарулил

И снова Swing, и снова баг - на этот раз в JComboBox. Состоит в следующем:


JComboBox box = new JComboBox();
box.addItem("x");
box.addItem("x");
box.setSelectedIndex(1);
System.out.println(box.getSelectedIndex())


Этот код напечатает в консоль не 1, как ожидалось, а 0. Баг состоит в том, что метод getSelectedIndex() возвращает индекс первого попавшегося элемента, равного селектированному, причем сравнение выполняется методом equals().

В развернувшейся бурной дискуссии сотрудники Sun пытаются доказать, что данное поведение корректно, поскольку оба элемента x равны. Лично я не согласен: так мог бы вести себя метод getSelectedItem(), но от getSelectedIndex() я бы ожидал возврат выбранного индекса , а не какого-нибудь другого.

Багу #4133743 уже более 10-ти лет. Интересно состояние данного тикета: "11-Closed, Not a Defect, bug". :))

Разрешить нельзя запретить

На сайте http://neoutils.ru (и какого меня туда понесло?) наткнулся на замечательную программу NeoAutorun. Софтина позволяет контролировать список автоматически загружаемых программ, но это неважно - я ее не видел, и не хочу. Меня впечатлил чекбокс на скриншоте:



Сейчас вот размышляю о возможности существования текстового поля "ввести/стереть", кнопки "сохранить/удалить" и выпадающего списка "раскатать/закатать"...

Еще один баг от Swing

Только что еще один Свинговый баг побороли. На одной из ~10 машин, где работает наша программа, запуск диалога выбора файлов JFileChooser занимает примерно полминуты (ну о-о-очень долго, если честно). Кроме того, переход в любую папку также отбирает несколько секунд. Windows XP SP2 стоит, последние обновления, все дела... А на других машинах - все хорошо.

После непродолжительного копания, наткнулся на описание Java-Sun bug #5050516. Оказывается, на некоторых системах такое поведение вызывается поддержкой Windows Compressed Folders. После того, как отключили ее командой

regsvr32 /u %windir%\system32\zipfldr.dll,

все заработало быстро и правильно.

Багу больше 4х лет. В jdk 1.6 он еще живет. Вроде, исправили в седьмом, но я не проверял))

Побороли ошибку

Третьего дня одна девушка, работающая в моей команде, поборола ошибку в программе. Ошибка заключалась в следующем: при запуске swing-приложения его окно (разворачиваемое на весь экран) загадочно мерцало где-то полсекунды.

Путем самоотверженных изысканий установилось, что каждый раз при запуске программы из Eclipse девушка дергала под столом ножкой. Ножка цепляла кабель, идущий от видеокарты к монитору, что и вызывало странное мерцание экрана. В результате отказа от дерганья ножкой от проблемы удалось избавиться.

А почему дергала, спросите вы? Такие уж это загадочные существа - женщины :)

YourKit

Открыл для себя замечательный профилировщик (он же профайлер) - называется YourKit. Умеет профилировать и CPU, и память, и потоки, и дедлоки... А, во, еще имеет плагин для Eclipse, позволяющий запускать профайлинг прямо оттуда.

Не, я реально в восторге! Только что с его помощью выяснил, почему в одном из наших продуктов не высвобождалась память при закрытии старого документа и открытии нового. Наш обработчик тултипов хранил ссылку на TableColumn, который хранил ссылку на объект SwingPropertyChangeSupport, у которого в списке маус-моушн-лиснеров зачем-то хранилась DefaultTableModel. Из-за этой "лишней" ссылки на данные GC никогда их реально и не прибивал... Ну, блин, Swing!!! А YourKit все сразу показал - и самые большие объекты в памяти, и ссылки на них.

Зараза, к сожалению, платная, но обладает 15-дневным пробным ключом активации. Очень рекомендую попробовать! Ведь как приятно, после дня мучений, увидеть такой замечательный график:

Бинарные форматы документов Microsoft Office 97-2007 открыты!

В прошлую пятницу Microsoft открыла общественности спецификации бинарных форматов для Word, Excel, PowerPoint и Drawing 97-2007.

Брать отсюда: http://www.microsoft.com/interop/docs/OfficeBinaryFormats.mspx.

А здесь Джоэль дает несколько комментариев и полезных советов к тому, как это все понимать.