java - Examples of GoF Design Patterns - Stack Overflow

java - Examples of GoF Design Patterns - Stack Overflow

Creational patterns

Abstract factory (recognizeable by creational methods returning the factory itself which in turn can be used to create another abstract/interface type)

• javax.xml.parsers.DocumentBuilderFactory#newInstance()
• javax.xml.transform.TransformerFactory#newInstance()
• javax.xml.xpath.XPathFactory#newInstance()

Builder (recognizeable by creational methods returning the instance itself)

• java.lang.StringBuilder#append() (unsynchronized)
• java.lang.StringBuffer#append() (synchronized)
• java.nio.ByteBuffer#put() (also on CharBuffer, ShortBuffer, IntBuffer, LongBuffer,FloatBuffer and DoubleBuffer)
• javax.swing.GroupLayout.Group#addComponent()
• All implementations of java.lang.Appendable

Factory method (recognizeable by creational methods returning an implementation of an abstract/interface type)

• java.util.Calendar#getInstance()
• java.util.ResourceBundle#getBundle()
• java.text.NumberFormat#getInstance()
• java.nio.charset.Charset#forName()
• java.net.URLStreamHandlerFactory#createURLStreamHandler(String) (Returns singleton object per protocol)

Prototype (recognizeable by creational methods returning a different instance of itself with the same properties)

• java.lang.Object#clone() (the class has to implement java.lang.Cloneable)

Singleton (recognizeable by creational methods returning the same instance (usually of itself) everytime)

• java.lang.Runtime#getRuntime()
• java.awt.Desktop#getDesktop()

---

Structural patterns

Adapter (recognizeable by creational methods taking an instance of different abstract/interface type and returning an implementation of own/another abstract/interface type which decorates/overrides the given instance)

• java.util.Arrays#asList()
• java.io.InputStreamReader(InputStream) (returns a Reader)
• java.io.OutputStreamWriter(OutputStream) (returns a Writer)
• javax.xml.bind.annotation.adapters.XmlAdapter#marshal() and #unmarshal()

Bridge (recognizeable by creational methods taking an instance of different abstract/interface type and returning an implementation of own abstract/interface type which delegates/uses the given instance)

• None comes to mind yet. A fictive example would be new LinkedHashMap(LinkedHashSet<K>, List<V>) which returns an unmodifiable linked map which doesn't clone the items, but uses them. The java.util.Collections#newSetFromMap() and singletonXXX() methods however comes close.

Composite (recognizeable by behavioral methods taking an instance of same abstract/interface type into a tree structure)

• java.awt.Container#add(Component) (practically all over Swing thus)
• javax.faces.component.UIComponent#getChildren() (practically all over JSF UI thus)

Decorator (recognizeable by creational methods taking an instance of same abstract/interface type which adds additional behaviour)

• All subclasses of java.io.InputStream, OutputStream, Reader and Writer have a constructor taking an instance of same type.
• java.util.Collections, the checkedXXX(), synchronizedXXX() and unmodifiableXXX()methods.
• javax.servlet.http.HttpServletRequestWrapper and HttpServletResponseWrapper

Facade (recognizeable by behavioral methods which internally uses instances of different independent abstract/interface types)

• javax.faces.context.FacesContext, it internally uses among others the abstract/interface types LifeCycle, ViewHandler, NavigationHandler and many more without that the enduser has to worry about it (which are however overrideable by injection).
• javax.faces.context.ExternalContext, which internally uses ServletContext,HttpSession, HttpServletRequest, HttpServletResponse, etc.

Flyweight (recognizeable by creational methods returning a cached instance, a bit the "multiton" idea)

• java.lang.Integer#valueOf(int) (also on Boolean, Byte, Character, Short and Long)

Proxy (recognizeable by creational methods which returns an implementation of given abstract/interface type which in turndelegates/uses a different implementation of given abstract/interface type)

• java.lang.reflect.Proxy
• java.rmi.*, the whole API actually.

The Wikipedia example is IMHO a bit poor, lazy loading has actually completely nothing to do with the proxy pattern at all.

---

Behavioral patterns

Chain of responsibility (recognizeable by behavioral methods which (indirectly) invokes the same method in anotherimplementation of same abstract/interface type in a queue)

