Lasu 2 String

If (false) may be useful

2011-08-17T19:01:00.000+02:00

Can you be friend with this kind of dead code? In this particular subject my opinion is slightly different from the general. I can agree that in the ideal programming world there is no need to use dead code, but in reality there are situations when it's good to consider this solution as appropriate.

Standard solution (JavaDoc)

As I previously wrote here, JavaDoc is not perfect as well. Of course, if we have a lot of time, our code will look really good. Unfortunately, most of us do not have such amount of time, so we cannot become JavaDoc-Shakespeare if we want to be truly agile.

Another solution (JavaDoc-Code)

At first I used to replace some descriptions in JavaDoc with pure code. It can become handy in many ways. Code is precise so (mostly) there is no need to wander about its meaning - invaluable in multi-language team and not only there. Problem is in its volatility - each refactor including simple variable renaming can bring serious harm to our JavaDoc-Code, also code witch is no code (there is no compiler validation) can contains expressions that are understandable only for the author. Those reasons make this method (more or less) meaninglessness.

Useful !/?

Don't get me wrong this is not the solution that should be used often, however my experience shows that it can be useful. One of such a moment is when we have to reimplement some important method long to a few hundred lines. To make backup always available SVN will be not enough (at least till next generation), as some serious refactor can make it almost useless. Also developers are more minded for applying changes to both dead path and active one, if they find dead code with good explanation, what, of course, is impossible for code in the repository! So basically, if you do not like to tell/force people not to make refactor because you have some important code in repository - consider using dead code.

How! / When?

If you are in such a comfortable situation and your project have test, testers and there is a lot of time between bug and fix, dead code is probably not for you.
But if your project lack some of those things and still after all, you do not want to take it as excuse for your bugs then consider dead code as you temporary friend.

Secret behind 0.999... = 1

2011-03-20T17:13:00.003+01:00

« Polska wersja »

Wikipedia: 0.999...

Searching a solution we often forget about the problem behind it. I'm familiar with the wrong focusing on 'how' instead on 'why', and what's more I've seen people doing the same mistakes as well. For example, let's just look at law regulations as synonym of complication paired with uncleanness. However, I'll drop that subject and introduce the similar problem occurring in maths. Do not expect any great proof, because I'll do that to explain it as simple as possible.

`0.999... = 1`

The proof for the equation above is the above derivation:


      x = 0.999...

    10x = 9.999...

10x - x = 9.999... - 0.999...

     9x = 9

      x = 1

If you are interested on it, you can find more about it on Wiki: 0.999... or at once read quite fine explanation by Cecil Adams. The fact is that he will not going to get Nobel price for that but in real numbers field his explanation is mostly accurate.

I wanted to explain the reason behind it rather than submitting next proof for it. For this purpose I'll introduce the proof that every person earns the same amount of money, of course using the same method as above.


Let's:

  m - best earnings on earth.

  x - earnings some man.

  y - earnings some other man.

We have then:

  x >= 0

  y >= 0

  x <= m

  y <= m



Let's assume:

  x = y

We can divide by nonzero:

  x/2m = y/2m

Let's bring it to integer numbers:

using (x <= m)

  x/2m = 0

using (y <= m)

  y/2m = 0

So we have proved equality:

  0 = 0

Thus, I proved that each of us earns the same amount of money, so it's proved the validity of the communist system.

Explanation

Now, it's high time to end the torment and explain the point. Each of us earns the same amount, 'but' in accuracy to double amount of the best salary possible to be earned. The same thing happens in the case of 0.999 ... = 1. Except the fact that in the latter case the accuracy of the integers is 1, the precision of real numbers is (roughly) 1/∞. So we can safely confirm equality between 0.(9) and 1, 'BUT' with an accuracy of 1/∞, which shows that in the same time there is (roughly) the difference between these two numbers.

Summary

All proves (including those the Wiki) are accurate, but in the same time they do not carry too much sense.

This is how it is

Proper infinity algebra is not used with some fairly simple reasons (in general):

Infinitely small values are 'relatively' meaningless, so for quite a while there was no need to include them in the model.
Algebra with ∞ numbers begins to exhibit vector traits.
The calculation results are interesting only if it is lifted upwards.
Inclusion of infinity in the model is quite tiring.
A few existing formulas would have to be corrected in order to properly fit infinity algebra.

More on...

If somebody wants to make some calculation, he/she may read about surreal numbers, that contain the infinite and infinitesimal numbers (greater than zero but less than any positive real numbers). The mathematical description you can find on wiki as well: 0.999...: Alternative number systems

Przeglądarki kontra bezpieczeństwo

2010-12-21T17:00:00.014+01:00

Czyż Internet Explorer nie służy do przeglądania internetu z twojego komputera i vice versa?

Mogliśmy jakiś czas temu zaobserwować miły gest ze strony Mozilli wspierający osoby które chcą zwiększyć bezpieczeństwo ich produktu (patrz: Refresh of the Mozilla Security Bug Bounty Program). Zaciekawiony tymże faktem poszperałem więcej w poszukiwaniu informacji o bezpieczeństwie naszych przeglądarek...

Ciekawostką jest raport firmy CERT z 2005r (ich pierwszy nawiasem mówiąc) - jednakże jego jakość jest wątpliwa i bardziej tu pasuje nazwa 'zestawienie'. Taki współczynnik jak ( Liczba luk / Popularność ) jest nie tyle nietrafiony co wręcz błędny. Otóż im większa szansa zysku z odkrytej luki tym częściej i szybciej zostanie ona wykorzystana, a w internecie ilość przekłada się przecież w bezpośredni sposób na zysk. Tak więc, moim zdaniem, powinno być raczej ( Liczba luk * Popularność ). Ten sam mechanizm działa też w drugą stronę: firmy mające małą liczbę użytkowników są znacznie mniej podatne na ataki.

Dostępność luki

Ataki hakerów można podzielić na skierowane na konkretny cel oraz na rozproszone (tzw. "kto się złapie"). Jak łatwo się domyślić, atak skierowany na nas może być bardzo przykry w konsekwencjach, tym samym największe znaczenie ma czas, przez który potencjalne luki są odsłonięte na światło dzienne oraz ich 'krytyczność', co ma wpływ na łatwość(dostępność) oraz sensowność ich wykorzystania.

Wtyczki

Kolejnym niezmiernie istotnym czynnikiem wpływającym na bezpieczeństwo są plugin-y. Jeśli bowiem przeglądarka pozwala na ich zainstalowanie, wówczas (nie)bezpieczeństwo dotyczy także i ich, bo nawiasem mówiąc jakiś czas temu jeden z powszechnie dostępnych plugin-ów zawierał dość długo niewykrywalnego wirusa.

Nowości

Problemem dla bezpieczeństwa są wszelkie nowości zwłaszcza te DUŻE, mające podbić rynek. To one praktycznie zawsze oznaczają nowe luki.

W mojej opini

Co Ja na to? Osobiście z wyżej wymienionych powodów używam Opery, a przy tym jest dla mnie potwornie wygodna. Fakt, że przez te kilka lat dwa razy usunęła mi "ulubione" i kilka razy na miesiąc muszę sprawdzić parę 'niedorobionych' stron na Firefox-ie, jest jak najbardziej do zaakceptowania.

Złożoność problemu

Faktem jest, że bezpieczeństwo ze swojej natury jest skomplikowane, wobec tego można tak ustawić wyniki porównań/ rankingów, aby dowolną (no może poza MSIE) przeglądarkę uznać za "najlepszą". Wykorzystywanie tego do promocji produktów powoduje znaczne ograniczenie bezpieczeństwa mniej obeznanych użytkowników.

Także w temacie

Swoją drogą polecam zapoznanie się także z zestawieniem w formie wykresu.
Porównanie (test) IE, Firefox, Chrome, Opera, czy Safari?, nie koncentruje się na bezpieczeństwie, ale też jest wart naszej uwagi.
Google również wie jak zrobić dobry użytek z umiejętności 'hakerów'.

Informatyk zawodem wysokiego ryzyka?

2010-07-16T23:45:00.008+02:00

Kolejny post dotyczący naszego Polskiego "zaścianka". A mianowicie chciałbym napomknąć jak wygląda egzystencja nas informatyków w kontekście przepisów prawnych oraz strachu przed naszymi umiejętnościami.

Wiedza, którą dysponujemy, pozwala nam patrzeć na systemy które używamy z zupełnie innej perspektywy, odkrywać ich błędy nawet bez zbytniego zaangażowania się w to. I co, niestety, smuci wytknięcie komuś błędu może wiele nas kosztować.

Na wstępie muszę zaznaczyć, że specem w kwestiach prawnych nie jestem. Tak więc nie będę się skupiał na tychże kwestiach w kontekście paragrafów.

Świat

Gdy słyszy się, że 'hacker' korzystając z serwisu znalazł poważną lukę bezpieczeństwa, a w nagrodę za powiadomienie właściciela o tym dostał jakiś śmieszny wyrok typu 600 lat pozbawienia wolności to człowiek zastanawia się czy w tej Ameryce jest tak dobrze jak to próbują nam wmówić? A przecież nawet w przypadkach, gdy użyto wiedzy tylko po to, aby pomóc uszczelnić zabezpieczenia, zakończenie często było takie samo. I przynajmniej mi taka sytuacja kojarzy się z inkwizycją. Tak jak kiedyś palono na stosie tych, których się obawiano, tak i teraz zagadnienia informatyczne są postrzegane jako swoista magia oraz budzą lęk i przerażenie.

Z drugiej jednak strony słyszymy o ujawnianiu wad oprogramowania jak choćby ostatnia sprawa z Windowsem XP, jednak nikt o żadnym procesie nie mówi.

Wszystkie te sytuacje dla kogoś nie obeznanego z prawem zapewne wyglądają dość dziwacznie, w tym także dla mnie. Być może jest to spowodowane różnicowaniem zabezpieczeń serwisów/portali i zwykłych programów.

Polska

Z mniej bądź lepiej znanych mi przypadków dotyczących bezpieczeństwa muszę przyznać, że jest dosłownie rÓŻNie. Choć patrząc na to z przymrużeniem oka zaściankiem pod tym względem nie wydajemy się być. Tu sporo na gorsze mogą zmienić ostatnie nowelizacje prawa, ale to już sprawa do dalszego zbadania. Tak czy siak prace społeczne za wytknięcie błędów w serwisie dadzą się przełknąć.

Doświadczenia

Administrując siecią posiadającą kilkuset użytkowników zaobserwowałem grupę "wykształconych", którzy robią co chcą, będąc ufnymi w swoją zarąbistość. Jednak pewnego słonecznego dnia przychodzi szara rzeczywistość i wtedy nawet genialny pomysł typu: skrypt zmieniający regularnie mac-a na niewiele się zdaje. Wielu z nich już się boleśnie przekonało, w tym także na moich oczach, że Wielki Brat patrzy a coś takiego jak anonimowość w internecie nie istnieje.
Pracując w sieci zapominamy, że nasze poczynania można praktycznie w 100% namierzyć, inna kwestia czy to się opłaca. Kluczowym pytaniem jest więc: "Komu się zaszło za skórę?", oraz jak bardzo ten ktoś jest zdeterminowany aby złapać nas na gorącym uczynku.
Nagradzanie ludzi z zewnątrz za informację o błędzie też można spotkać i z moich obserwacji wynika, że firmy mogą dużo na tym wygrać.
Na pewno niewyobrażalne straty firma 'może' ponieść w wyniku podejścia typu "my wiemy lepiej" bądź też "z hakerami się nie negocjuje", a sprawa jest dużo bardziej skomplikowana niż to się może wydawać na pierwszy rzut oka. Więc jest szansa, że doczeka się osobnego postu.
O innych ciekawych przypadkach z życia wziętych, przeczytasz na: Hacking.pl

Rada z mojej strony

Jeśli już znajdziemy jakąś lukę w obcym nam systemie, to:

Nie możemy oferować odpłatnego jej załatania. Dzieje się to dlatego, iż jako potencjalni hackerzy możemy chcieć uzyskać dostęp do kodu w celu dalszej penetracji systemu, a w interesie firmy leży zadbanie aby sprawa nie przybrała takiego rozwojowi wypadków.
Pozostawienie sprawy samej sobie może okazać się poważnym błędem. Bo problem może wypłynąć a my zostaniemy kozłem ofiarnym (logi mogą okazać się trwalsze od naszej sklerozy).
W zależności od metody odkrycia luki można rozważyć złożenie zawiadomienia o przestępstwie na mocy ustawy o ochronie danych osobowych, gdyż o zgrozo atak może okazać się jedyną formą obrony. Tu jednak lepiej zasięgnąć porady prawnej i to wyjątkowo dobrej, nie zapominajmy w końcu, że niektóre bronie są obosieczne.

Przyszłość

Trudno jest przewidzieć, w którą stronę pójdzie kwestia bezpieczeństwa, na pewno niezaprzeczalny wpływ na to mają ustawodawcy. A możliwe ścieżki zarysowują się:

Strach : Przepisy pójdą w stronę karania za nie upoważniony dostęp do danych nie zależnie od powodów. Taka postawa może spowodować zatajanie luk w bezpieczeństwie w efekcie czego usłyszymy o kilkulatkach forsujących zabezpieczenia korporacji.
Równowaga : Przepisy nie będą tak restrykcyjne a od czasu do czasu spotkamy się z zaniżonymi bądź zawyżonymi wyrokami.
Nacisk : Możliwości testowania zabezpieczeń zostaną oficjalnie otwarte, co nie ma szansy zaistnienia bez wyraźnego sprecyzowania jaką korzyść testujący z tego tytułu otrzyma oraz jakie są jego obowiązki (np. odpowiednio wczesne powiadomienie właściciela). Na pewno zwiększyłoby to liczbę specjalistów od bezpieczeństwa jak i ich fachowość. Z drugiej strony uszczupliłoby zasoby finansowe firm.

Materiały:

Dla zainteresowanych bardziej fachowa lektura (komentarze też warte uwagi)

PS. A jak wy się zapatrujecie na kwestie prawne w naszych zawodach?

Javarsovia 2010 z drugiej ręki

2010-07-13T19:10:00.003+02:00

Odczucia

Z niecierpliwością czekam na następną Javarsovie, co moim zdaniem samo z siebie świadczy o tym jak bardzo byłem zadowolony z uczestnictwa.
Afterparty także pobiło moje oczekiwania, tylko prelegentów na niej trochę brakowało.
Dodatkowo byłem pod wrażeniem liczby uczestników.
Na pewno niewybaczalnym jest fakt, że nie wygrałem Asusa .
Tak wiele się działo, że brakowało mi czasu, aby dokładnie zapoznać się ze stoiskami sponsorów.

Prezentacje

» Jak zapobiegać biodegradacji kodu «
by Jakub Nabrdalik

Temat nie był zbyt rozległy, ale ciekawie i kompleksowo omówiony.
Dodatkowo przykłady były jak najbardziej trafne.
Sam mam za sobą refaktoryzacje na tyle skomplikowane, że potrzebowałem na nie do 2 tygodni wraz z budową specjalnych narzędzi aby w ogóle były możliwe, efektem czego było skrócenie czasu wprowadzenia zmian z jednego dnia i więcej do maksymalnie kilku godzin i to bez nerwowego zastanawiania się jaki efekt nasza praca przyniesie. Więc choć przedmiot prezentacji wydaje się być błahy to nie zmienia to faktu jak duży wpływ ma nasze podejście do programowania na dalszą jakość pracy z projektem.

» Jak można zarobić na uczciwości, przejrzystości i szacunku do klienta «
» kontrakty agile w praktyce «
by Wojciech Seliga

Naprawdę miło usłyszeć jak ludzie potrafią się wybić nie działając na szkodę lub kosztem klienta. Z drugiej zaś strony możemy zaobserwować jakie konsekwencje przynosi odwrotne podejście: "W jaki sposób dożywotnio zarabiać na oprogramowaniu?"
Do samej prezentacji nie mam żadnych zastrzeżeń. Prowadzący wiedział o czym mówi, a temat jest niewątpliwie warty poszerzenia.

» Performance Considerations in Concurrent Garbage-Collected Systems «
by Gil Tene

I was really impressed by the quality of this presentation along with the amount of given informations.
What a pity that there was no time for more complicated questions.

» Projekt Voldemort: gdy relacyjna baza danych to za mało (zbyt wiele?) «
by Tomasz Nurkiewicz

Ciekawe i potrzebne rozwiązanie, może tylko nie potrzebnie było pokazane jak uzyskać prezentowane efekty, choć nie którym właśnie to przypadło do gustu.

» Windows Azure - Cloud Computing, co to, po co i dla kogo? «
by Tomasz Kopacz

Wiele funkcji zostało tu przedstawionych, ale jak dla mnie zbyt wiele. Dlatego nawet pomimo, iż zauważyłem niewątpliwe zalety proponowanych rozwiązań to postrzegam je jako "Spaghetti Monster" i osobiście bałbym się w to wchodzić.

» Oracle Coherence - wprowadzenie poprzez przykłady «
by Waldemar Kot

Ciągle mam wrażenie, że ta prezentacja powinna trwać minimum 3h, aby pokryć zapotrzebowanie na omawiany temat, zwłaszcza, że zawsze można liczyć na kompetentną odpowiedz od Waldka, o ile jest na to czas.

» Software Craftsmanship - Język wzorców językiem profesjonalistów «
by Sławek Sobótka

Na moje szczęście mogę wcześniej zapoznawać się z prezentacjami/przekonaniami Sławka, na tej podstawie przypuszczam, że i ta prezentacja cieszyła się odpowiednim uznaniem.

» Pozostałe «
by Inni prelegenci

Tu potrzeba jedynie poczekać na udostępnienie nagrań i materiałów.

GUI in GridBagLayout

2010-07-12T23:12:00.005+02:00

Basically, I do not like GridBagLayaout, but from my point of view it's the most effective way to build and maintain GUI. So before explaining my point of view, let's eliminate other path.

Graphical editor :

Alternative for writing a code is a creating GUI through a graphical editor, like the one in NetBeans. The effect obtained in this way is good, but it brings few problems as well:

Editor may lock GUI code.
Too many changes might:
- Mess the code,
- Force us to create GUI once again,
- Remove some important part of code,
Mostly we are not able to move GUI code to other IDE freely.

For me, reasons for 'no' have been unacceptable.

GUI as code & GridConstraintsBuilder:

Let's back to GridBagLayout. The greatest obstacle in using this layout in a code form is GridBagConstraint. Wasting line for each property does not make it readable at all, especially when we have to realign GUI with more than 10 elements. Folding its construction to multi parameter util-method does not make it really easy to handle especially for newbie.
Because of this reasons GridBagConstraint was rewritten to the builder form. For me, this way allows to keep a correct proportion between code's readability and its size. So there is no need to stuck on code analysing to make a small change.

One of the most important part of the new code is its integration with the existing one, because no one will allow himself to manage new and old ways. .printAsJavaCode$(...) method was created to make this inequality to be possible to happen:
$time{conversion code to new form} + $time{work on new-like code} <= $time{work on old-like code}

Main problems:

Conversion to Java code is not able to determine if value is provided by constant or by variable. This makes some additional checking as required along with the conversion.
There is no interface for constrain, so passing builder to component may happen.
Rich methods' set has its disadvantages as well. On the one hand, we can easily pass interesting arguments, but in this way, we lose a lot of highlightings.

Builder:

Sample of usage:
JFrame frame = new JFrame(); JPanel panel = new JPanel(new GridBagLayout()); frame.setContentPane(panel); GridConstraintsBuilder base = GridConstraintsBuilder.newOnCenter()// .setYAsRelative().setVerMarginY(2, 0, 4); GridConstraintsBuilder labels = base.clone(); GridConstraintsBuilder fields = base.clone(); labels.setAlignAsToRight()// .setX(1).setHorMarginX(5, 0, 10); fields.setAlignAsToLeft()// .setX(3).setHorMarginX(5, 0, 5); for (String text : new String[] { "Some", "One", "And other" }) { panel.add(new JLabel(text), labels.build()); panel.add(new JTextField(text), fields.build()); } frame.setSize(300, 200); frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE); frame.setVisible(true);
Sample of conversion of GridBagLayoutDemo.java :
At first we can convert constraints to Java using:
... pane.add(button, GridConstraintsBuilder.printJavaCode$(c)); ...
Execution of such a code would produce:
GridConstraintsBuilder.newOnCenter(0,0)// .fillHorizontal().provide() ; GridConstraintsBuilder.newOnCenter(1,0).setWeight(0.5,0.0)// .fillHorizontal().provide() ; GridConstraintsBuilder.newOnCenter(2,0).setWeight(0.5,0.0)// .fillHorizontal().provide() ; GridConstraintsBuilder.newOnCenter(0,1).setSize(3,1)// .fillHorizontal().setInternalPadding(0,40).provide() ; GridConstraintsBuilder.newOnPageEnd(1,2).setSize(2,1).setWeight(0.0,1.0)// .fillHorizontal().setInsets(0,10,0,0).provide() ;
So after including 'shouldFill' and 'shouldWeightX' the final code would look like:
GridConstraintsBuilder button1 = GridConstraintsBuilder.newCenter(0, 0)// .fillHorizontal(); if (shouldWeightX) button1.setWeightX(0.5); pane.add(new JButton("Button 1"), button1.build()); pane.add(new JButton("Button 2"), GridConstraintsBuilder// .newCenter(1, 0).setWeight(0.5, 0.0)// .fillHorizontal().build()); pane.add(new JButton("Button 3"), GridConstraintsBuilder// .newCenter(2, 0).setWeight(0.5, 0.0)// .fillHorizontal().build()); pane.add(new JButton("Long-Named Button 4"), GridConstraintsBuilder// .newCenter(0, 1).setSize(3, 1)// .fillHorizontal().setInternalPadding(0, 40).build()); pane.add(new JButton("5"), GridConstraintsBuilder// .newPageEnd(1, 2).setSize(2, 1).setWeight(0.0, 1.0)// .fillHorizontal().setInsets(0, 10, 0, 0).build());

Resources:

GridConstraintsBuilder code
Menadżerowie ułożenia.pdf

Forwarding exceptions as language potential

2010-02-20T22:04:00.005+01:00

Each of Java programmer knows how exhausting a handing exception can be. So sooner on later he/she founds the situation when he/she exactly knows that he/she is handling the exception that will never occur. Some thoughts about this can be found here.

Negative consequences

What are negative consequences of obligation to handle the checked exception:

They are omitted in order to simplify code (use only unchecked exceptions or catch and ignore checked exceptions).
A few exceptions are exchanged in one. This is considered as a good style, but mostly I don't think about it in this way.
There are lots of cases when we know that exception will not occur, but we cannot simply left catch block blank, because it can be changed in future.

At first, I wanted to handle it by generics, but tracking such a code might be almost impossible, however, at the end, in mostly cases, it may make code complication increased. Someday in the future, I'll try to describe the matter of generic exception.

What do we have today?

Quite interesting is the fact that Java allows to omit checked exceptions that have no chance to occur - what is widely used in practice. Let's see, how this works right by using the classes similar to java.lang.Appendable & java.lang.StringBuilder.
As the base, let's declare interface:

public interface Appendable {


    Appendable append(CharSequence csq)
     throws ParamaterException;


}

Let's consider the class that uses this interface:

public class StringBuilder implements Appendable {


    private  String string = "";


    public Appendable append(CharSequence csq){

    string += csq;

    return this;

    }


}

Using StringBuilder class directly through its interface ( Appendable ) we have to handle the exception:

static{

    Appendable stringBuilder = new StringBuilder();

    stringBuilder.append("");

}

Let's use direct implementation StringBuilder class. Now we do not have to handle that exception.

static{

    StringBuilder stringBuilder = new StringBuilder();

    stringBuilder.append("");

}

Let's consider more complicated example:


public class Sample {




    private Data data;



    Appendable appendTo(Appendable appendable) throws ParamaterException, ObjectException {

        if (data == null) throw new ObjectException();

        appendable.append(this.getClass().getSimpleName());

        return appendable;

    }

}

So as you can see one exception ( ObjectException ) comes from a called object, second one ( ParamaterException ) comes from a method parameter ( appendable ).
Let's modify the method signature in order to allow the complier to know where each exception comes from.
Let's modify semantics to express that:


public class Sample {




    private Data data;



    Appendable appendTo(Appendable appendable throws ParamaterException) throws ObjectException {

        // Both exception are thrown just ParamaterException is thrown/forwarded only if it occurs by calling 'appendable'.

        if (data == null) throw new ObjectException();

        appendable.append(this.getClass().getSimpleName());

        return appendable;

    }

}

Let's assume that placing the throw declaration right after input parameter means that the exception can be thrown only by the calling given parameter.

So in this way, the compiler can determine if the exception can be thrown by the known given parameter type or not

static{

    new Sample().appendTo(new StringBuilder()); // Compiler is able to determine that ParamaterException will do not occur here.

}

The above mentioned way to handle exception in language is a quite simple to understand and introduce. However, it's just a tip of the iceberg. If sometimes we have a nice way to handle exception flow in a this way of solving, this will have to be extended what can bring some problems in a few other aspects, however, it's not now time to bring it up.

At the end, I would like to mention that I'm just afraid that most programmers will not be able to comprehend the exceptions and the application flow in the same time.

The '!' logical-complement operator (fixed)

2010-02-14T02:32:00.007+01:00

It's high time to clear doubts about: The '!' logical-complement operator. With little help of someone who can express himself more clearly, subject should be easier to follow.

Some time ago I used to know all operators priorities in C++, using a minimal number of braces resulted with a quite compact code in logical cases. It was really easy to read that again, but only for me, what I did not see as a problem. When I started to work on the same code with others there were no turn back and I had to make conditions more readable...

Languages and braces

Analysing expression with braces requires to locate them as matching pairs, what takes more effort than a simple sequent reading like I used to do before. But the real breakthrough happened when I had to work on two totally different languages in the same time. Since then, big difference in semantics and operator priorities has changed a lot the way I'm wring code now. If someone has doubts whether a similar situation can happen or not, let's consider quite simple expression like: '2+2*2', what gives '6' in Java and '8' in MUMPS . So finally, I ended using a few braces. When is it essential to use braces?
I suggest doing it in order:

not to care about operator priorities
to prevent situation when modification can have impact on current expression meaning

Practise

Notice that adding braces, when it's necessary, might effect in a hard to analyse code, like having 3 and more closing bracket in a row, what's really confusing. Study this example to see how above rules apply:
Let's assume we have some variables:

boolean main = ...;


boolean current = ...;


boolean additional = ...;

And now code:

if ( main == !current )

becomes improper. Why? Because when we modify it and add something like this:

if ( main == !current && additional )

the code looks a little bit unclear. Why? It happens because we are not sure if negation applies only to variable 'current' or for a whole expression 'current && additional'. In order to prevent from such situation we will apply above rules for using braces. Our expression will be transformed into this:

if ( main == (!current) )

Does this look a little awkward? However, when we look closer at those three expressions below, 2nd and 3rd ones are totally clear, no matter what formatting is used. What's more a modification of our 'if' is easier because it does not require so much cursor travel (to add bracket).
1.

if ( main == !current  && additional )

if ( main == ! current&&additional )

if ( main == (!current)  && additional )

if ( main == (! current)&&additional )

if ( main == (!(current  && additional)) )

if ( main == (! (current&&additional)) )

So let's see how useful it will be when we exchange 'current' with little wider XML-like expression chain:

data.getAccountData().getUnit().getContract().isOpen()

we get 'if' looking like:

if (main == data.getAccountData().getUnit().getContract().isOpen() && additional)

Now if we want to negate isOpen() part in this expression, we write something like this:

if (main == (!data.getAccountData().getUnit().getContract().isOpen()) && additional)

while I would suggest:

if (main == data.getAccountData().getUnit().getContract().!isOpen() && additional)

instanceof operator

The next example is instanceof operator and it's negation. Now, in order to negate instanceof we must write:

if (!(obj instanceof Person)){...}

While I would suggest:

if (obj !instanceof Person){...}

Of course those examples require a few analysis, as a behaviour for null-s. But it's not a big deal in this case.

Work around:

We can generate isOpen() as well as isNotOpen() instead of one method in that case. But it is rather a naive solution - isNotOpen() version in most cases calls traditional isOpen() with simple negation, what increases stack trace. Another problem could also occur during a code fixing, because someone could repair only one method (if both would contains implementations).

The logical-complement operator !

2009-12-18T22:22:00.006+01:00

Maybe I'm weird but I really do not like syntax for this operator.

Now time it's like:


  if (!person.getThinkingModel().isThinking()){...}

I would personally prefer:


  if (person.getThinkingModel().!isThinking()){...}

I would do same about instanceof to allow:


  if (obj !instanceof Person){...}

Work around:
Would be nice to see both methods generated isThinking() as well as isNotThinking() instead of one in that case. Problem in this solutions involve setters which should be duplicated as well, and mostly 'Not' version should call traditional with simple negation, which increases stack traces.


  if (person.getThinkingModel().isNotThinking()){...}

This way have one more advantage. When you write in more than one language you can worry less about operators priority.

Use yours own judgement, which is easier to read and write.

Little confusion about Generics

2009-10-15T22:22:00.008+02:00

Lets consider some class used for collecting References. It requires little work but there is way to do not determine Reference type to early. So lets observe consequences of this action.


import java.lang.ref.Reference;

import java.lang.ref.WeakReference;



/**

 * Collects {@link Reference}-s

 */

public class ReferenceCollector<Ref extends Reference</* ? extends
*/ Type>, Type>

    implements Iterable<Reference<? extends Type>> { ... 
}

This class will allow given code to compile:

ReferenceCollector<WeakReference<String>, ?> rc1 = null;

ReferenceCollector<WeakReference<String>, ? extends Object> rc2 = null;

On the other hand reversing Type arguments will be not allowed:

ReferenceCollector<WeakReference<? extends Object>, String> rc2 = null;

This mean that nesting is count more then arguments order, what more it's all about compatibility not as I would expect equality of types. Probably I just need read rest of JLS when I'll have free time to get idea why '?' is allowed as second generic argument.

I just killed Eclipse

2009-10-04T11:51:00.008+02:00

I like enum-s more than most people do.

They are really nice to use and synchronization-safe. But as I found, they have their limits as well.

After generating 1,8Mb Java code for one enum Eclipse dying after most try of refactorization ;), Java was not happy at all about it as well with error:

The code for the static initializer is exceeding the 65535 bytes limit

I already saw bug about it 4262078. I just had no idea that I'll ever reach that huge amount of code in one 'function'.

Lets see what we need deal with!

We need to store almost 1000 elements.
Each element have up to 30 attributes.
Constructor signature look like:

private Element(int section, int code, String name , Pair<ItemAttributes, Object>... attributes) { ... }

Step 1:
Less see how many entries can we have...
Java start to work when file size get down to 380Kb and number of elements was around 130.

Step 2:
Adding magic code...

public class PIA extends Pair<ItemAttributes, Object>{



  public PIA(ItemAttributes key, Object value) {

    super(key, value);

  }



}

Replacing 'Pair<ItemAttributes, Object>' with PIA reduced class size to 1Mb.

Step 3:
More magic code...
renaming ItemAttributes to IA reduced code size to 700Kb, and still not enough.

Step 4:
More magic code...
After simplifying constructor to

private Element(int section, int code, String name, Object[]... attributes) { ... }

source code take 450Kb

Last step
Undo all changes and split elements into enum-s similar with sections.

Enhanced while statement proposal

2009-03-30T01:23:00.007+02:00

OVERVIEW

FEATURE SUMMARY:
Enhanced while statement allow to iterate through iterator.

MAJOR ADVANTAGE:
People will stop working around for-each loop.

MAJOR BENEFIT(s):
Allow to easy express operation on iterator(s), and iterating over non linear Iterators.

MAJOR DISADVANTAGE:
Automatic loop over Iterator my be problem for some peoples.

ALTERNATIVES:
Using while loop.

EXAMPLES

SIMPLE EXAMPLE:

  String toString(Iterator<String> list){

    if (!list.hasNext()) return "[]";

    StringBuilder ret = new StringBuilder();

    ret.append('[').append(list.next());

    while (String string : list) {

      ret.append(',').append(list.next());  

    }

    return ret.append(']').toString();

  }

ADVANCED EXAMPLE:

  String toString(Iterator<Transfer> list){

    while (Transfer t : list) {

      ArrayList<Data> data = new ArrayList<Data>();

      if ( t.isOpeningTag() )

        while (Transfer t : list){

          if (t.isClosingTag()) break;

          data.add(t.getData());

        }

      else {

        list.remove(); // OK: no interactions

        throw new Exception("...");

        }

      list.remove(); // warning list here can refer to last element of inner loop

      // Process chunk 

    }

    

  }

DETAILS

SPECIFICATION:
Same as JLS 14.14.2, except:

The Expression must either have type Iterator, or a compile-time error occurs.
Let I be the type of the expression Expression

If Expression is directly field or variable or parameter (ExpressionVariable) then additional checking is performed:
If Variable is used as Expression for while-each loop inside while-each loop over same Variable then Variable occurring after inner while-each loop (but in outer while-each loop) will compile with warning “Variable state refer to inner loop”.

COMPILATION:
Same as for-each (almost).

TESTING:
Same as while loops.

LIBRARY SUPPORT:
None.

REFLECTIVE APIS:
No.

OTHER CHANGES:
No.

MIGRATION:
None.

COMPATIBILITY

Except code, which is only forward compatibility.

REFERENCES

Enhanced for each loop iteration control

'forget' keyword proposal

2009-03-27T07:05:00.010+01:00

OVERVIEW

FEATURE SUMMARY:
'forget' keyword allows to erase variable from current context, or it means that field should not be used.

MAJOR ADVANTAGE:
This change makes language be more WYSIWYG.

MAJOR BENEFIT(s):

It makes people be able to erase 'variable' from current context, while now it's:
- impossible for final variables (only by comments),
- impossible for arguments (for not final Object we can assign null),
- impossible for fields.
- local fields need more or 'less' artificial blocks (two lines wasted and one indent level).
Declaring that variable should not be used, or does not contain valid information for this scope (at current time) will be possible.
Code quality does not fall so drastically after we leave it, comparing to '=null', 'only comments' or 'weird blocks'.

MAJOR DISADVANTAGE:
New keyword == Someone can have declared method/field/variable named 'forget'.

ALTERNATIVES:
It's already listed.

EXAMPLES

SIMPLE / ADVANCED EXAMPLE(s):

  public static void main(final String[] args) {

    System.out.println(Arrays.toString(args));

    forget args; // 'args' cannot be used anymore

    String[] args;  // Error: Duplicate local variable args

   ...

  }

public class Forget {



  private ArrayList<String> criticKeys;

  

  public void addKey(String newKey){

    forget this.criticKeys; // use synchronized method ONLY

    ... // validate 

    ... // add

  }

  

}

  public static void main(final String[] arguments) {

    int sum = 0;

    for (String s : arguments) {

      sum += Integer.parseInt(s); 

      System.out.println(sum);

      forget s; // OK

      forget args; // OK: arguments variable is final

      forget sum; // Error: cannot erase variable it it will still can be used

    }

    System.out.println(arguments.length); // Error: erased context

  }

DETAILS

SPECIFICATION:
forget VariableIdentifier;
or
forget this. FieldIdentifier;

Forbid using given identifier in all followed expressions, in all blocks in which variable could be used in current method scope.

If variable is not final then forget expression cannot occurs in loop block if variable was declared in wider block, it's because variable should not be forgotten if it will be used again.

If field is not final than forget expression cannot occurs in any loop block.

COMPILATION:
Variable is not erased (but it can be, if it's not field), it's just protected from access that should not happen for any reason. What's more, handling variable, as if it still exists, prevents a situation when a programmer creates new variable with the same name and then removes forget statement.

TESTING:
It's the same as testing effects of exiting from the block for variables. For fields, it's just an access control.

LIBRARY SUPPORT:
None.

REFLECTIVE APIS:
None.

OTHER CHANGES:
None.

MIGRATION:
None.

COMPATIBILITY

New keyword can be problem. There is not other impact.

REFERENCES

'final' without explicit type proposal

2009-03-26T20:44:00.008+01:00

OVERVIEW

FEATURE SUMMARY:

MAJOR ADVANTAGE:
It allows people to concentrate on logic during operating on heavy generics and to use values which are more intuitive for them than variables.

MAJOR BENEFIT(s):

It allows to avoid duplicating unnecessarily types of declaration.
It increase a concentration on 'what I've got' than on 'what type is that' (we decrease size by one to obtain last element index, not because we can do this = it's int), while for variables we still keep concentrate on: 'what type is that' / 'what I can put there'.
Editing existing code to get some value from method chain is easier.
That method can be itself multi-thread with this, but it's a far future.
Using of Generics is easier.

MAJOR DISADVANTAGE:

Certainly, some people will overuse this solution.
Consider operator is easier to read.
It might be a problem if a person does not know how to give proper names for values.

ALTERNATIVES:
Normal variables.

EXAMPLES

SIMPLE / ADVANCED EXAMPLE:

  public Map<String,ArrayList<String>> readMaping(){

    final map = new HashMap<String,ArrayList<String>>();

    for( final row : readLine() ){

      String key = row.get(0);

      row.remove(0);

      map.put(key, row);

    }

    return map;

  }

  public Map<String,ArrayList<String>> readMaping(){

    final map; //compile time error

    map= new HashMap<String,ArrayList<String>>();

    for( final row : readLine() ){

      String key = row.get(0);

      row.remove(0);

      map.put(key, row);

    }

    return map;

  }

public class Final {  

  static final maping = new HashMap<String, ArrayList<String>>();

}

public class Final {

  static final maping = (Map<String,ArrayList<String>>)loadMap();

}

DETAILS

SPECIFICATION: FieldDeclaration
FieldDeclaration would be extended to allow omitting Type declaration if field is final and it's directly followed by assignment of new class instance creation(created object type would be used), or by Anonymous Constructors (JLS 15.9.5.1 )(direct superclass S would be used), or Enum constants preceded by EnumType (JLS 8.9) (Enum type would be used), or CastExpression (JLS 15.16) (ReferenceType would be used).

SPECIFICATION: LocalVariableDeclarationStatement
(JLS 14.4) Local Variable Declaration Statements would be extended to allow omitting Type declaration if field is final and listed rules taking place:

VariableInitializer appears.
Variable is not initialized directly with null (this can be discussed).
VariableInitializer type is neither primitive nor Object.
- primitive : they should not be mixed with Object-s to easy.
- Object : when object type is Object, we mostly deal with situation 'Unknown type', so this should not be hidden.
If VariableInitializer -Expression type is intersection type (we always omit Object type in intersection), then:
- If intersected types have common ancestor then this ancestor is used as type.
- If effect of intersected types is one Interface, then this interface is used as type.
- In other way, an error occurs.

COMPILATION:
Just as today, value type only need to be determined.

TESTING:
The same as final-s variables.

LIBRARY SUPPORT:
No.

REFLECTIVE APIS:
No.

OTHER CHANGES:
No.

MIGRATION:
None.

COMPATIBILITY

Only code is no forward compatible.

REFERENCES

Glue classes proposal 0.9

2009-03-20T15:02:00.007+01:00

OVERVIEW

FEATURE SUMMARY:

Glue classes allow to link utils direct with objects.

MAJOR ADVANTAGE:

Forgotten functionality can be not such big deal now.

MAJOR BENEFIT(s):

New functions can be easy localized (critically important while introduce new peoples into project).
Security: glue class do not see anything protected.
Light binding new functions with existing classes.
Number of used classes reduction.
Allow to assign methods and functions(static methods) to arrays, classes, interfaces, …
It's proof against same method occurs in class and delegator as well like in two delegators.
Allow to link gained(.jar) logic with new one, witch is impossible before final developer implements his classes.
Allow to project compact interfaces and do not worry about additional logic.

MAJOR DISADVANTAGE:
Do not know any ;) sorry.

ALTERNATIVES:
Utils classes, more work on project, duplicated code...

EXAMPLES

SIMPLE EXAMPLE:

Now time:

public class base {



  public static <T> T[] flatten(T[][] this) {

    int length = 0;

    for (T[] subArray : this) {

      length += subArray.length;

    }

    T[] ret = (T[]) Array.newInstance(this.getClass().getComponentType().getComponentType(), length);

    int pos = 0;

    for (T[] subArray : this) {

      System.arraycopy(subArray, 0, ret, pos, subArray.length);

      pos += subArray.length;

    }

    return ret;

  }



}

Now time(usage):

  public static void main(String[] args) {

    Integer[][] array = new Integer[][] { { 1, 2, 3, 4 }, { 5, 6, 7 }, {}, { 9, 0 } };

    System.out.println(Arrays.toString(base.flatten(array)));

  }

Glue:

public class base<T> glue( T[][] ) {



  public glue T[] flatten( this) {

    int length = 0;

    for (T[] subArray : this) {

      length += subArray.length;

    }

    T[] ret = (T[]) Array.newInstance(this.getClass().getComponentType().getComponentType(), length);

    int pos = 0;

    for (T[] subArray : this) {

      System.arraycopy(subArray, 0, ret, pos, subArray.length);

      pos += subArray.length;

    }

    return ret;

  }



}

Glue(usage):

  public static void main(String[] args) {

    Integer[][] array = new Integer[][] { { 1, 2, 3, 4 }, { 5, 6, 7 }, {}, { 9, 0 } };

    System.out.println(array..flatten()..toString());

  }

ADVANCED EXAMPLE:

Now time:

public class base {



  public static <T> int addAll( ArrayList<T> this, Iterator<? extends T> iterator) {

    int added = 0;

    while (iterator.hasNext()) {

      added += this.add(iterator.next()) ? 1 : 0;

    }

    return added;

  }



  public static <T, E extends T> int addAll(ArrayList<T> this, E[] elements) {

    int added = 0;

    for (T t : elements) {

      added += this.add(t) ? 1 : 0;

    }

    return added;

  }



}

Now time(usage):

  public static void main(String[] args) {

    Integer[] add = new Integer[] { 1, 2, 34, 2, 5, };

    ArrayList<Integer> arrayList = new ArrayList<Integer>();

    ArrayList<Integer> finall = new ArrayList<Integer>();

    

    base.addAll(arrayList, add);

    base.addAll(finall, add);

    base.addAll(finall,arrayList.iterator());

    

    System.out.println(finall);

  }

Glue:

public class base<T> glue( ArrayList<T> ){



  public glue int addAll( this, Iterator<? extends T> iterator) {

    int added = 0;

    while (iterator.hasNext()) {

      added += this.add(iterator.next()) ? 1 : 0;

    }

    return added;

  }



  public glue <E extends T> int addAll( this, E[] elements) {

    int added = 0;

    for (T t : elements) {

      added += this.add(t) ? 1 : 0;

    }

    return added;

  }



}

Glue(usage):

  public static void main(String[] args) {

    Integer[] add = new Integer[] { 1, 2, 34, 2, 5, };

    ArrayList<Integer> arrayList = new ArrayList<Integer>();

    ArrayList<Integer> finall = new ArrayList<Integer>();


    arrayList..addAll(add);

    finall..addAll(add);

    finall..addAll(arrayList.iterator());


    System.out.println(finall);

  }

Glue second:

public class base glue( Date )

{

  private static final SimpleDateFormat  sdf  = new SimpleDateFormat("yyyy.MM.dd");


  public glue String format( this ) {

    synchronized (sdf) {

      return sdf.format(this);

    }

  }


  private static final Date  applicationStart  = new Date();


  public static glue Date applicationStart() {

    return applicationStart;

  }

}

Glue second(usage):

  public static void main(String[] args) {

    System.out.println(Date..applicationStart()..format());

  }

DETAILS

SPECIFICATION:
JLS 8.8:
ClassDeclaration:
  NormalClassDeclaration
  GlueClassDeclaration
  EnumDeclaration

GlueClassDeclaration
  ClassModifiers_opt class Identifier TypeParameters_opt glue ( GlueFormalParameter ) GlueClassBody

GlueFormalParameter
  VariableModifiers Type

GlueClassBody:
  { GlueClassBodyDeclarations_opt }

GlueClassBodyDeclarations:
  GlueClassBodyDeclaration
  GlueClassBodyDeclarations GlueClassBodyDeclaration

GlueClassBodyDeclaration:
  GlueClassMemberDeclaration
  StaticInitializer

GlueClassMemberDeclaration:
  FieldDeclaration
  StaticMethodDeclaration
  GlueMethodDeclaration
  StaticClassDeclaration
  InterfaceDeclaration
  ;

GlueMethodDeclaration:
  GlueMethodHeader MethodBody

GlueMethodHeader:
  MethodModifiers_opt glue TypeParameters*_opt ResultType GlueMethodDeclarator Throws_opt

GlueMethodDeclarator:
  Identifier ( this,_*opt FormalParameterList_opt )

*opt: 'this' occurs always and only if glue method is not static.

TypeParameters from GlueClassDeclaration are always visible for TypeParameters in GlueMethodHeader (even if method is static).

15.12 Method Invocation Expressions:
GlueMethodInvocation:
  Primary .. TypeName_opt NonWildTypeArguments*_opt Identifier ( ArgumentList_opt )
  super .. TypeName_opt NonWildTypeArguments*_opt Identifier ( ArgumentList_opt )
  ClassName . super .. TypeName_opt NonWildTypeArguments*_opt Identifier ( ArgumentList_opt )
  TypeName .. TypeName_opt NonWildTypeArguments* Identifier ( ArgumentList_opt )

NonWildTypeArguments* suit TypeParameters in GlueMethodHeader.

COMPILATION:

If object (except null) is valid for GlueFormalParameter then glue-method can be called for this object.
If type is compatible with GlueFormalParameter then static glue-method can be called for this type.
For non static methods glued-object is passed as first 'this' parameter.
Compiled method signature contains TypeParameters from GlueClassDeclaration (at start), and it's always static.

TESTING:
Like simple static methods.

LIBRARY SUPPORT:
No.

REFLECTIVE APIS:
No.

OTHER CHANGES:
No.

MIGRATION:
None.

COMPATIBILITY

New jars are fully compatible. Code is only backward compatible.

REFERENCES

Glue classes proposal beta
Glue classes proposal 0.9
Extension of 'Interface' definition to include class (static) methods

Return 'this' proposal

2009-03-15T22:27:00.024+01:00

GENESIS

It's a simplified 'This' type problem, which seems to be too much complicated as for now and need more analyses. Construction is designed not to interact with possibility that 'This' type will be introduced.

OVERVIEW

FEATURE SUMMARY:
It allows the method to return reference to 'this' object.

MAJOR ADVANTAGE:
Simplification of return this; statement.
'void' can be easy replaced with 'this'.

MAJOR BENEFIT(s): It would prevent NullPointerException, and make some 'builder' like interfaces look really clear and simple.

MAJOR DISADVANTAGE:
Returned value cannot be changed while inheritance.

ALTERNATIVES:
Self-bounded generics, This type.

EXAMPLES

SIMPLE/ADVANCED EXAMPLE:

public class Builder {



  String text = "";



  public this add (char c){text+=c;}

  

  public this add (String c){

    if (c==null){

      text +="null";

      return; // this will be  returned

    }

    text+=c;

  }

  

  public static void test(Builder builder) {

    builder.add('.').add("test()").add(':');

  }



}


package test;



public class ReturnThis {



 public static Class<?> getTestingReturnType(Object object) throws SecurityException, NoSuchMethodException {

  return object.getClass().getMethod("testing").getReturnType();

 }



 static class A { public this testing() {}; }



 static class B extends A {}



 public static void main(String[] args) throws SecurityException, NoSuchMethodException {

  System.out.println(getTestingReturnType(new A()));

  // will print: class test.ReturnThis$A



  System.out.println(getTestingReturnType(new B()));

  // will print: class test.ReturnThis$B

 }

}

  static class A { public this test() { } }



  static class B extends A { }



  static Class<?> getReturnedType(Class<?> classs) {

    try {

      return classs.getMethod("test").getReturnType();

    } catch (SecurityException e) {

      e.printStackTrace();

    } catch (NoSuchMethodException e) {

      e.printStackTrace();

    }

    return null;

  }



  public static void main(String[] args) {

    System.out.println(getReturnedType(A.class));

    // will print: class returnThis.ReturnThis$A

    

    System.out.println(getReturnedType((new A()).getClass()));

    // will print: class returnThis.ReturnThis$A

    

    System.out.println(getReturnedType(B.class));

    // will print: class returnThis.ReturnThis$B

    

    System.out.println(getReturnedType((new B()).getClass()));

    // will print: class returnThis.ReturnThis$B

  }

DETAILS

SPECIFICATION:
JLS 8.4

ResultType:
  Type
  void
  this

A method declaration either specifies the type of value that the method returns, uses the keyword void to indicate that the method does not return a value, or uses the keyword this to indicate that the method return the reference to 'this' object.

Keyword this cannot occurs if method is static.

JLS 14.17

ReturnStatement:
return Expression_opt ;

A return statement with no Expression must be contained in the body of a method that is declared, using the keyword void, not to return any value (§8.4), or in the body of a method that is declared, using the keyword this , to return this reference (§8...),or in the body of a constructor (§8.8).

Method Overriding:
Method with 'this' as ResultType can be override only with method with the same ResultType (proposal in this form can be, however, extended to work with backward covariant return types in future)

COMPILATION:

Method just before exiting from it's scope returns 'this'.
Returned object type is ALWAYS actual object type.
Method in compiled form have special 'this' type as ResultType, which is exchanged during loading to be actual object type:
interface A{ this sample(); }
interface B extends A { }
class C implements B { this sample(){...}; }
So compiled classes contain only methods with A and C, but after loading they are extended to ensure that Method.getReturnType() will be always actual object type.

TESTING:
Most efforts need to be focused on ensuring that Method.getReturnType() will work in a correct way.

LIBRARY SUPPORT:
No.

REFLECTIVE APIS:
No: From this perspective methods are simply overridden in runtime.

OTHER CHANGES:
Javadoc:
return type is visible as 'this' and linked to current class.

MIGRATION:
None.

COMPATIBILITY

Backward: full.
Forward: can be handled like other void type to be partial compatibile.

REFERENCES

Bug: 6479372
http://java.net/cs/user/view/cs_msg/37432

Read-only & Partial arrays proposal

2009-03-14T20:50:00.003+01:00

Instrukcje

Tworzenie tablic do odczytu pozwoliło by zwiększyć szybkość jak i bezpieczeństwo pisanych programów. Była by to zwykła tablica tworzona na podstawie już istniejącej bez możliwości modyfikacji jej stanu.

Tablice częściowe tworzone na tablicach do odczytu pomogły by zmniejszyć ryzyko popełnienia błędu dostępu do niewłaściwego obszaru tablicy oraz zmniejszyło by zużycie pamięci.

Przegląd

Podsumowanie:
Obecnie tablice są jedyną konstrukcją która nie pozwala limitowania dostępu na zapis. Przy tym poziom kontroli nad nimi(min sprawdzanie indeksów) pozwala uważać, że nie powinno stanowić to problemów.
Tablice częściowe to bardziej skomplikowana sprawa, gdyż wymaga aby tablica zawierała informacje o rodzicu. Lub wręcz usprawnienia działania GC.

Główne zalety / korzyści:

(Read-only) Zwiększenie bezpieczeństwa kodu.
(Read-only) Oszczędność pamięci.
(Partial) Zwiększenie bezpieczeństwa kodu.
(Partial) Możliwość zredukowania konieczności kopiowania tablic do minimum.
(Partial) Szybkość wydzielenia kawałka tablicy w stosunku do kopiowania.

Najistotniejsze wady:

Trzeba zaimplementować.
Problem z wyegzekwowaniem braku praw zapisu ze strony JNI.
(Partial) Konieczność poprawienia GC, bądź liczenia się z tym, że pamięć nie będzie zwalniana.

Inne rozwiązania:

ArrayListy tylko do odczytu.
Iteratory.
Kopiowanie tablic.
Każdy konstruktor może zwracać dwa 'obiekty' jeden normalny drugi tylko do odczytu.

Przykłady:

  public void array() {
    int[] array = new int[] { 1, 2, 3, 4 };
    int[] readOnlyArray = array.getReadOnly();
    readOnlyArray[0] = 2; // Exception
    readOnlyArray = readOnlyArray.getReadOnly(1,2);
    System.out.println(readOnlyArray.length); // will print 1
  }

Detale rozwiązania:

(tablica).getReadOnly() : T[]
(tablica).getReadOnly(int from,int to) : T[]
(tablica).isReadOnly() : boolean;

Kompatybilność wsteczna:

Zapewniona.

Kompatybilność w przód:

Trudno powiedzieć.

Linki:

Glue classes proposal beta

2009-03-12T20:47:00.006+01:00

OVERVIEW

Notice that it's beta specification: it's not described in full details, half validated (translation), and it's provided for you to pre-analyse. I still need some time to provide syntax which fully supports generics. Multi-glue classes are under consideration as well, but this may occur to be to complex to handle by any earth living programmer.

FEATURE SUMMARY:
Glue classes allow to link utils direct with objects.

MAJOR ADVANTAGE:
Forgotten functionality can be not such big deal now.

MAJOR BENEFIT(s):

New functions can be easy localised (critically important while introduce new peoples into project).
Security: glue class do not see anything protected.
Light binding new functions with existing classes.
Number of used classes reduction.
Allow to assign methods and functions(static methods) to arrays, classes, interfaces, …
It's proof against same method occurs in class and delegator as well like in two delegators.
Allow to link gained(.jar) logic with new one, witch is impossible before final developer implements his classes.
Allow to project compact interfaces and do not worry about additional logic.

MAJOR DISADVANTAGE:
Do not know any ;) sorry.

ALTERNATIVES:
Utils classes.

EXAMPLES

SIMPLE EXAMPLE:

public class base glue <? extends Date>

{



  private static final SimpleDateFormat  sdf  = new SimpleDateFormat("yyyy.MM.dd");



  public String format(This this) {

    synchronized (sdf) {

      return sdf.format(this);

    }

  }



  private static final Date applicationStart = new Date();



  public static Date applicationStart() {

    return applicationStart;

  }



}

base: logic name, should start with lowercase because it's representing logic not class.
glue <? extends Date>: logic will glue to all classes extending Date.
.format(This this): method that will be 'visible' for declared objects.
This: Object type representing this.getClass()
this: equivalent with given bound (? extends Date).

Usage:

import java.util.Date;

import pl.some.utils.base; // imported to allow ..format() execution



public class Test {



  public static void test_0(Date date) {

    System.out.println(date..format()); //simple usage

  }



  public static void test_1(Date date) {

    System.out.println(date..base.format()); //used when we have more logics with same methods

  }



  public static void test_2(Date date) {

    System.out.println(date..pl.some.utils.base.format()); // full declaration

  }


  public static void test_3() {

    System.out.println(Date..applicationStart()..format()); // mixed case

  }



}

ADVANCED EXAMPLE:
Will come...

DETAILS

SPECIFICATION:
JLS 8.8: http://java.sun.com/docs/books/jls/third_edition/html/classes.html#8.8 ClassDeclaration:
  NormalClassDeclaration
  GlueClassDeclaration
  EnumDeclaration

GlueClassDeclaration
  ClassModifiers_opt class Identifier glue<ActualTypeArgument> GlueClassBody

ActualTypeArgument
  (JLS 4.5.1) represent objects for witch glue works: <? extends Date>, <Date>, <Object[][]>, ...

COMPILATION:
Everything we need is already in JDK, we just need little trick to bind static method in compilation time with existing classes.

TESTING:
Like simple static methods.

LIBRARY SUPPORT:
No.

REFLECTIVE APIS:
No.

OTHER CHANGES:
No.

MIGRATION:
None.

COMPATIBILITY

New jars are fully compatible. Code is only backward compatible.

REFERENCES

Glue classes proposal beta: http://lasu2string.blogspot.com/2009/03/glue-classes-proposal.html

Krucjata przeciwko dziedziczeniu. Wyprawa 2.

Instrukcje

Zapewne nie raz zdarzyło się wam pisać metody do już istniejących klas. Jeśli klasa nie pochodziła z 'zewnętrznych' bibliotek to pół biedy, co się dzieje jeśli jednak pochodzi?

Dziedziczymy? Ależ oczywiście, że tak.
Metody statyczne? I to porozrzucane po całym projekcie.
Lub po prostu więcej kodu.

Efekty nie są przyjemne. Zwiększenie komplikacji samego kodu, jego logiki, oraz struktury klas. Nie raz zdarza się, że nowy pracownik pisze rzeczy już napisane ponieważ nie potrafi ich zlokalizować.

Rozważmy klasy które zamiast gromadząc statyczne metody doklejała by je do już istniejącej klasy.

Wyobraźmy sobie sytuacje gdy przy obiekcie Date po postawieniu kropki obok standardowych metod wyświetlają się nam:

..sformatujDoBazyDanych() : String

..sformatujDoWyświetlenia() : String

Sytuacja staje się na tyle jasna, że nawet nowo przybyły pracownik wie co ma robić. Ile czasu oszczędziło by to już paracującym? Oraz ograniczyło ilość używanych klas w kodzie.

Ciekawym rozwiązaniem może być także doklejanie metod do interfejsów.

Przykładowe schematy obrazujące przyklejone klasy.

Klasa z metodami statycznymi

Zwykła klasa

Klasy przyklejone	Klasyczne metody podejścia
Klasa + klasa przyklejona.	Klasa + klasa pomocnicza z metodami statycznymi.
Klasa + dwie klasy przyklejone.	Klasa + klasa pomocnicza z metodami statycznymi + dziedziczenie.
Klasa + cztery klasy przyklejone.	Klasa + dwie klasy pomocnicze z metodami statycznymi + dziedziczenie.

Przegląd

Główne zalety / korzyści:

Szybka lokalizacja nowych funkcjonalności.
'Lekkie' wiązania nowych funkcji z istniejącymi klasami.
Znaczna redukcja ilości używanych klas.
Umożliwia podpięcie statycznych metod pod interfejsy.
Umożliwia 'bezpieczne' rozszerzenie klas finalnych.
Umożliwia tworzenie zwięzłych klas(nie trzeba od razu pamiętać o wszystkich funkcjach).

Najistotniejsze wady:

Określenie sposobu selektywnego wyłączania przyklejonych klas.

Inne rozwiązania:

Modlitwa ;) .
Nie zatrudniać nowych ludzi.

Podsumowanie:

Przykłady:

… glue class DisplayDate extends Date{



  private static final SimpleDateFormat sdf 

    =new SimpleDateFormat("yyyy.MM.dd");



  public glue String format(){

  synchronized (sdf) {

    f.format(this);

    }

  }



}

Wywołanie:


   ...(){

   Date cur = new Date();

   return cur..format();

   }


   ...(){

   Date cur = new Date();

   return cur..DisplayDate.format();

   }

Detale rozwiązania:

this reprezentuje klasę + interfejsy warunkujące doklejanie.

Do rozważenia są także metody potrafiące się doklejać do więcej niż jednej klasy...

Dodatkowo nie należy zapominać, że metody statyczne też powinny mieć możliwość warunkowego doklejania.

Metody doklejane nie powinny mieć dostępu do prywatnych pól i metod.

Kompatybilność:

Wsteczna:
Pełna.

W przód:
Brak.

Consider operator proposal

2009-03-11T20:19:00.025+01:00

OVERVIEW

FEATURE SUMMARY:
Consider operator extends language with full value support and assign value to name and return it.

MAJOR ADVANTAGE:
It introduces natural division in variables and values.

It makes language to be more natural for human and generics easier to use.

MAJOR BENEFIT(s):

If we need to get a value, we can do that quite simple (without splitting expression or duplicating code).
Decrease number of potential bugs (value cannot be assigned).
It can help in splitting code to proper parts; nowdays, we need to declare variable regardless we need it or not (or make it final).
Decrease size of unnecessary code.
Method can be itself multi-thread with this, but it's far future.

MAJOR DISADVANTAGE:
Possibility to be unclear at start.

ALTERNATIVES:
Some time 'final' variables can be used, but it's more like for-each, life is better with it.

EXAMPLES

SIMPLE EXAMPLE:

  public static void standard(Resource<String,Container<Unit>> resource) {

    Comparator<Resource<String,Container<Unit>>> resourceComparator

        = (standard? Resource.baseComparator : Resource.extdComparator);

    if (resourceComparator.compare(resource,this.last)==0) return; // duplicate

    ...

  }



  public static void consider(Resource<String,Container<Unit>> resource) {

    (standard? Resource.baseComparator : Resource.extdComparator) :: resourceComparator;

    if (resourceComparator.compare(resource,this.last)==0) return; // duplicate

    ...

  }



  public static void standard_2(ArrayList<Resource<String,Container<Unit>>> resources){

    for (Resource<String,Container<Unit>> resource: resources){

      System.out.println(resource);

    }

  }

  

  public static void consider_2(ArrayList<Resource<String,Container<Unit>>> resources){

    for (::resource:resources){

      System.out.println(resource);

    }

  }

ADVANCED EXAMPLE:

  public void validLastElementState(ArrayList<Data> list){

    if (list.get(list.size()::size-1)::data.reportStare().getState()!=validState){

      throw new IllegalStateException(Data.class.getSimpleName()+"("+data+") of "+size+" elements is in wrong "+State.class.getSimpleName());

    }

    ... other operations ...

  }

Would be compiled to:


  public void validLastElementState(ArrayList<Data> list){

    {

      list.size()::size;

      list.get(size-1)::data

     if (data.reportStare().getState()!=validState){ 

       throw new IllegalStateException(

           Data.class.getSimpleName()+"("+data+") of "+size+" elements is in wrong "+State.class.getSimpleName()); 

     }

    }

   ... other operations ... 

   }

DETAILS

SPECIFICATION:
Value :: name
Assign left side value to given name and return it.

JLS 14.14.2
EnhancedForStatement:
    for ( VarDeclaration : Expression) Statement

VarDeclaration: al least one of
    VariableDeclaration
    ValueDeclaration

VariableDeclaration
    VariableModifiersopt Type Identifier

ValueDeclaration
    :: ValueName

COMPILATION:
While value is same as final variable compiling is not big problem.

TESTING:
Same as final variable.

LIBRARY SUPPORT:
No.

REFLECTIVE APIS:
No.

OTHER CHANGES:
No.

MIGRATION:
No need.

COMPATIBILITY

Compiled code can be normally executed.

REFERENCES

Consider operator proposal

Instrukcje

Człowiek nie myśli sekwencyjnie, tak więc i pisanie sekwencyjnych algorytmów nie jest czymś zupełnie naturalnym dla niego. Dlatego założenie, że sekwencyjny algorytm będzie czytać się łatwo jest co najmniej nie trafione.

Proponowany operator '::' ma ułatwić myślenie o wynikach jak o wynikach a nie zmiennych, a wiązał by on wartość z nawą: wartość::nazwa, (wartość po ktorej możemy iterować):::(nazwa wartości iterowanych) bądź wartość::nazwa::{blok w którym obowiązuje wartość}. Nie należy zapominać że pewnym ukłonem (bardzo sensownym zresztą) w te stroną są 'zmienne' final.

Aby w pełni zrozumieć sytuacje przyjrzyjmy tytułowi jednego z rozdziałów JLS: „Types, Values, and Variables” wygląda pięknie jednak nie do końca odpowiada rzeczywistości która rysuję się raczej jak: „Types, Variables and their Values”, gdyż tak naprawdę wartości są tylko częściowo wspierane przez Jave. 'Zawężenie' myślenia do kategorii zmiennych wynika z asemblera i obecnie znacznie ogranicza nas przed myśleniem o niektórych bytach jako lokalnie nie zmiennych (wartość nie może się zmienić).

Jak wyglądała by Java wspierająca wartości:

Częściowo(czyli tak jak obecnie) :

  public void validLastElementState(ArrayList<Data> list) {

    {

      int size = list.size();

      Data data = list.get(size - 1);

      if (data.reportStare().getState()!=validState){

        throw new IllegalStateException(Data.class.getSimpleName()+"("+data+") of "+size+" elements is in wrong "+State.class.getSimpleName());

      }

    }

    ... other operations ...

  }

W ogóle (+/-) :

  public void validLastElementState(ArrayList<Data> list) {

    {

      int size = list.size();

      int position =size -1;

      Data data = list.get(position);

      StateReporter stateReporter = data.reportStare();

      State state = stateReporter.getState();

      if (state!=validState){

        throw new IllegalStateException(Data.class.getSimpleName()+"("+data+") of "+size+" elements is in wrong "+State.class.getSimpleName());

      }

    }

    ... other operations ...

  }

W pełni :

  public void validLastElementState(ArrayList<Data> list){

    if (list.get(list.size()::size-1)::data.reportStare().getState()!=validState){

      throw new IllegalStateException(Data.class.getSimpleName()+"("+data+") of "+size+" elements is in wrong "+State.class.getSimpleName());

    }

    ... other operations ...

  }

Przegląd

Główne zalety / korzyści:

Naturalny zapis algorytmów bez niepotrzebnych rozbić tylko dla wyciągnięcia zmiennej.
Możliwość naturalnego rozbicia odpowiednio napisanych metod na wiele wątków(daleka przyszłość).
Mniejsza ilość bugów.
Ułatwia rozdzielenie kodu na więcej mniejszych linijek (nie trzeba deklarować zmiennych).
Mniejsza ilość niepotrzebnego kodu.

Najistotniejsze wady:

Dla niektórych taki zapis może być czymś problematycznym.
Konieczność rozważenia widoczności wartości.
Pewnym problemem może być fakt, że w warunkach logicznych && operator '::' mógłby znajdować się tylko z lewej strony wyrażenia (prawa może zostać pominięta).

Inne rozwiązania:

Używanie 'zmiennych' final.

Podsumowanie:
Powyższe rozwiązanie nie wprowadza do języka nic nowego, pozwala jednak zapisywać algorytmy w sposób bardziej naturalny/intuicyjny. Nie należy zapominać iż daje także możliwość większego 'narzygania' do kodu.

Przykłady:

W pełni :

  public void validLastElementState(ArrayList<Data> list){

    list.size()::size;

    list.get(size-1)::data

    if (data.reportStare().getState()!=validState){

      throw new IllegalStateException(Data.class.getSimpleName()+"("+data+") of "+size+" elements is in wrong "+State.class.getSimpleName());

    }

    ... other operations ...

  }


  public static void printAll(ArrayList<ArrayList<SomeGeneric<String, Integer>>> param) {

    for (ArrayList<SomeGeneric<String, Integer>> l1 : param) {

      for (SomeGeneric<String, Integer> l2 : l1) {

        System.out.println(l2);

        l2=null;//ok

      }

    }

  }

  

  public static void printAll(ArrayList<ArrayList<SomeGeneric<String, Integer>>> param) {

    for (param:::l1) {

      for (l1:::l2) {

        System.out.println(l2);

        l2 = null;//error

      }

    }

  }

Detale rozwiązania:

Wartość sama z siebie nie może się zmienić, gdyż była by inną wartością, a co za tym idzie wszelkie próby podstawienia kończyły by się błedem w czasie kompilacji.

Kompatybilność:

Wsteczna:
Pełna.

W przód:
Brak.

Delegation proposal

2009-03-10T19:47:00.000+01:00

OVERVIEW

FEATURE SUMMARY:
This change allow to delegate methods, interfaces and classes.

MAJOR ADVANTAGE:
It would be a first step for programmers to have something instead of inheritance, allowing to write better code.

MAJOR BENEFITS:
Java looks incomplete without something so base as delegating. Others are:

Code more immune for changes(if interface changes, there will be not so much to change, or I would say, changes will be on the right place, but not on all projects)
Decreasing costs of code modification.
Explicit defining MethodModifiers

MAJOR DISADVANTAGE:
Changes cost.

ALTERNATIVES:
It's nothing that cannot be implemented in a simple way, but this change does not increase delegation complex, unreadablity, and costs of support with each method.

EXAMPLES

SIMPLE EXAMPLE:

public abstract class ClassA implements InterfaceA {

  InterfaceA ia = ...;

  public delegate InterfaceA{
    return ia;
  }

}

ADVANCED EXAMPLE:

public abstract class ClassA implements InterfaceA {

  ClassSome cs = ... ; // ClassSome implements InterfaceA, InterfaceB, InterfaceC

  Some some = ... ; // have the same methods from InterfaceA and InterfaceC but do not implements them

  public delegate ClassSome exclude Object,InterfaceB{
    if (cs==null) return some;
    return cs;
  }

}

DETAILS

SPECIFICATION:
DelegationDeclaration:
    DelegationHeader DelegationBody

DelegationHeader:
    DelegationModifiers_opt delegate MethodSets Exclude_opt Throws_opt DelegationDeclarator

DelegationModifiers:
    DelegationModifier
    DelegationModifiers DelegationModifier

DelegationModifier: one of
    Annotation public protected private abstract static final synchronized

Exclude:
    exclude MethodSets

MethodSets:
    MethodSet
    MethodSets, MethodSet

MethodSet: one of
    ClassOrInterfaceType InterfaceMemberDeclaration

DelegationBody:
    same with: MethodBody except ReturnStatement

ReturnStatement:
    return* Expression

return work in different way in delegation than in method.
For each method with ResultType(Type) it's interpreted:
    return (Expression).MethodIdentifier(ActualParameters);
For each method with ResultType(void) it's interpreted:
    (Expression).MethodIdentifier(ActualParameters);
    return;

COMPILATION:
Delegation is deployed to all methods that occur in 'delegate MethodSets' and do not occur in Exclude_opt.
All methods have modifiers: DelegationModifiers_opt
Declared exception in Throws_opt are added to each method ExceptionTypeList.

TESTING:
Normal way.

LIBRARY SUPPORT:
No

REFLECTIVE APIS:
No changed.

OTHER CHANGES:
None.

MIGRATION:
No need.

COMPATIBILITY

All working programs will still work. New byte code is compatible with old one.

REFERENCES

Delegation proposal

Instrukcje

