Java notes

From Helpful
Jump to: navigation, search

(This page is currently written from a view of someone who has coded in Java before, but not recently, and mostly for university courses, so one not too informed of more complex libraries and concepts Java has introduced since, or overly informed over those always present)


Memory size settings (mostly heap)

This article/section is a stub — probably a pile of half-sorted notes, is not well-checked so may have incorrect bits. (Feel free to ignore, fix, or tell me)

Java has its own heap management, which works with a fixed amount of memory that you have to give it. You can limit this amount of system heap, and in fact the default maximum is a fairly low figure.

This can cause you to run into java.lang.OutOfMemoryError exceptions, or just less in-Java memory cacheing.


When you want a particular instantiation of java to be able to use a lot of memory, you primarily want to set the maximum that the VM can use for heap allocations:

  • -Xmx, the maximum heap size.
    • The default is usually something like 64M
    • Note that on 32-bit, more than 1..3GB may be denied (practically often under ~2.5GB)
    • For sone JVMs, you may need to specify working in 64-bit before you can allocate more


You may also care about:

  • -Xms, the initial heap size - this amount of memory will be immediately allocated to the VM heap.
    • The default is something like 4M
    • You can raise this, which if you know that at (or soon after) startup it needs to grow to something on the order of Xmx - this will save time reallocating.
    • For the same reason, in various real-world it makes little practical difference


And possibly:

  • -Xss, the stack size.
    • Generally you don't need to touch this.
    • (there may also be system limits(verify)) (conflicting reports on defaults)


  • -Xmn
    • ... but you need to dive into java memory management to understand how that can be useful.


See also:

Some Java terms

(...some glossary because these have no recognizable meaning from outside of Java)

JavaBeans and Enterprise JavaBeans

This article/section is a stub — probably a pile of half-sorted notes, is not well-checked so may have incorrect bits. (Feel free to ignore, fix, or tell me)

A bean can be described as a reusable component that can be tweaked in an IDE (as opposed to only in code).

A class that wants to be some type of bean must follow various conventions - naming, construction, and bean-type-specific behaviour.


JavaBeans - arguably the most basic case of a bean, allowing IDEs integration. Used e.g. in Swing, AWT, SWT.


Enterprise JavaBean (EJB) - apparently used when the intent is to encapsulate business logic in server-side code(verify)


Apparently POJO (Plain Old Java Object) is a term introduced to refer to something that is not a bean.

See also:

NetBeans

This article/section is a stub — probably a pile of half-sorted notes, is not well-checked so may have incorrect bits. (Feel free to ignore, fix, or tell me)

(Here partly to point out that this has little to do with javabeans)

Usually refers to one of two things:

  • the idea of packing modules in a java archives to act as (not-so-entangled) libraries (similar to JAR files), and can (also) contain executable applications.
  • the Netbeans IDE (supporting various languages beyond Java), which apparently uses Netbeans archives, but is otherwise fairly unrelated.


See also:


JAR, WAR, EAR

This article/section is a stub — probably a pile of half-sorted notes, is not well-checked so may have incorrect bits. (Feel free to ignore, fix, or tell me)


http://en.wikipedia.org/wiki/JAR_(file_format)

http://en.wikipedia.org/wiki/WAR_(Sun_file_format)


Also:

http://en.wikipedia.org/wiki/EAR_(file_format)

http://en.wikipedia.org/wiki/Resource_Adapter (sometimes RAR, but not to be confused with the general-purpose RAR archive format)

Servlets and such

This article/section is a stub — probably a pile of half-sorted notes, is not well-checked so may have incorrect bits. (Feel free to ignore, fix, or tell me)

A Java servlet is a Java object that uses a particular request-response programming model, usually used specifically for web requests.


A system utilizing Java servlets will have a servlet container, the thing the servlets are managed by (often a standalone daemon) which shows a page using the compiled servlet classes.

Java servlets are Java code, but since Java is so verbose, these are usually generated automatically based on JavaServer pages (JSP), a web templating language for servlets.

As such, servlet containers will rebuild servlets classes from JSP if and when necessary.


Some common web containers include Jetty, Apache Tomcat, Resin. See also http://en.wikipedia.org/wiki/List_of_Servlet_containers


See also:


Daemons, containers, servlets, JSP, etc.

This article/section is a stub — probably a pile of half-sorted notes, is not well-checked so may have incorrect bits. (Feel free to ignore, fix, or tell me)

Roughly speaking...


A container is the part of a web server that talks to servlets (and often JSP) via their preset interfaces. (Usually adding multithreading, possibly security, and such)

Common installable packages (say, Tomcat, Jetty, Resin, JBoss) are also sometimes referred to as containers, because their primary function is providing containers to host servlets or JSP.

Also :

  • Servlet container refers to the ability to host servlets(verify)
  • Web container usually refers to things that can do servlets and JSP(verify)
  • Application server usually refers to things that can do servlets, JSP, and more enterprisy things.(verify)

...but know these terms are somewhat fuzzy and commonly abused.



A servlet is an object conforming to the servlet API. It has a lifecycle inside a container.


To a container, JSP is just another API. JSP gives a setup that is more document-centric (than the comparatively app-centric servlet setup). The two are complementary in that you'll just choose the one that suits you best for the specific thing to serve. They are indeed frequently mixed.


See also:


JWS

This article/section is a stub — probably a pile of half-sorted notes, is not well-checked so may have incorrect bits. (Feel free to ignore, fix, or tell me)

Java Web Start (JWS, JavaWS, JAWS) exists to launch java apps via the web browser, separate from the frame in a local VM.

By default they run in restricted mode. Signed apps can run as local apps.


JWS can also be used to start packaged applets, in case you have them (it's generally not so useful to use JWs for only applets).


JWS can be useful for apps that are updated a lot.


http://en.wikipedia.org/wiki/Java_Web_Start


JNLP

Java Network Launching Protocol (JNLP) is the (XML-serialized) part of JWS that specifies how to launch apps/applets.

Apps/applets can fetch these values via System.getProperty()


From some views, JNLP is synonymous with JWS, or rather, JWS is the most common client that is called in reaction to seeing JNLP.(verify)


http://en.wikipedia.org/wiki/Java_Web_Start#Java_Network_Launching_Protocol_.28JNLP.29




Java Network Launching Protocol (JNLP)