• java.util.logging.Logger#log()
• javax.servlet.Filter#doFilter()

Command (recognizeable by behavioral methods in an abstract/interface type which invokes a method in an implementation of adifferent abstract/interface type which has been encapsulated by the command implementation during its creation)

• All implementations of java.lang.Runnable
• All implementations of javax.swing.Action

Interpreter (recognizeable by behavioral methods returning a structurally different instance/type of the given instance/type; note that parsing/formatting is not part of the pattern, determining the pattern and how to apply it is)

• java.util.Pattern
• java.text.Normalizer
• All subclasses of java.text.Format
• All subclasses of javax.el.ELResolver

Iterator (recognizeable by behavioral methods sequentially returning instances of a different type from a queue)

• All implementations of java.util.Iterator (thus among others also java.util.Scanner!).
• All implementations of java.util.Enumeration

Mediator (recognizeable by behavioral methods taking an instance of different abstract/interface type (usually using the command pattern) which delegates/uses the given instance)

• java.util.Timer (all scheduleXXX() methods)
• java.util.concurrent.Executor#execute()
• java.util.concurrent.ExecutorService (the invokeXXX() and submit() methods)
• java.util.concurrent.ScheduledExecutorService (all scheduleXXX() methods)
• java.lang.reflect.Method#invoke()

Memento (recognizeable by behavioral methods which internally changes the state of the whole instance)

• java.util.Date (the setter methods do that, Date is internally represented by a long value)
• All implementations of java.io.Serializable
• All implementations of javax.faces.component.StateHolder

Observer (or Publish/Subscribe) (recognizeable by behavioral methods which invokes a method on an instance of anotherabstract/interface type, depending on own state)

• java.util.Observer/java.util.Observable (rarely used in real world though)
• All implementations of java.util.EventListener (practically all over Swing thus)
• javax.servlet.http.HttpSessionBindingListener
• javax.servlet.http.HttpSessionAttributeListener
• javax.faces.event.PhaseListener