Opinia aby zabronić 'złego' dziedziczenia jest dość powszechnie znana. Jednak żeby być szczerym trzeba stwierdzić, że nie ma w języku mechanizmu który by wspierał choćby delegacje. W związku z oczywistymi utrudnieniami pojawiają się choćby głosy, ażeby wprowadzić do języka properties (czyt. automatycznie dodawanie get-erów i set-erów). O ile pomysł ten jest ciut poroniony np.: jeśli chcieli byśmy oddzielnie zdefiniować min. widoczność to musieli byśmy napisać praktycznie tyle samo kodu ile przy zwykłej metodzie. Jednak sam problem ma swoje podstawy.

Przyjrzyjmy się więc przykładowej konstrukcji która miała by pozwolić na delegowanie class i interfejsów. Oraz możliwościom jakie by ona dała.

Przegląd

Główne zalety / korzyści:

Ujednolicenie sposobu delegacji wielu metod.
Łatwy refactor (zakomentowanie delegacji, wykluczenie metody).
Możliwość jawnego zdefiniowania widoczności jak i innych modyfikatorów (static / final)

Najistotniejsze wady:

Koszt zmian.
Zdefiniować reagowanie na ewentualny null.

Inne rozwiązania:

Pisać wszystko ręcznie.
Rozszerzyć środowisko o lepsze generatory kodu.

Podsumowanie:

Przykłady:

Baza

public interface InterfaceA extends Iterable<String> {

String getName();

ArrayList<Date> getDates();

}

public interface InterfaceB {

public InterfaceA info();

}

public abstract class ClassA implements InterfaceA {

public int delta = 0;

abstract public void printState();

}

Przykład

public class Sample_01 {

  private static InterfaceA interfaceA;

  public static delegate InterfaceA from interfaceA onnull {throw new NullPointerException(InterfaceA.class.getSimpleName());};

}

Wyglądał by po skompilowaniu jak:

public class Sample_01 {

  private static InterfaceA  interfaceA;

  public static String getName() {
    if (interfaceA == null) throw new NullPointerException(InterfaceA.class.getSimpleName());
    return interfaceA.getName();
  }

  public static ArrayList<Date> getDates() {
    if (interfaceA == null) throw new NullPointerException(InterfaceA.class.getSimpleName());
    return interfaceA.getDates();
  }

}

Przykład

public class Sample_02 {

  private static InterfaceA  interfaceA;

  private static InterfaceB  interfaceB;

  private InterfaceA getInterfaceA() {
    return interfaceA == null ? interfaceB.info() : interfaceA;
  }

  public final delegate InterfaceA from getInterfaceA();

}

Wyglądał by po skompilowaniu jak:

Detale rozwiązania:

[private|protected|public|final|static|]
delegate
{[Interface|Class|method]}
from
[variable|method|function|null]
[exclude {Interface|Class|list of methods}]
[onnull throw new Exception(...)]

Dla kompilatora metoda wydelegowana jak i zadeklarowana jawnie były by identyczne, a co za tym idzie dwie identyczne nie mogły by występować w tym samym czasie.

Kompatybilność:

Wsteczna:
Taki sposób delegowania metod nie wpływa na już istniejący kod.

W przód:
Sam kod nie mógłby być interpretowany wstecz. Aczkolwiek nie ma znanych mi przeciwwskazań aby prze-kompilowane biblioteki nie mogły być używane.

Linki:

Ulatwiło by to: Bug: Add language support for converting methods to interfaces
Bug 4483171
Bug 5043025

Final interfaces... proposal

2009-03-09T19:37:00.000+01:00

Instrukcje

Interface (klasa abstrakcyjna) finalny nie mógłby zostać rozszerzony (zaimplementowany) przez żadną klasę(interface), oprócz tych określonych wprost.

Przegląd

Podsumowanie:

Główne zalety / korzyści:

Ograniczenie pomyłek, zwłaszcza w przypadku dużych projektów.
Zwiększenie bezpieczeństwa.

Najistotniejsze wady:

Trzeba zaimplementować.

Inne rozwiązania:

Agregacja + validacja.

Przykłady:

Detale rozwiązania:

interface final Interface allow ClassI

Kompatybilność wsteczna:

Zapewniona.

Kompatybilność w przód:

Częściowa.

'forget' keyword proposal

2009-03-08T19:29:00.000+01:00

Instrukcje

Słowo 'forget' powodowało by wymazanie zmiennej z obecnego kontekstu. Co pozwoliło by na bardziej intuicyjne operowanie logiką programu, w przypadku gdy dana zmienna nie może(powinna być) być już używana. Ma to niebanalne znaczenie gdy po jakimś czasie wracamy do napisanego kodu.

Przegląd

Podsumowanie:
Rozszerzenie kontroli nad zasięgiem istnienia zmiennych.

Główne zalety / korzyści:

Brak konieczności wprowadzania sztucznych bloków. Czyli używania bloków do limitowania dostępu do zmiennych oraz wyodrębniania logicznie spójnych fragmentów kodu.
Czytelniejszy kod.
Mniej bugów (Możemy jasno określić gdy nie nie wolno dam już danej zmiennej użyć).

Najistotniejsze wady:

Trzeba zaimplementować.
Niektórzy mogą nadużywać tych samych nazw.

Inne rozwiązania:

Przeważnie można używać zmiennych o zasięgu bloku. Niestety zmuszeni jesteśmy wtedy wcześniej deklarować zmienne(przed blokiem/pascal like).
Podstawić null (najwyżej wyleci wyjątek).

Przykłady:



  public void read(String path) throws IOException {

    InputStreamReader isr = new InputStreamReader(new FileInputStream(new File(path)));

    int some = isr.read();

    // read

    isr.close();

    forget isr;

    // other operations

    InputStreamReader isr = new InputStreamReader(new FileInputStream(new File(path+".txt")));

    // other operations ...

  }

Detale rozwiązania:

Kompatybilność wsteczna:

Zapewniona pod warunkiem automatycznej zmiany nazw zmiennych, bądź przy możliwości współistnienia zmiennej o nazwie słowa kluczowego.

Kompatybilność w przód:

Zapewniona na poziome bytecodu

'This' type

2009-03-03T19:40:00.010+01:00

AUTHOR: Lasu aka Marek Kozieł http://lasu2string.blogspot.com/

OVERVIEW

FEATURE SUMMARY:
This type add ability to project valid interfaces(classes) for further extending/implementing. 'This' means current interface/class type or something implementing/extending it.

MAJOR ADVANTAGE:

Support of interface projecting at interface level.
More readable code structure (interfaces/methods).
Making refactor more enjoyable (much easier).
Discarding request of replacing 'void' with 'this'.
Splitting interfaces to sub-interfaces can become pleasant.
Down casting working properly.
Decreasing number of method signatures in classes/interfaces.

MAJOR DISADVANTAGE:

Class 'This' may already exist somewhere in code(?)
As so far, it's not been thought over know if there is point of using it for input parameters.
'This.class' might be a problem for generics, but generally everything depends on how 'This' is interpreted(personally, I think that it should be generic with arguments)(this.getClass()).

ALTERNATIVES:
Rewriting each method's signature on every class / interface.

EXAMPLES

  public static interface IB implements Iterable<This> {
  }

  public static interface IC implements IB {
  }

Would mean(which is impossible now time):

public static interface IC implementsIB, Iterable<IC> {
}

public static interface IA {
    This write(String s);
  }

  public static interface IB extends IA {
    This write(double value);
  }

  public abstract static class CC implements IB {
    This write(int value){
      ...
      return this;
    }
  }

  public static class CD extends CC {
    @Override
    public This write(double value) {
      ...
      return this;
    }
    @Override
    public This write(String s) {
      ...
      return this;
    }
  }

  public static void main(String[] args) {
    CD object = new CD();
    object.write("Some").write(3).write(3.11);
  }

Nowdays, the same code would look as:

public static interface IA {
    IA write(String s);
  }

  public static interface IB extends IA {
    IB write(double value);
    @Override
    IB write(String s);
  }

  public abstract static class CC implements IB {
    CC write(int value){
      ...
      return this;
    }

    @Override
    public abstract CC write(double value);

    @Override
    public abstract CC write(String s);
  }

  public static class CD extends CC {
    @Override
    public CD write(double value) {
      ...
      return this;
    }
    @Override
    public CD write(String s) {
      ...
      return this;
    }
    @Override
    CD write(int value){
      ...
      return this;
    }
  }

DETAILS:

SPECIFICATION:
(I did not have time to analyze this completely.)

COMPILATION:
With 'This' type is valid:

this
null
? extends This

'This' should be considered to be able to appear in:

return type(yes).
input type(yes/no?).
method body(yes?).
As generic parameter(yes/only if they appear as return types?).

List<This extends Container<This>> would mean This but not less than Container

This could be reduced to last superclass

COMPATIBILITY

Only programs where are class/interface named 'This' used can be problem.

REFERENCES

Notice that considered document does not contain complete analyze of those solutions and can have some lacks. So if you have some questions/advices that it does not fully fit with Project Coin, post it on my blog to discuss:
http://lasu2string.blogspot.com/2009/03/this-type.html

Instrukcje

Może to nie jest jasne jednak o ile klasy podlegają dziedziczeniu to już typy nie. Efektem tego jest dość paranoidalna sytuacja w której z jednej strony sugeruje się stosowanie interfejsów a z drugiej uniemożliwia się tworzenie ciągów wywołań.

Dość średnim sposobem rozwiązania tego problemu była propozycja wprowadzenia automatycznej konwersji void na this. Jednak są ludzie którzy świadomie stosują void np. żeby później zdefiniować pożądany zwracany typ ( bugi wynikajace ze zmian murowane ).

Przegląd

Główne zalety / korzyści:

Uproszczenie struktury kodu.
Uproszczenie projektowania złożonych interfejsów.

Najistotniejsze wady:

Komplikacja struktury kodu.
Trzeba się zastanowić czy This ma sens jako parametr wejściowy.
Istnieją klasy o nazwie 'This'.

Inne rozwiązania:

Przepisać każdą metodę jeszcze raz w każdej klasie/interfejsie ze zmienionym typem zwracanym.
Zwracać void i zmuszać programistów do bardziej 'jawnych' wywołań.

Podsumowanie:

Przykłady:

  public static void main(String[] args) {
    CD object = new CD();
    object.write("Some").write(3).write(3.11);
  }

Aby osiągnąć podobny efekt dziś musieli byśmy napisać:

Detale rozwiązania:

Co jest typu This?

zmienne typu This
this
null
zmienne typu ? extends This

Kompatybilność:

Wsteczna:
Pełna.

W przód:
Brak.

Project Coin: Known enhancements

2009-02-18T17:11:00.022+01:00

You can read about really nice idea to make Java better: FOSDEM 2009: OpenJDK 6 and Project Coin. So lets see some of them...

(Reflection) Accessibilities of members should be ACCESS-LEVEL sensitive

I do not like reflection (yet). And do not see point to increase it's range. But idea about considering context of method call is nice for security.

String conversion needs another index entry

It's about(I think): String Concatenation Operator + ?

Compilation spec needed: should state if private should imply final for a method

I do not know why some one would like to see some methods to be final without 'final' word. This could be pretty troublesome.

long double support

Why not?

Extension of 'Interface' definition to include class (static) methods.

I wandered about this some time ago. But maybe I'll be able to introduce better way to provide this.

Method forwarding - Subclassing without subtyping

This need to be inspected. I wandered about similar idea (but more Java-like).
The Replace Inheritance with Delegation Refactoring (RIWD)

Cloning inner classes

It's no problem for me ;P

A Proposal for User-Defined Lightweight Value-Semantics Objects

I'll have to take more time to consider it...

Suggestion for "atomic" keyword for try {} blocks

What for(increase complex)?

Explicit (language) support for properties

Problem is real but solution is weak.

Ease the JLS to allow mathematical symbols in indentifiers (defined operators or operator overloading)
Allow Unicode versions of operators
RFE: Operator overloading

But why in Java?

RFE: Please add nested /* */ comments

Interesting for consideration, but impossible.

Maximum method size is too small (64Kb)

Heavy methods ^_^

Allow multiple constants and ranges in case labels

Why not?

Object Oriented Callbacks

callbackName = myObject.myFunction
NOT in this form.

'final' variables and inner classes

I'll have to take more time to consider it...

java really needs a complex (number) primitive type

Life is not always nice. AlgebraicMath

Allow this/super in certain static contexts

Really bad solution(not the problem).

Catching multiple exceptions simultaneously

YES!

package access for interface methods

I wander about further problems...

Add support for vertabim string literals

Should be deeply considered.

Java Generics Support should support primitive types

Nice idea but impossible.

RFE: Add Immutable types to Java

Agree with problem / do not agree with solution.

silly JLS rule that restricts the throw clause in a hiding method

I think I do agree.

http://bugs.sun.com/view_bug.do?bug_id=4632701

As I already said. Make language depended from one implementation is not good idea.

Document class file attributes for compilation date/time + debugging

Hard to say.

wanted: constant pool entries for arrays

I think I need better description.

RFE: Tail Call Optimization

I want to meet the men who introduced this idea.

Multiple return values from a method

It's matter of time.

RFE: permit allocation of new objects on stack

"Unfortunately, it's not that simple.
The constructor, for example, might leak the reference. Or any method called on the object might do so."

RFE: syntactic sugar to simulate C++ stack-allocted object destructor semantics

Such big tank to kill the rabbit.

RFE: 64 bit pointers needed

Not this year.

Typedef (alias)

NO?

AutomaticException chaining for exception in try and exception thrown in finally

I would prefer option to select which exception should be dropped.

Encapsulation though access control

2009-02-11T02:48:00.005+01:00

Encapsulation does not necessarily means getters and setters. And have more than one aspects:

Inside structure control.
Input data validation.
Outside access control.

Lets consider 'Outside access control'.

While we directly do not know which class calls method, it's hard to limit context of (method) call. It is possible, but amount of work is to big now time.
Any way what solutions do we have?

Control by 'key'.


public final class SetByLock {



  private SetByLock(Object acessKey) {

    this.acessKey = acessKey;

  }



  private final Object  acessKey;



  private String      data;



  public String getData() {

    return data;

  }



  public void setData(Object accessKey, String data) {

    if (acessKey != accessKey) { throw new UnauthorizedAccessException(accessKey == null ? "null" : accessKey.toString()); }

    this.data = data;

  }



}

As we can see in the example above, we have to pass the key each time we want to execute protected method. For limiting access this solution is good enough, as only creator have the powder to access danger space (method, …), and only he can lend this powder to other objects.

Control by 'delegated accessor'.


public class Container<Type> {



  public Type  element;



}



public class SetByAccessor {



  public SetByAccessor(Container<Accessor> accessorContainer, String data) {

    this.data.data = data;

    if (accessorContainer != null) {

      accessorContainer.element = new Accessor(this.data);

    }

  }



  private Local  data  = new Local();



  public String getData() {

    return data.data;

  }



  /*

   * Store local data

   */

  private static class Local {



    public Local() {

    }



    public String  data;

  }



  /*

   * Allow to more access

   */

  public static class Accessor {

    public Accessor(Local data) {

      if (data == null) { throw new NullPointerException(Local.class.getSimpleName()); }

      this.data = data;

    }



    private Local  data;



    public void setData(String data) {

      this.data.data = data;

    }

  }



}

In this solution we can lend 'limited' access just by one object, while previous one required pair: object & key .
Problem is when we have lot's of elements to control. 1000 objects force us to store 1000 Accessor-s

Mixed solution.




public class SetByMixed {



  public SetByMixed(Object accessKey, String data) {

    this.data.data = data;

    this.accessKey = accessKey;

  }



  private final Object  accessKey;



  private Accessor    accessor;



  public Accessor getAccessor(Object accessKey) {

    if (this.accessKey != accessKey) { throw new UnauthorizedAccessException(accessKey == null ? "null" : accessKey.toString()); }

    if (accessor == null) {

      accessor = new Accessor(data);

    }

    return accessor;

  }



  private Local  data  = new Local();



  public String getData() {

    return data.data;

  }



  /*

   * Store local data

   */

  private static class Local {



    public Local() {

    }



    public String  data;

  }



  /*

   * Allow to 'limited' access

   */

  public static class Accessor {

    public Accessor(Local data) {

      if (data == null) { throw new NullPointerException(Local.class.getSimpleName()); }

      this.data = data;

    }



    private Local  data;



    public void setData(String data) {

      this.data.data = data;

    }

  }



}

