Programming, graphics, games, media, C++, Windows, Internet and more...
Entries for tag "java", ordered from most recent. Entry count: 7.
# jEdit Doesn't Start
Sun
30
Oct 2011
jEdit is a free, multi-platform and my favorite text editor intended for programmers. Some time ago I encountered a problem with it, which repeated again today. So in case you also use this editor or found this post by searching Google, here is the solution:
Problem: jEdit (on Windows) doesn't start. Process is created and exists in memory, but it does nothing and shows no windows, so the only thing you can do is terminating it.
Solution: Terminate the jEdit process and the process of Java virtual machine, then browse to your user directory (like "C:\Users\Adam Sawicki" on my Windows 7) and delete the following small file in a sudirectory: ".jedit\server". After that you will be able to successfully start jEdit.
Comments | #java #tools #windows Share
# Too Low Level and Too High Level Abstraction
Fri
15
Jul 2011
Programmers fascinated by object-oriented methodology love the idea of abstraction and generalization, but others - especially those interested in data-oriented design - consider "premature generalization" as a big anti-pattern. I prefer the latter approach, so as I recently learn a little bit of Java, including Servlers and JSP, I feel terrified of how its API looks like. Let me explain...
Today an idea came to my mind that an API can be too abstract (general, universal) at low level or high level. The most abstract low-level API looks like this:
int write(void *buf, int bytes);
int read(void *buf, int bytes);
It's so general and universal that it would fit anywhere, but on the other hand it doesn't provide anything specific. It's just a very narrow pipe we have to pass all our data through. Of course this method is sometimes useful. For example that's the way we transfer data over network. But we do it using some specific protocol so it's reasonable to define a higher-level API with some objects that encapsulate concepts specific to that protocol, just like cURL implements HTTP, FTP and other network protocols on top of network sockets.
Let's compare some details from two APIs. A socket can have additional options that can be set. There are different options for different kinds of sockets and they have different types - some of them are bools, others are ints. But there is only one function to set such options - setsockopt:
int setsockopt(SOCKET s, int level, int optname, const char *optval, int optlen);
Objects in POSIX Threads API also can have additional attributes, but there are specific functions to set them, like in the example below. Which way do you prefer?
int pthread_attr_setdetachstate(pthread_attr_t *attr, int detachstate);
int pthread_attr_setstacksize(pthread_attr_t *attr , size_t stacksize);
But excessive abstraction can also go too far the other way. That's what I see in Java API. I mean, these who code a lot in this language certainly can "feel" the sense in this approach, but for me it's almost ridiculous. Not only every part of the Java API has dozens of small classes with not much more than simple getName/setName methods and there is an interface for everything just like people were afraid of using real classes, but lots os stuff is refered by strings. I'd say Java is so high level that it's not only a strongly-typed language, it's stringly-typed language. Lots of classes implementing some interface can be registered in some global registry under its name so an instance can be constructed without ever refering to the real class, like: new SomeSpecificClass().
Probably the most grotesque example I saw today is java.naming package. Including its subpackages, it contains about hunred of classes and interfaces. But there is more than this. It's the whole great body of knowledge called JNDI (Java Naming and Directory Interface) with long tutorials and lots of concepts to understand, like Context, InitialContext, Directory, Service Provider, Lookup, Names, Composite Names, Compound Names, Naming System, Federations and so on... All this just to provide an abstract interface for a tree of any objects referred by name, so that disk files and directories can be accessed same way as data received with LDAP or some global variables defined in an XML file. Do anyone really needs that? The javax.naming.Context interface is not far from what would be the ultimate high level abstraction:
interface SuperAbstractEverything {
public Object getObject(String namePathIdOrWhatever);
};
Comments | #java #software engineering Share
# Prezentacja o J2ME
Sun
30
Dec 2007
Właśnie skończyłem pisanie mojej pracy egzaminacyjnej na jeden z przedmiotów na studiach. Jest to prezentacja do wykładu na temat J2ME, czyli programowania w języku Java midletów na komórki. Omawia bardziej lub mniej dokładnie wszystkie moduły wchodzące w skład standardu MIDP 2.0. Ma 98 slajdów. Nie wiem, czy z samej prezentacji - nie słysząc wykładu - można się dużo nauczyć, ale zapraszam do przeglądania:
Comments | #productions #studies #mobile #java #teaching Share
# Komórki, J2ME, M3G
Tue
25
Dec 2007
Dobra, poddaję się. Nie chce mi się już zajmować programowaniem na komórki. To jest fajne, ale mam też inne rzeczy w planach. Poznałem MIDP 2.0 i M3G dość dokładnie, zwłaszcza od strony teoretycznej. W praktyce dobił mnie problem z siatką o aktualizowanej dynamicznie geometrii (początkowo ma wszystkie wierzchołki w (0,0,0)), która na emulatorze działa dobrze, a na moim telefonie znika, kiedy tylko punkt (0,0,0) przestaje być w polu widzenia.
Z tego mojego "zajmowania się" pozostaną dwie pożyteczne rzeczy. Pierwsza to CapsViewer - mały midlet do pokazywania możliwości sprzętowych telefonu, na którym działa (parametry wyświetlacza, ilość pamięci, możliwości grafiki 3D itd.).
Druga to diagramy klas, który pomogły mi wyobrazić sobie organizację API M3G. Ta biblioteka jest przemyślana, przyjemna, obiektowa i wysokopoziomowa, ale co za tym idzie składa się z bardzo wielu drobnych, powiązanych ze sobą klas. Może komuś kiedyś przydadzą się te diagramy...
Wszystko
Same agregacje
Same dziedziczenia
Comments | #rendering #java #mobile Share
# Nauka M3G
Fri
21
Dec 2007
Uczę się ostatnio M3G (Mobile 3D Graphics API). To jest biblioteka do mobilnej grafiki 3D wspierana przez niektóre komórki. Oprócz możliwości rysowania wprost oteksturowanych trójkątów posiada również API wysokopoziomowe z grafem sceny zawierającym siatki, kamery i światła. Wspiera animację na klatkach kluczowych oraz szkieletową. Ogólnie jest bardzo przyjemna.
Ma własny format pliku potrafiący przechowywać cały graf sceny wraz z teksturami. Długo szukałem sposobu na wyeksportowanie do niego czegoś z Blendera. Byłem nawet gotów napisać własny eksporter. Na szczęście dzisiaj po rozmowie na IRC-u z ludźmi z kanału #blendercoders przejrzałem źródło istniejącego eksportera M3G do Blendera i udało mi się go wreszcie nakłonić do prawidłowego działania. Tajemnicą nakłonienia go do eksportowania koordynatów tekstur jest, jak się okazuje, zaznaczenie w ustawieniach materiału niepozornego przycisku TexFace.
Co do samego midletu, na razie napisałem tyle :)
Comments | #rendering #java #mobile Share
# Mobile Galaxy
Thu
06
Dec 2007
Nic nie pisałem od tak dawna, bo nie miałem dostępu do Internetu przez kilka dni. W tym czasie zacząłem z nudów uczyć się programowania w J2ME na komórki. Moja pierwsza produkcja to małe demo graficzne - Mobile Galaxy. Udostępniam je razem z kodem źródłowym.
Comments | #mobile #java #productions #rendering Share
# Processing
Thu
23
Aug 2007
Processing 1.0 (BETA) - pod tą dziwną nazwą kryje się ciekawa zabawka - prosty język programowania oraz proste IDE, w którym można eksperymentować z grafiką 2D i 3D pisząc efekty, animacje i proste gry. Jest napisane jest w Javie i do Javy kompiluje napisany kod. Sam język też jest podobny do Javy. Pozwala na eksport swojego dzieła do apletu lub aplikacji Java. W porównaniu z Evaldraw wypada moim zdaniem na plus, bo choć wydajność jest dużo gorsza, to całe środowisko jest wygodniejsze w obsłudze, prostsze w użyciu, lepiej dopracowane i lepiej udokumentowane. Oto co udało mi się stworzyć:
