Archiwa kategorii: Java

DCEVM – prawdziwy hot swap

Hot Swap, czyli podmiana kodu w trakcie działania aplikacji, jest w Javie dostępny już od dłuższego czasu. Jest to jednak hot swap częściowy, ponieważ Java HotSwap™ VM potrafi zaktualizować tylko implementację istniejących metod. Zmiany na poziomie klasy, czy całej hierarchii klas, są poza jej zasięgiem. W tym miejscu do akcji wkracza DCEVM, czyli Dynamic Code Evolution VM. Jest to modyfikacja wcześniej wspomnianej maszyny wirtualnej, która pozwala na dodawanie klas, metod, modyfikację drzewa dziedziczenia, a to wszystko bez restartu maszyny! Jako że jest to projekt open source, źródła i binarki są do ściągnięcia na oficjalnej stronie. Projekt jest jeszcze w fazie rozwoju, dlatego nie jest zalecane używanie go na produkcyjnych środowiskach. Doskonale natomiast może się sprawdzić na maszynach developerskich, gdzie potrafi zaoszczędzić sporo czasu potrzebnego na ponownie uruchamianie aplikacji. Osobiście jestem bardzo ciekawy jak będzie wyglądać rozwój DCEVM – bardzo mu kibicuję i liczę na pojawienie się takiego rozwiązania w standardowej maszynie wirtualnej od Oracle. Interesujące może być również to, jak przy rozwijających się darmowych rozwiązaniach poradzi sobie JRebel. Zasady działania tych dwóch narzędzi są różne, ale dla użytkownika końcowego znaczenie ma cel, który w obydwu przypadkach jest praktycznie taki sam.

Aha, dla osób używających IntelliJ IDEA dostępny jest plug-in ułatwiający integrację DCEVM z tym IDE. Zachęcam do zabawy!

MBean’y

Ostatnio miałem okazję zetknąć się z bardzo przydatnym mechanizmem, z którym szczerze mówiąc nie miałem nigdy wcześniej do czynienia. Jak się pewnie domyślacie chodzi tutaj o wspomniane w tytule MBean’y. Z jakiegoś powodu niewiele się o nich mówi, a są sytuacje, w których mogą być bardzo pomocne. Postaram się wam przybliżyć ten temat w dalszej części wpisu.

Czytaj dalej

Mockito – „łapiemy” argumenty wywołania metod

Temat Mockito był już na tym blogu poruszany kilkakrotnie (np. TU i TU). Opisywałem jak można wykorzystać to narzędzie do mockowania oraz weryfikacji wywołania metod. W tym drugim przypadku często zachodzi także konieczność wykonania dodatkowych asercji na argumencie weryfikowanej metody. Aby upewnić się, że program działa poprawnie, oprócz samego faktu wykonania metody sprawdzamy, czy jej argumenty mają poprawne wartości pól. Pomocna w takiej sytuacji jest klasa ArgumentCaptor będąca częścią Mockito. Poniżej znajdziecie przykładowy test, który z niej korzysta.
 

public class SampleTest
{
  private Canvas canvas;
  private CanvasPainter painter;

  @Before
  public void setUp() throws Exception
  {
    canvas = mock(Canvas.class);
    painter = new CanvasPainter(canvas);
  }

  @Test
  public void testDraw() throws Exception
  {
    Point point = new Point(1, 2);
    painter.addPoint(point);

    painter.draw();

    ArgumentCaptor captor = ArgumentCaptor.forClass(Point.class);
    verify(canvas, times(1)).draw(captor.capture());

    Point captured = captor.getValue();
    assertThat(captured.getX(), is(1D));
    assertThat(captured.getY(), is(2D));
  }
}

 
Kod jest chyba na tyle prosty, że nie wymaga dłuższego komentarza. Sprawdzamy w nim, czy wykonanie metody draw() klasy CanvasPainter powoduje wykonanie metody draw() klasy Canvas dla każdego punktu, który został dodany przy pomocy metody addPoint(). Prócz samego wywołania chcemy też sprawdzić, że przekazany do metody draw() klasy Canvas obiekt ma odpowiednie wartości pól x i y.

JARCamp #3 – rejestracja otwarta

Trzy ciekawe wykłady, fenomenalna atmosfera oraz ludzie, którzy tak jak Ty chcą podzielić się wiedzą  - tak zapowiada się trzeci JARCamp, na który można się już rejestrować. Spotkanie odbędzie się 12 kwietnia na barce Alrina. Prelekcje rozpoczynają się o godzinie 19:00. Poruszone zostaną na nich bardzo różnorodne tematy – od niuansów biblioteki Scalding aż po technologie portalowe. Nie zabraknie oczywiście przekąsek i napojów sponsorowanych przez firmę Metrosoft. Zapraszamy do REJESTRACJI!

Pełna agenda spotkania:

  • Scalding, czyli: WordCount Hadoopem nie musi mieć 70 linii- Konrad Malawski
  • „Dogfooding” w zespole Gradle - Szczepan Faber
  • JEE Portal? Is it a framework, a platform or a product? -Milen Dyankov

Aktualności, materiały oraz zdjęcia można znaleźć na stronie jarcamp.pl

33rd Degree 2013 – okiem uczestnika

Od 13 do 15 marca miałem przyjemność uczestniczyć w konferencji 33rd Degree. W tym roku była ona zorganizowana w Warszawie – zmiana miejsca spowodowana była problemami ze znalezieniem odpowiednio dużej sali w Krakowie, gdzie 33rd Degree odbywało się rok temu. Nie zmieniło się natomiast jedno – bardzo wysoki poziom merytoryczny prelekcji.

Czytaj dalej

Zdaj OCEWCD – pytanie 11

Co będzie efektem uruchomienia poniższego kodu servletu?

@WebServlet("/Test")
public class TestServlet extends HttpServlet
{
    protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException
    {
        request.getRequestDispatcher("test.jsp").forward(request, response);
    }
}
package eu.javablog.ocewcd;

public class BeanClass
{
    private String text;

    public BeanClass(String text)
    {
        this.text = text;
    }

    public String getText()
    {
        return text;
    }

    public void setText(String text)
    {
        this.text = text;
    }
}
<html>
<head>
    <title>Test Page</title>
</head>
<body>
    <jsp:useBean id="myBean" type="eu.javablog.ocewcd.BeanClass" scope="request">
        <jsp:setProperty name="myBean" property="text" value="DEFAULT" />
    </jsp:useBean>

    <p>${myBean.text}</p>
</body>
</html>

 

  1. Wyświetlony zostanie pusty ciąg znaków.
  2. W trakcie wykonania rzucony zostanie wyjątek.
  3. Kod nie skompiluje się.
  4. Wyświetlony zostanie DEFAULT.
  5. Wyświetlony zostanie null.

 

Pokaż odpowiedź »

Poprawna jest odpowiedź nr 2.

Podchwytliwość tego pytania polega na tym, że dla taga jsp:useBean podaliśmy wartość atrybutu type, a nie class. W takim wypadku, jeśli w podanym scope nie ma wskazanego przez nas atrybutu, bean nie będzie stworzony. Zamiast tego rzucony zostanie wyjątek: java.lang.InstantiationException: bean myBean not found within scope.

Zdaj OCEWCD – pytanie 10

Co się stanie po uruchomieniu kodu poniższego servletu?

@WebServlet("/Test")
public class TestServlet extends HttpServlet
{
    protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException
    {
        request.setAttribute("myBean", new BeanClass("SERVLET"));
        request.getRequestDispatcher("test.jsp").forward(request, response);
    }
}
public class BeanClass
{
    private String text;

    public BeanClass(String text)
    {
        this.text = text;
    }

    public String getText()
    {
        return text;
    }

    public void setText(String text)
    {
        this.text = text;
    }
}
<html>
<head>
    <title>Test Page</title>
</head>
<body>
    <jsp:useBean id="myBean" class="eu.javablog.ocewcd.BeanClass">
        <jsp:setProperty name="myBean" property="text" value="DEFAULT" />
    </jsp:useBean>

    <p>${myBean.text}</p>
</body>
</html>

 

  1. Wydrukowany zostanie wyraz DEFAULT.
  2. Kod nie skompiluje się.
  3. Wydrukowany zostanie wyraz SERVLET.
  4. W trakcie działania rzucony zostanie wyjątek.
  5. Wyświetlony będzie pusty String.

 

Pokaż odpowiedź »

Poprawna jest odpowiedź nr 4.

Powodem rzucenia wyjątku jest fakt, iż tag jsp:useBean będzie próbował stworzyć nowy obiekt typu BeanClass. W tym celu wymaga on jednak bezargumentowego konstruktora, którego ta klasa nie posiada. Mylący w tym pytaniu jest także fakt dodania do obiektu żądania nowego atrybutu w kodzie servletu. Mogłoby się wydawać, że jsp:useBean wykorzysta go, i nie będzie próbował tworzyć nowej instancji. Tak się jednak nie dzieje, ponieważ domyślnym scope’em tego taga jest page scope. Nasz argument znajduje się natomiast w request scope. Do poprawy przykładu wystarczyłoby więc dodanie do naszego jsp:useBean atrybutu scope=”request”, bądź też uzupełnienie klasy BeanClass o bezargumentowy konstruktor.

Wasze prezentacje na JARCampie!

Jak wspominaliśmy już na poprzednim, inauguracyjnym spotkaniu, głównym celem JARCampa jest aktywizacja środowiska skupionego wokół szeroko pojętej Javy. Chcemy stworzyć społeczność swobodnej wymiany wiedzy, doświadczeń, czy przemyśleń. Jeśli chciałabyś/chciałbyś podzielić się czymś z innymi uczestnikami JARCampa, prosimy o maila na adres kontakt@jarcamp.pl. Forma jest w zasadzie dowolna – może być to prezentacja, demonstracja napisanego przez siebie kawałka kodu, czy luźny talk bez żadnych dodatkowych materiałów. Czekamy na Wasze pomysły!

Zapraszamy na JARCamp!

Miło nam Was poinformować, iż już za około miesiąc, 7 grudnia, odbędzie się pierwsze z serii spotkań barcampowych organizowanych przez javablog, o jakże oryginalnej i dźwięcznej nazwie – JARCamp. Dzięki naszemu sponsorowi, firmie Metrosoft, czekać na Was będą przeróżne przekąski i napoje, które, mamy nadzieję, pobudzą i uprzyjemnią dyskusję zgromadzonym osobom. Miejscem spotkania będzie Barka Alrina, która przycumowana jest w przepięknej okolicy, zaraz obok Kładki Ojca Bernatka. Tematem przewodnim będzie rozwój Javy i najciekawsze nowości planowane w ramach jej kolejnego wydania. Bilety kosztują całe 0 zł, ale jest ich tylko 65, więc nie zwlekajcie z zapisami! Po więcej szczegółów, zdjęć, i w celu rejestracji, zapraszamy na oficjalną stronę JARCampa – www.jarcamp.pl.