State (recognizeable by behavioral methods which changes its behaviour depending on the instance's state which can be controlled externally)

• javax.faces.lifecycle.LifeCycle#execute() (controlled by FacesServlet, the behaviour is dependent on current phase (state) of JSF lifecycle)

Strategy (recognizeable by behavioral methods in an abstract/interface type which invokes a method in an implementation of adifferent abstract/interface type which has been passed-in as method argument into the strategy implementation)

• java.util.Comparator#compare(), executed by among others Collections#sort().
• javax.servlet.http.HttpServlet, the service() and all doXXX() methods takeHttpServletRequest and HttpServletResponse and the implementor has to process them (and not to get hold of them as instance variables!).
• javax.servlet.Filter#doFilter()

Template method (recognizeable by behavioral methods which already have a "default" behaviour definied by an abstract type)

• All non-abstract methods of java.io.InputStream, java.io.OutputStream, java.io.Readerand java.io.Writer.
• All non-abstract methods of java.util.AbstractList, java.util.AbstractSet andjava.util.AbstractMap.
• javax.servlet.http.HttpServlet, all the doXXX() methods by default sends a HTTP 405 "Method Not Allowed" error to the response. You're free to implement none or any of them.

Visitor (recognizeable by two different abstract/interface types which has methods definied which takes each the otherabstract/interface type; the one actually calls the method of the other and the other executes the desired strategy on it)

• javax.lang.model.element.AnnotationValue and AnnotationValueVisitor
• javax.lang.model.element.Element and ElementVisitor
• javax.lang.model.type.TypeMirror and TypeVisitor

share

edited Apr 6 '13 at 20:18

community wiki 25 revs, 3 users 100%BalusC

Debugging Java Web Start

Steps for debugging a java web start application
Step 1. Open a command prompt window (Windows)
Step 2. set JAVAWS_TRACE_NATIVE=1
Step 3. set JAVAWS_VM_ARGS=-Xdebug -Xrunjdwp:transport=dt_socket,server=y,suspend=y,address=8000
Step 4. Run javaws http://server:port/appname/application.jnlp
Step 5. Goto eclipse debug configuration screen and create a new Remote Java Application debug configuration
Step 6. Under the connection properties, specify the hostname of the machine where you have started the terminal and port as 8000, apply and click debug

Understanding Weak References in Java

Excerpted from: https://weblogs.java.net/blog/enicholas/archive/2006/05/understanding_w.html

A weak reference, simply put, is a reference that isn't strong enough to force an object to remain in memory. Weak references allow you to leverage the garbage collector's ability to determine reachability for you, so you don't have to do it yourself. You create a weak reference like this:

WeakReference<Widget> weakWidget = new WeakReference<Widget>(widget);

and then elsewhere in the code you can use weakWidget.get() to get the actual Widget object. Of course the weak reference isn't strong enough to prevent garbage collection, so you may find (if there are no strong references to the widget) that weakWidget.get()suddenly starts returning null.

WeakHashMap works exactly like HashMap, except that the keys (not the values!) are referred to using weak references. If a WeakHashMap key becomes garbage, its entry is removed automatically. If you're following the standard convention of referring to your maps via the Map interface, no other code needs to even be aware of the change and requires no changes other than the switch fromHashMap to a WeakHashMap.

Difference degrees of Weakness

1. Soft references -



A soft reference is exactly like a weak reference, except that it is less eager to throw away the object to which it refers. An object which is only weakly reachable (the strongest references to it are WeakReferences) will be discarded at the next garbage collection cycle, but an object which is softly reachable will generally stick around for a while.


SoftReferences aren't required to behave any differently than WeakReferences, but in practice softly reachable objects are generally retained as long as memory is in plentiful supply. This makes them an excellent foundation for a cache for the use case of image caching described below for instance.





Suppose you have an application which has to work with user-supplied images. Naturally you want to cache these images, because loading them from disk is very expensive and you want to avoid the possibility of having two copies of the (potentially gigantic) image in memory at once.


Because an image cache is supposed to prevent us from reloading images when we don't absolutely need to, you will quickly realize that the cache should always contain a reference to any image which is already in memory. With ordinary strong references, though, that reference itself will force the image to remain in memory, which requires you (just as above) to somehow determine when the image is no longer needed in memory and remove it from the cache, so that it becomes eligible for garbage collection. Once again you are forced to duplicate the behavior of the garbage collector and manually determine whether or not an object should be in memory.



2. Phantom references - A phantom reference is quite different than either SoftReference or WeakReference. Its grip on its object is so tenuous that you can't even retrieve the object -- its get() method always returns null. The only use for such a reference is keeping track of when it gets enqueued into a ReferenceQueue, as at that point you know the object to which it pointed is dead. PhantomReferences are enqueued only when the object is physically removed from memory, and the get() method always returns null specifically to prevent you from being able to "resurrect" an almost-dead object. Uses:




1. Phantom references allow you to determine exactly when an object was removed from memory. They are in fact the only way to determine that. This isn't generally that useful, but might come in handy in certain very specific circumstances like manipulating large images: if you know for sure that an image should be garbage collected, you can wait until it actually is before attempting to load the next image, and therefore make the dreaded OutOfMemoryError less likely.


2. PhantomReferences avoid a fundamental problem with finalization: finalize() methods can "resurrect" objects by creating new strong references to them. Well, the problem is that an object which overrides finalize() must now be determined to be garbage in at least two separate garbage collection cycles in order to be collected. When the first cycle determines that it is garbage, it becomes eligible for finalization. Because of the (slim, but unfortunately real) possibility that the object was "resurrected" during finalization, the garbage collector has to run again before the object can actually be removed. And because finalization might not have happened in a timely fashion, an arbitrary number of garbage collection cycles might have happened while the object was waiting for finalization. This can mean serious delays in actually cleaning up garbage objects, and is why you can getOutOfMemoryErrors even when most of the heap is garbage. With PhantomReference, this situation is impossible -- when a PhantomReference is enqueued, there is absolutely no way to get a pointer to the now-dead object (which is good, because it isn't in memory any longer). Because PhantomReference cannot be used to resurrect an object, the object can be instantly cleaned up during the first garbage collection cycle in which it is found to be phantomly reachable. You can then dispose whatever resources you need to at your convenience.

Ethernet Fabrics: An Overview

What is Ethernet Fabric?

Fabrics offer one alternative for meeting the demands of the modern data center. An Ethernet fabric is a type of network topology that collapses traditional three-tier data center switching architectures into one or two tiers, ensures network traffic is never more than two hops away from its destination and operationally behaves like one big switch. The goal of an Ethernet fabric is to increase the scalability, performance and resilience of highly virtualized and cloud-ready data centers.

Vendors typically sell commercial Ethernet fabrics as a product suite comprising specialized hardware and software. Fabrics can be implemented using various architectures, the most common among them leaf-spine and mesh. Several terms -- including data center fabric, switch fabric, network fabric and Ethernet fabric, or some amalgamation of all four -- are often used interchangeably to refer to this topology.

Ethernet fabric refers to flatter, highly scalable topologies that enable low latency via one- or two-hop connectivity in data center switching.

Why would one need an Ethernet Fabric?

Applications -- and by extension, the networks that delivered them -- used to be a lot simpler. Application traffic primarily flowed north and south between three tiers of switching that connected servers to clients.

The widespread adoption of server virtualization, however, transformed these devices, enabling these once-static architectures to become virtual machines capable of exploiting a data center's entire capacity by moving traffic among multiple physical servers. Applications were also becoming more complex, with various functions being broken off into different systems and components that would need to communicate across servers.

This influx of east-west traffic -- that is, traffic between and among servers -- has strained traditional three-tier switching architectures and limited scalability. Data would now have to pass through more hops to reach its destination, adding latency and consequently degrading performance.

Meanwhile, the performance and resilience of data center networks were further hamstrung by the pervasive use of Spanning Tree Protocol (STP), an algorithm that prevents bridge loops by shutting down redundant paths in favor of a single active link that transmits data. While STP is sufficient for conventional traffic flows and application architectures, it is an imperfect and fragile approach that uses bandwidth inefficiently.

Ethernet fabrics -- along with complementary technologies such as TRILL and Shortest Path Bridging (SPB) -- offer an alternative to the complexity and inefficiencies of three-tiered networks and Spanning Tree. An interconnected fabric combines the visibility of Layer 2 with the operational benefits of Layer 3.

Limitations of Ethernet Fabrics

1. Vendor lock-in: While a fabric offers many benefits, there is one major challenge that can be a deal-breaker for some network engineers: It almost always requires a single-vendor network. With a few exceptions, most vendors have created proprietary enhancements to standard protocols, such as TRILL and SPB, he said. This has rendered most vendors' fabrics incompatible with their competitors' infrastructure.
2. The other piece to this is fabrics … are not infinite [in capacity], and there are scaling limitations. "When you get into the multi-thousand-port range, you're starting to get to an area where the management headaches [are such that] you should consider segmenting.

Brocade Offerings

http://www.brocade.com/products/all/switches/index.page?network=ETHERNET_FABRIC

Brocade's TRILL-based Virtual Cluster Switching (VCS) data center fabric is designed for building large Layer 2 network domains. It debuted in 2010 with Brocade's series of fixed-form factor VDX 6700 switches, which are top-of-rack devices that cluster together in self-forming fabrics.

With Brocade VDX 8770 series, the server facing ports capacity has gone up to 8000 ports. The switches initially shipped with Gigabit Ethernet, 10 GbE and 40 GbE line cards, but the 4 Tbps per-slot backplane capacity is aimed at eventually supporting high-density 100 GbE ports. VDX 8770 features 3.5-microsecond port-to-port latency and a highly scalable MAC address table, capable of supporting up to 384,000 virtual machines in a single switch.

The VDX 8770 also has a new feature that allows customers to establish multiple load-balanced Layer 3 gateways within a Layer 2 VCS fabric, allowing them to increase the bandwidth available between Layer 2 domains.

To support high-performance networks, Brocade has upgraded its ADX ADCs (load balancers) to include a multi-tenancy feature that will allow enterprises and cloud service providers to slice up the resources of the appliances and assign virtual instances of an ADC to specific applications and services.

The ADX multi-tenancy doesn't slice resources by individual CPU core. It assigns tenants to processor subsystems, giving enterprises the ability to "mix and match capacity without having to determine where those processor hosts are in the system”.

Multi-tenancy in Ethernet Fabrics

Brocade engineered native multi-tenancy through support of an extension to Transparent Interconnections of Lots of Links (TRILL), the Internet Engineering Task Force's (IETF) standard that enables multi-path forwarding in a Layer 2 network and eliminates the need for spanning tree. The extension, known as Fine-Grained Labeling (FGL), replaces 12-bit virtual local area network (VLAN) labeling in a TRILL-based Ethernet frame with 24-bit FGL labeling. FGL expands the number of network segments that a network engineer can create in a Layer 2 network from 4,000 to 16 million.

"It's better than VLANs. And with VXLAN [Virtual Extensible LAN], NVGRE [Network Virtualization using Generic Routing Encapsulation] and STT, you're creating overlay mechanisms that step you out of Layer 2. [FGL] keeps all of that partitioning still running at Layer 2. In theory, you have better low-level control and performance."

The number of network segments in a Layer 2 network is a basic building block of a multi-tenant data center or cloud. Some vendors have tackled segmentation through overlay technologies like VMware NSX and tunneling protocols such as VXLAN and NVGRE. Brocade has embraced overlays with its support of VMware's NSX VXLAN termination endpoints on its VDX. However, not every IT organization is ready to embrace overlay products, which canblur the organizational lines between the network and server teams. "The networking guys want to manage and control the multi-tenancy solution." FGL uses the same constructs as VLANs, which promises a gentle learning curve to network pros. Also, since the technology is network-based, FGL is hypervisor-agnostic, unlike most overlay products.

Brocade enhanced the AutoQoS feature of VCS to apply automatic Quality of Service policies to storage traffic that traverses the fabric.

Brocade launched the VDX 6740 series of 10/40 Gigabit Ethernet (GbE) top-of-rack switches for the VCS fabric. Brocade is selling both fiber optic and copper versions of the VDX 6740 at the outset. The new 1RU switch has 1.28 Tbps of bandwidth with 64 10 GbE ports and 4 40 GbE ports. A 100 GbE line card for its VDX 8770 chassis, which will start shipping in the first half of 2014.

Although Brocade's VCS multi-tenancy is based on the IETF's FGL specification, Brocade's overall implementation of TRILL remains proprietary, much like the Cisco FabricPath, the only other major TRILL-based Ethernet fabric on the market. This prevents interoperability. While the data forwarding plane of VCS complies with IETF's TRILL specification, the control plane is proprietary.

Software defined networking (SDN) and Ethernet Fabrics: Do the two technologies intersect?

When we think about SDN, we think about the ability to influence network behavior from outside the network by using OpenFlow protocols. OpenFlow is largely supplementary to existing forwarding and routing techniques in a network, and it's supplementary to VCS. What many are going to do with OpenFlow is say, "I've got some unique network behavior that I would like to instantiate using OpenFlow because my networking vendor doesn't provide it natively within the switch." But they're not looking for OpenFlow to displace all of their routing and porting techniques. Outsourcing the entire control plane would be a pretty big bite to take. Brocade’s intent is to implement OpenFlow, both within the VCS fabric and other data center platforms, in that same supplementary fashion.

Another variant of SDN is network virtualization, the ability to apply logical networks or overlay networks on top of an existing physical network infrastructure. One of the benefits of that is to give the customer more freedom in terms of scalability and going beyond VLAN ID and MAC address table size limitations. In introducing logical networks, you're actually increasing the overall administrative overhead that the customer has to deal with. The beauty of a VCS fabric is that through automation and simplicity, you can reduce your administrative burden and your operational overhead in the physical network infrastructure, and invest more time in that logical overlay.

Converged Storage Networking (FCoE): What is the future?

There is some [modest] adoption in convergence and FCoE from the server to the first hop in the network. That is gaining some momentum because it's an opportunity for customers to reduce the adapters in the server and simplify cabling. VCS is capable of supporting that convergence to the switch, at which point we're capable of breaking out native Fibre Channel traffic on the SAN [storage area network] and non-storage traffic on the Ethernet LAN.

More important from a convergence point of view is the growth of IP storage and our ability to leverage VCS to make NAS [network attached storage] or iSCSI work better. VCS provides a lower-latency and higher-throughput environment than a conventional LAN, so it's a better IP storage transport. Also, VCS has a scaling property that aligns with the way customers think about scaling up their NAS environments. They want to be able to add pods of storage and have that federate into the existing IP storage architecture. That's the way you scale a VCS fabric.

 

References

1. http://searchnetworking.techtarget.com/news/2240173618/FCoE-for-converged-networking-Not-quite-Brocade-veep-says
2. http://searchnetworking.techtarget.com/news/2240173619/Network-Innovation-Award-Brocade-VCS-Fabric
3. http://searchnetworking.techtarget.com/news/2240206057/Brocade-adds-multi-tenancy-to-VCS-Ethernet-fabric-new-ToR-switches
4. http://searchnetworking.techtarget.com/news/2240163205/New-Brocade-VDX-chassis-adds-scale-to-data-center-fabric?src=itke%20disc

Cloud Operations with SAN Infrastructure Visibility – Brocade | VMware Cloud Management - VMware Blogs

Cloud Operations with SAN Infrastructure Visibility – Brocade | VMware Cloud Management - VMware Blogs:

Cool blog out this morning by Wayne Greene, VMware’s snr director in charge of cloud management about the Brocade SAN Analytics Management Pack for vCenter Operations Management Suite.

More details at Brocade site - http://community.brocade.com/t5/Data-Center/SAN-Visibility-for-Virtual-Infrastructure-Managers/ba-p/249 

Eclipse 4.2 in Ubuntu 12.04

Eclipse 4.2 in Ubuntu 12.04 | Bruno Braga:

1. Install the version of eclipse that comes with Ubuntu repo (for 12.04 its eclipse 3.8)
2. Then follow the below steps to update that version with the latest eclipse. After that, when you click on the original Eclipse icon it will launch the updated eclipse.
3. Note: We will need to redo the steps every time we want to update eclipse installation. 

# Get the Eclipse installer for Linux 
# (if you do not know the flavour, just choose "Classic")
# http://www.eclipse.org/downloads/
 
 
# Unpack it
$ tar -zxvf eclipse-SDK-4.2-linux-gtk.tar.gz
 
 
# if you have a previous Eclipse version installed
# just move it (in case anything goes terribly wrong, 
# you can just rollback)
$ sudo mv /usr/lib/eclipse /usr/lib/eclipse-old
 
 
# move the unpacked directory to lib
$ sudo mv eclipse /usr/lib/
 

Why OpenTSDB chose HBase for Time Series data storage? - Stack Overflow

Why OpenTSDB chose HBase for Time Series data storage? - Stack Overflow:

Nice reply to this question by OpenTSDB author for why StumbleUpon uses HBase (and in fact facebook does the same for big data analytics):

I chose HBase because it scales. Whisper is much like RRD, it's a fixed-size database, it must destroy data in order to work within its space constraints. HBase offers the following properties that make it very well suited for large scale time series databases:

1. Linear scaling. Want to store data? Add more nodes. At StumbleUpon, where I wrote OpenTSDB, our time series data was co-located on a 20-node cluster that was primarily used for analytics and batch processing. The cluster grew to 120 nodes fairly quickly, and meanwhile OpenTSDB, which makes up only a tiny fraction of the cluster's workload, grew to half a trillion data points.

1. Automatic replication. Your data is stored in HDFS, which by default means 3 replicas on 3 different machines. If a machine or a drives dies, no big deal. Drives and machines die all the time when you build commodity servers. But the thing is: you don't really care.

1. Efficient scans. Most time series data is used to answer questions that are like "what are the data points between time X and Y". If you structure your keys properly, you can implement this very efficiently with HBase with a simple scan operation.

The fact that HBase is column oriented wasn't nearly as important a consideration as the fact that it's a big sorted key-value system that really scales.
All RRD-based and RRD-derived tools couldn't satisfy the scale requirements of being able to accuratelystore billions and billions of data points forever for very cheap (just a few bytes of actual disk space per data point).

TempoDB docs:

1. https://tempo-db.com/docs/modeling-time-series-data/
2. http://www.plainlystated.com/2013/01/bulk-loading-time-series-data-tempodb/