At final here we have 'nice' part of code. Keys can be reused and there no need to store pairs to have full access. What more we do not need to write 'secure check' on each method and worry if we have access to every method (it's possible for each method to have own key in control by 'key').
Key just need to be controlled to do not leak out.

Summary.

I just wander, if we really need all this stuff when we want limit write access?

Using Strings and Objects in Switch case statements.

2009-02-04T21:50:00.000+01:00

Lets consider enhancement on Sun Bug Database : 5012262

It's about letting us using String in switch.

Sample workaround:

switch(inputString.hashCode()){
case 3541040: //Hashcode of "strA"
System.out.println("strA");
case 3541041: //Hashcode of "strB"
System.out.println("strB");
}

Now let's see why this will do not work:

System.out.println("aa".hashCode());
System.out.println("bB".hashCode());

Will result with:

3104
3104

Quite lol?

So finally lets see more interesting workaround:

enum Switch {

    ONE("asd") {
      @Override
      public void action() {
        System.out.println(this.text);
      }
    },//
    TWO("bad");//

    protected String  text;

    public void action() {
      throw new NotImplementedException();
    }

    Switch(String text) {
      if (text == null) { throw new NullPointerException("text"); }
      this.text = text;
    }

    public static Switch getByText(String text) {
      if (text == null) return null;
      for (Switch casee : Switch.values()) {
        if (casee.text.equals(text)) return casee;
      }
      return null;
    }

    public static Switch getByTextForStartWith(String prefix) {
      if (prefix == null) return null;
      for (Switch casee : Switch.values()) {
        if (casee.text.startsWith(prefix)) return casee;
      }
      return null;
    }

  }

Can we?

Sure we can!

@see: String switch: Small language changes on JDK 7

Memory management in Java

2009-02-03T00:35:00.014+01:00

Different look on memory leak problem.

We have garbage collector in Java, but this do not prevent us from make memory to leak. What more even standard library isn't leak-free.

How can we spare memory easly?

String.intern() is one of the easiest way.

It do not interfere with gc.
It's fast.
Multi thread safe.

I just need to check if .intern() work with .substring(...)

Where we loose memory quietly?

Most Classes created to store high amount of dynamic data have their own memory menage system. ArrayList, StringBuilder, ... they all allocate *2 memory. Which mean that is we have 1024 elements and need to add one while no free space is available then space will be extended to 2024.

How much memory do we loose?

Calling .trimToSize() can spare approximately 10% of memory.
On String.intern() I used to save up to 70%.

Digital TV in Poland

2009-02-02T01:14:00.019+01:00

Wikipedia: Digital television

Slowly but unstoppable Digital TV will finally come to us.

I just wander why people are so enthusiastic about it?
Let's try to predict sample chronology:

Digital TV work.
People buy new TV-s and/or other equipment.
People open eyes and notice that 3D is better.
3D TV work.
...

Is there really point to introduce Digital TV to market (for customers) while 3D is quite near?

CES 2008: 3DIS 3D monitor Aving
Sony shows 3D television prototypes at CES 2009

Some more information about images:
The Future of Digital Imaging - High Dynamic Range Photography:

Genesis of Programming

2009-02-01T22:10:00.005+01:00

Wikipedia: Tower of Babel

1 At one time the whole earth had the same programming language and vocabulary. 2 As people migrated from the asembler, they found a valley in the land of Shinar and settled there 3 They said to each other, "Come, let us make libraries ." They had objects for stone and patterns for mortar. 4 And they said, "Come, let us build ourselves a language and a standard library with everything programmer can need under the sky. Let us make a name for ourselves; otherwise, we will be scattered over the face of the whole earth."

5 Then the marketing came down to look over the language concepts and the library that the men were building. 6 The marketing said, "If, as one people all having the same language, they have begun to do this, then nothing they plan to do will be impossible for them. 7 Come, let Us go down there and forbid them to create language so that they will not be able to create programs for all the platforms."

8 So the marketing scattered them from there over the firms on the whole earth, and they stopped building the language. 9 Therefore its name is called Babylon, for there the marketing confused the programmers of the whole earth, and from there the marketing scattered them over the face of the firms on the whole earth.

Did anyone wonder how many code go to trash because of current situation?

When you will visit 99 Bottles of Beer you will see sample program in 1249 different programming languages and variations. And as it's easy to predict, it's not all what we can find on the web.

That's why, I do like Java. I do not need to worry for which platform the code is, or learn new language. It may not be clear but Windows is not the entire world.

The LORD said, "If, as one people all having the same language, they have begun to do this, then nothing they plan to do will be impossible for them.Genesis 11:6

Was it really LORD's punishment or maybe people still are not able to find compromise? As we can see, language is not the only problem, there's something more deeper in it.

Direct consequence of current situation is confusion. Students / programmers when they have to much to choose, they try to know as much as possible. With every new language we have more people that know many languages in a base level. :/

@see The future of programming languages (Anders Hejlsberg speech)

Gdyby ludzie mówili językami programowania?

2009-01-19T22:25:00.021+01:00

Generalnie programowanie sprowadza się do myślenia w określony sposób. Często opanowanie tego sposobu zajęło nam tyle czasu i w trakcie użycia sprawia tyle trudności, że nie mamy czasu się zastanawiać co my właściwie myślimy.

Tak więc spróbuje przedstawić jak wyglądała by przykładowa sytuacja w której to Heniek mówi Marianowi, że ten ma udać się do monopolowego po flaszkę oraz bimber który kochana sprzedawczyni Hela trzyma za pazuchą dla najlepszych klientów, a co gorsza z nimi wrócić.

Asembler:

Marian robisz tak:

wsadź rękę w prawą kieszeń Heńka
wyciągnij zawartość
wsadź to co żeś wziął do swojej prawej kieszeni
obróć się w prawo o 90%
zrób 40 kroków w przód
obróć się w prawo o 30%
zrób 40 kroków w przód
otwórz drzwi
zrób 4 kroki w przód
obróć się w prawo o 90%
wsadź prawą rękę za pazuchę Heli
jeśli nie ma bimbru przejdź do kupowania flaszki
zaciśnij prawą rękę na bimbrze
wyjmij bimber
schowaj bimber do lewej kieszeni
(kupowanie flaszki):
wsadź prawą rękę za ladę
sprawdź czy jest tam flaszka
jeśli flaszki nie ma to (kończ zakupy)
wyjmij prawą rękę z za lady
wyjmij zawartość prawej kieszeni
wsadź to co wziąłeś do kasy
wsadź prawą rękę za ladę
weź flaszkę
wyjmij prawą rękę z za lady
wsadź zawartość ręki do prawej kieszeni.
(kończ zakupy)
….. powrót ….

PHP:

Marian robisz tak:

Ktoś ci da coś nie pytaj kto i nie sprawdzaj co, bo jeszcze się coś stanie.
Idziesz z tym do sklepu na pewno trafisz nie ma wielu możliwości
Jeśli są flaszki to bierzesz jedną i dajesz temu kto co dal to coś wcześniej i zostawiasz to coś co dostałeś wcześniej.
Jeśli sprzedawczyni ma za pazuchą flaszkę to jest Hela weź to od niej i daj temu co poprzednio.
Wracasz!

Pascal:

Marian robisz tak:

Możesz mieć do dyspozycji:
Heniek
Hela
flaszka
bimber
kasa
zaczynasz robić
jeśli Heniek ma kasę wówczas
zaczynasz robić
bierzesz kasę od Heniek
idziesz do Hela
jeśli Hela ma do sprzedania flaszkę wówczas
zaczynasz robić
kupujesz flaszkę od Hela
chowasz flaszkę
wracasz do Heniek
oddajesz flaszkę dla Heniek
idziesz do Hela
kończysz robić
jeśli Hela ma bimber wówczas bierzesz bimber od Hela
wracasz do Heniek
kończysz robić
kończysz robić

Perl:

Marian robisz tak:

bierzesz kasę od Heniek
jeśli wciąż nie masz kasy sprzedajesz włosy Heńka.
jeśli wciąż nie masz kasy zatrudniasz się do kopania działki jakiejś babci.
jeśli wciąż nie masz kasy zatrudniasz się Heńka kopania działki jakiejś babci.
idziesz do Sklep, hryyy, bierzesz bimber od Hela, hry, hryy, jeśli masz kasę kupujesz flaszkę.
kaszl ; kaszl
jeśli nie masz bimber wyciągasz tajne zapasy z piwnicy sąsiada.
jeśli nie masz flaszka to podkradasz z domu.
wraczasz

Perl (wersja identyczna)

Marian robisz tak:

b|erzesz kasę od msr Hen|ek
|eśl| wc|ąż n|e masz ka$y sprzeda|esz włosy Heńka.
|f wc|ąż n|e have ka$y zatródn|asz s|ę to kOpan|a dz|ałk| |ak|e|ś babc|.
|eśl| wc|ąż n|e masz ka$y zatrudn|asz s|ę Heńka diging dz|ałk| |ak|e|ś babc|.
|dz|esz do Sklep, hryyy, b|erzesz b|mber od Hela, hry, hryy, |eśl| masz kasę kupu|esz flaszkę.
kaszl ; kaszl
|eśl| n|e masz b|mber wyc|ągasz ta|ne zapasy z p|wn|cy sąs|ada.
|eśl| n|e masz flaszka to podkradasz z house.
wraaaaaaaczasz

What do I need in JDK ?

2008-12-30T00:32:00.036+01:00

I'll put some staff that I found that are much problem from time to time for me.

Lack of methods in File class...
String Comparator...
Thread Statics...
Add .shrink() for StringBuffer & StringBuilder...
1st lvl type validation in standard Generics...
Generics variables...
Support for method to be able to return more than one variable...
Extended printStackTrace...
Read-Only Arrays...
'forget' keyword...

Add to File class:

.copy(File)
.compareFileData(File)
. ...

String Comparator

String Comparator is horrible, it's provide much useless information. Who need 'this.charAt(k)-anotherString.charAt(k)' mixed with 'this.length()-anotherString.length()' ?
Let's see other way to implement comparator:
stringA.compare5StateTo(stringB)

return -2 if stringB is greater than stringA
return -1 if stringB start with stringA
return 0 if stringA equals stringB
return +1 if stringA start with stringB
return +2 if stringA is greater than stringB

Now time I need perform 3 operations to obtain same target.

Thread Statics

Static is global, but allow to make thread static would allow to remove 10~100% synchronization blocks. But it's really hard task and need to be deeply considered. Main problem is to prevent all thread-static data to be created with each thread, and make it available on demand only. Resources pool with auto–pinning to thread would be some solution as well.

Add .shrink() for StringBuffer & StringBuilder

Now time array inside of this Objects can only increase with it's size. This can be problem if happen that for one moment some one will put there a lot of data remove it and skip the object for new one.
Scenario:
We have 100 StringBuffer shared between threads (so we cannot dispose memory).
In 99,9..% of time StringBuffer store 1kb of data and in 0,001% there is 1mb of data.
In that case after some time there will be 100Mb unnecessarily allocated memory.
Other solution is conditional decreasing array size on .remove() (I prefer that).

1st lvl type validation in standard Generics

Personally I used to pass Class<? super ComponentType> in constructor. This solution can to be done easily. With no backward impact.
This cannot be overestimated as one of the best solution to prevent stupid bugs.
Second solution is to add validators on .add(...). More powder full but not as easy to use as previous one.

Generics variables

We have methods, classes, why there are no variables?

Support for method to be able to return more than one variable

Sample:

public static (int:index, double avg) some(...){
  if (isRequested(index)) index = binarySearch(...);
  if (isRequested(avg)){
    ...
  }
}

public static main(...){
  int index;
  index=some(...).index;
  double avg;
  (index=.index,avg=.avg)=some(...);

  some(...).{//here we have access to returned values here
    if (.avg>0){
      ...
    }
  };
}

Notice that isRequested() is a method which tells us if parameter needs to be returned.

Simple tuples are bad, the same as a return by reference because you need to remember parameters' sequence. That's why, even if we are able to return more than one value, we may have implemented the same method in a few different ways (and it's not so rare) depending on what we need.

You may do not see the power of this solution, however, when you analyze the given case you will see that the return values do not need to be counted if a used method is not requested for them.

Creating a new Class for that purpose is not a solution as well. If you analyze this you will see that it is not so rare to define unnecessary classes for each method ( or most of them) that do not allow us to tell if we need a full result or only part of it.

Have you ever wandered what you return when you add many elements to container? It really would be nice to get back:

Did even wander what would u return in case that when u add many elements to container. What would be nice to get back?

number of added elements
number of not added elements
list of added elements
list of not added elements

Of course, overkill might be a bad solution, as always.
I will describe it in more details on free time.

Extend printStackTrace

Allow to print stack trace only from throw exception point to exception handling point.

Read-Only Arrays

It's really hard to pinpoint what solution would be best.
At first I wander about 'context' access like:

Type[] readOnly =array.getReadOnly(from,to);
array[from] = t;
if (readOnly[0]==t) is always true

This would be peaty powder full solution, and it would allow to write more secure programs. Unfortunately every operation on arrays could bring unexpected problems if some one would use base array as buffer. Is that clear?

System.arraycopy(readOnly, srcPos, array, destPos, length);

We need check if readOnly and array point same space!

Other solution is about giving always read only arrays:

Type[] readOnly =array.copyAsReadOnly(from,to) array[from] = t;
if (readOnly[0]==t) can be false

'forget' keyword

with 'forget':

String data =readLine();
data = operate(data);
boolean isOk = data.contains(“contains”);
forget data;
// here we do not have access to data object

now time:

boolean isOk;
{
String data =readLine();
data = operate(data);
isOk = data.contains(“contains”);
}
// here we do not have access to data object

Null handling: Small language changes on JDK 7

2008-12-28T19:03:00.000+01:00

The idea is about allowing people to handle null object situation as easy as possible (here by new operator). And I agree with that since even before.

Discussion can be seen on:

Current (sample) implementation use '?.' as operator, but in my opinion '.?.' would be more appropriate, because '?' following directly by some name can be hardly noticed when we only inspect code. Example:

This attribute can be important for people who did not used to this operator.

Autoboxing issues

Most disputation about this operator connects with autoboxing issue where options are:

Forbid autoboxing that is simple and should not bring any problems, as we still have if and (?:).
Turn on autoboxing that can kill program efficiency and through exception.
Turn on autoboxing only if object is a target.
Add other operator to this one.

Notice that forbidding autoboxing is a good solution because does not cause unnecessary syntax complication. Autoboxing (if object is a target) responses to operator logic and what's important, it should not cause any additional bad impacts on program logic. What more adding another operator may drastically increase code complication.

What did we loose with hiding object's address?

2008-12-28T15:45:00.027+01:00

Let's list advantages:

More control over application security! Mostly, it's impossible to get forbidden information.
Information has to be delivered overtly.
Garbage collector can work easier, more reliable and it's not so rare to be faster than manual deallocating memory. What's more, programmers have more time for code quality and efficiency.

Disadvantages:

Programmer is obliged to predict which data will be needed in future.
Natural (physical) objects order has been lost.

Let's look closer to consequences of natural ordered lost. At first, it may seem like there is no negative impact and for most common problems it's truth.
Secondly, after a closer look we may notice that accessing objects by address is not necessary. However, there are some groups of algorithms that need some kind of order, like binary-search. For example:
We have two collections of objects and we wand to do some operation on them like: intersection.

How big is that task (approximately)?
n : size of 1st collection
m : size of 2nd collection
k : average size important information in single object

Now time in java in == sense :

n*m

Now time in java in .equals(...) sense :

n*m*k

Now time if programmer provide Comparator (it might be impossible):

min(n,m)*log(max(n,m))*k
+time to write valid comparator and rewrite it on any data structure change.
+sorting time n*log(n)*k + m*log(m)*k (this do not have to be done each time)

Same task with some (like physical in memory) order:

min(n,m)*log(max(n,m))
+sorting time n*log(n) + m*log(m) (this do not have to be done each time)

So if we get some data (static for object) we would be able to make some algorithms real-time. For example, I may say that a simple optimalization of searching in a dictionary can widely decrease server's usage. For me, it was 30%.
It does not have to be address, Handle^someRandom is appropriate as well.
Solving this problem would not make the impact of all Java community, but it would allow to make reliable and fast tools for programmers that would be a great advantage.

The main problem is that object address in Java is not constant, so I'll need to check if there are some static handlers that would allow to make one step forward after successful step back.

Of course, I disagree with allowing to access object with handlers.

For-each loop: Small language changes on JDK 7

2008-12-27T12:07:00.041+01:00

Lets talk about:

For-each loop over a Map
Control over for-each loops (index/remove)

At first, I asked myself if it's possible to obtain those targets just by a simple code.?
It's not so clear for all, but answer is YES.
However, there are still some small languages changes that would improve programming quality.

Indexing control over for-each loops

What would be the effect of adding indexing directly to for-each loop?

Language syntax need to be extended.
While loop can iterate more than MAX_INT there might be possibility to obtain exception (IndexOutOfBoundsException)
We will not be able to obtain some more complicated indexes (like even numbers, numbers started from 333, ...)
It's higher probability that when people get used to it they will want a more complicated syntax

What is the impact of other solutions?

Implement IntIterator, LongIterator
Possible to extend for-each loop with increment (initialization) expression for (String s:array; intIterator.next()) { ... }
We would be able to index everything
No negative impact during extending loop statement
We could selectively index elements

Sample:

/*
* @author Marek Kozieł
*/
public interface IntIterator extends Serializable {

  /*
   * Returns <tt>true</tt> if the iteration has more elements. (In other words, returns <tt>true</tt> if <tt>next</tt> would return an element rather than throwing an exception.)
   *
   * @return <tt>true</tt> if the iterator has more elements.
   */
  public boolean hasNext();

  /*
   * Returns the next element in the iteration.
   *
   * @return the next element in the iteration.
   * @exception NoSuchElementException iteration has no more elements.
   */
  public int next();

  public static class IntIteratorImpl implements IntIterator {

    public IntIteratorImpl() {
      last = 0 - 1;
    }

    public IntIteratorImpl(int starValue) {
      if (starValue == Integer.MIN_VALUE) { throw new IllegalArgumentException("Start value(" + starValue + ") is unsupported"); }
      last = starValue - 1;
    }

    private int  last  = 0;

    @Override
    public final boolean hasNext() {
      return (last != Integer.MAX_VALUE);
    }

    @Override
    public final int next() {
      if (last == Integer.MAX_VALUE) { throw new NoSuchElementException(); }
      return (last++);
    }

  }

}

Removing control over for-each loops

What would be the effect of adding indexing directly to for-each loop?

Possible, but for loop should know if it's iterate through Iterator.
Syntax need to be extended like:
for.remove(...).

What is the impact of another solutions?
Allow for-each loop to iterate through Iterator not only through Iterable!

Will allow use more complicated Iterators!
Container would be able to return easily few iterators (Map iterator over: keys, values, distinct values, keys & values ) without complicated objects structure.
No syntax change is required!

For-each loop over a Map

What would be the effect of allowing loop to work on Map-s?

Language would become dependent from Map implementation
Syntax need to be extended!

What is the impact of another solution?
I personally use solution that allow me to iterate through my own Map-s for a few months. Container is just able to return a few different iterators (see previous solution).

Summary

Language changes can have high negative impact.
Making language dependent from one implementation will skip people from implemending better ones.

Another sugestion: Allow for-each loop iterator through more than one container

Effect:

Syntax need to be extended:
for(String s: array,collection,iterator)
if (for.current==array) { ... }
Skipping people from writing a few loops with the same content!

String switch: Small language changes on JDK 7

2008-12-26T16:58:00.041+01:00

According to Stephen Colebourne's Weblog: JDK 7 language changes - JavaEdge votes!
Allowing put String into switch statement is OK for me. But I cannot agree with placing that into JDK.
You can ask why. For me it's quite simple. Java is Object oriented language, while this change we make it more String or 'Script' oriented.

I need to suggest other solution. Allow to use switch with any kind of object.
In that case we would have add 2 or more switch statement.

How would that look?

Base Interfaces:

public interface Equally<Type> {
  /**
   * @return true if objects are equal
   */
  boolean equal(Type object, Type other);
}

public interface EquallyAsymmetric<Source,Target> {
  /**
   * @return true if objects are equal
   */
  boolean equal(Source source, Target target);
}

public interface ComparatorAsymmetric<Source,Target> {
int compare(Source source, Target target);
}

Switch:

switch ( Expression : Equally) SwitchBlock

switch ( Expression : EquallyAsymmetric) SwitchBlock

switch ( Expression : Comparator) SwitchBlock

switch ( Expression : ComparatorAsymmetric) SwitchBlock

How would that work?

public class SomeData {

  public SomeData(String key, Data data) {
    super();
    this.key = key;
    this.data = data;
    // validation
  }

  private Data data;

  public final String key;

  public final static Equally<SomeData> equally = new EquallySomeData();

  public final static EquallyAsymmetric<SomeData, String> equallyAsymmetric = new EquallyAsymmetricSomeData();  ;

  public final static Comparator<SomeData> comparator = new ComparatorSomeData();

  private static class ComparatorSomeData implements Comparator<SomeData> {
    @Override
    public int compare(SomeData o1, SomeData o2) {
      return o1.key.compareTo(o2.key);
    }

  };

  private static class EquallyAsymmetricSomeData implements EquallyAsymmetric<SomeData, String> {
    @Override
    public boolean equal(SomeData source, String target) {
      return source.key.equals(target);
    }
  };

  private static class EquallySomeData implements Equally<SomeData> {
    @Override
    public boolean equal(SomeData object, SomeData other) {
      return object.key.equals(other.key);
    }
  }

}

Equally sample:

SomeData getMatch(String key)
{
switch (new SomeData(key,null):SomeData.equally) {
    case someData:
      break;
    default:
      break;
    }
}

Equally asymmetric sample:

SomeData getMatch(String key)
{
switch (new SomeData(key,null):SomeData.equallyAsymmetric ) {
case „some”:
break;
default:
break;
}
}

Comparator sample:

SomeData getMatch(String key)
{
switch (new SomeData(key,null):SomeData.equallyAsymmetric ) {
    case lower <= ... < upper:
      break;
    default:
      break;
    }
}

Asymmetric look on operation allow to keep encapsulation while perform operation we need.

@see Using Strings and Objects in Switch case statements

Is Javadoc killing program evolution?

2008-12-19T20:15:00.014+01:00

Hello!

When I found what Javadoc was, I was totally impressed. The way that it made code more readable was increadible for me. So it didn't take too much time until I used to comment each class, method and parameter. I did that in one project and was satisfied with results. However, in the second one I found a problem that improving Javadoc after rebuilding some parts of code took even 3x more time and efford than it should have. That's why nowadays, I'm used to providing comments as little as possible. This doesn't mean that I avoid using Javadoc. I just try to make it as brief as possible, omitting as much as I can without harming a project.

What is the reason?

Let's use a standard library java.util.Arrays as an example in which each comment is repeated 1~8+ times with immortal [CTRL +C] [CTRL +V].
In code I use approximately 30% of my classes, 30% of base types & classes, 30% of generic classes. For those generics there's also no dedicated tag to describe parameter type for generic. What's more, if I declare generic, there is no way to make a nice description for it as well (this include simple arrays too).

What do we lose?

Each time when we make some changes, we need to search for all comments and fix them.
Even if all code works fine and we want only to improve documentation, we need to search all places where documentation is pleased.
If we use generics, we need to search the way to describe it clearly and we also should have a hope that someone reading it will understand comments in the same (our) way.

What do I expect?

Javadoc support for convention. I want to be able to define one describe for parameter, method, variable, ... and reuse it.
Reusing docs from implemented interfaces (classes).
Being able to describe generic once I define and use them.
Being able to call direct parameters(safe for refactor).
Support for multi-language comments

What would that give to me?

Evolution Javadoc in the same speed as code.
Improvement in usage. It would direct people to use the same names for the same aims.

Sample:

/**
* ...
* @paramconv element element that will be proceed
* @methodconv addFromCollection add all elements from given container
* @gen Unit component for this class ...
* @author Marek Kozieł
*/
public abstract class DocSample<Unit> implements List<Unit> {

  /**
   * ...
   */
  class Entry<K, V> {

  }

  /**
   * @gen ArrayList#1 pair key and value
   * @get ArrayList#1#K Key for list of units
   * @gen ArrayList#1#V List of units
   * @get ArrayList#1#2#1 unit ...
   */
  ArrayList<Entry<String, List<Unit>>>  list;

  /**
   * @methodinherit
   * {@link #add(Object)#index} index at which to insert the first element from the specified collection
   * @paraminherit index
   * @param element
   */
  @Override
  public void add(int index, Unit element) {
    // TODO Auto-generated method stub
  }

  /**
   * @methodconv
   * @param iterator ...
   */
  public int addFromCollection(Iterator<? extends Unit> iterator) {
    int count = 0;
    while (iterator.hasNext()) {
      count += (add(iterator.next())?1:0);
    }
    return count;
  }

  /**
   * @methodconv
   * @param iterable ...
   */
  public int addFromCollection(Iterable<? extends Unit> iterable) {
    return addFromCollection(iterable.iterator());
  }

  /**
   * @methodconv
   * @param array ...
   */
  public <EUnit extends Unit> int addFromCollection(EUnit[] array) {
    int count = 0;
    for (EUnit eUnit : array) {
      count += (add(eUnit)?1:0);
    }
    return count;
  }

  /**
   * ...
   * @paramconv element
   */
  abstract public boolean add(Unit element);

  /**
   * ...
   * @paramconv element
   */
  abstract public int remove(Unit element);

}

Meaning:

@gen : represent generic parameter
@paramconv : get describe from same name @paramconv from class comment.
@methodconv : get describe from same name @methodconv from class comment.
@methodinherit : get describe from implemented Interface / Class from override method
@methodinherit(Interface/Class) : get describe from given implemented Interface / Class from override method

@paraminherit index ...
@paraminherit(Interface/Class) index ..

For
ArrayList<Entry<String, List<Unit>>> list;
describe would look like:

ArrayList< ... > :
-Entry< ... , ... > : pair key and value
--String : Key for list of units
--List< ... > : List of units
---Unit : unit ...