Could not find gem ‘pgw’ ( >= 0, runtime)’ in any of the gem sources listed in your Gemfile

I tried Ole Morten Amundsen’s method, but it didn’t ( quite ) work (see below)

Magic directory method

1. mkdir -p vendor/cache
2. bundle update
3. git add -A
4. git commit -m"whatever"
5. git push heroku master

All the gems public or private are installed into the vendor/cache directory.

Pros:

1. Simple.
2. It works.
3. Also allows for a locked down deployment (? not completely certain on this because heroku does report “Installing …” for all the gems including the private gem)

Cons:

1. All the gems used are installed, not just the single gem that is not available on rubyforge.
2. Magicalness feels like a possible bug. (Note: I am using bundler 1.0.13) so it may not work in future
3. git bloat – all the external gems and dependencies are now part of your repo.
4. Possible issues with machine specific deployments with other gems? ( not certain about this – but flagging it as a possibility )

Ole Morten Amundsen variant

1. gem unpack pgw --target vendor/gems
2. edit Gemfile to explicitly list the gem version and supply the path
   gem "pgw", "0.0.3", :path =>"{#File.expand_path(__FILE__)}/../vendor/gems/"
3. bundle install --local
4. git add -A
5. git commit -m"whatever"
6. git push heroku master

The resulting Gemfile.lock will have this:

PATH
  remote: vendor/gems
  specs:
    pgw (0.0.3)

GEM
...(everything else ) ...

Pros:

1. Feels more like the intended process
2. Only extra code is the private gem ‘pgw’ – none of the standard ruby gems are added to the project.

Cons:

1. More typing
2. Have to include specific version number in the Gemfile – so harder to ensure against an accidental release with old version of gem.
3. “unpacking” seems lame. Is there a way to keep the ‘pgw’ gem as a .gem file?

Questions

1. Is there an easy way to move the gems to my master project other than gem unpack?
2. should the gem be put in vendor/bundle since that is the default BUNDLE_PATH?

Specifically,

1. Create two tables Main and Secondary
   • create table Main ( ID bigint, ordering varchar(3));
   • create table Secondary ( Main_ID bigint, Secondary_Value bigint);
2. Insert Values:
   • insert into Main (ID, ordering) values (1, 'u'),(2,'d'),(3,'n');
   • insert into Secondary (Main_ID, Secondary_Value) values ( 1, 11),(1,21),(1,41),(1,31),(1,71),(1,61),(1,51),(2,62),(2,42),(2,82), ( 3,3), (3, 1), (3, 5);
3. Create a query that orders the results by Main.ID, Secondary.Secondary_Value based on Main.ordering value. If the Main.ordering is:
   • ‘u’ then the corresponding Secondary_Value is ordered ascending,
   • ‘d’ then the corresponding Secondary_Value is ordered descending,
   • ‘n’ then the corresponding Secondary_Value is unordered

The solution is:

select * from Main join Secondary on ( Main.ID = Secondary.Main_ID ) order by Main.ID, (case MAIN.ordering when 'u' then 1 when 'd' then -1 else 0 end) * Secondary.Secondary_Value;

+------+----------+---------+-----------------+
| ID   | ordering | Main_ID | Secondary_Value |
+------+----------+---------+-----------------+
|    1 | u        |       1 |              11 |
|    1 | u        |       1 |              21 |
|    1 | u        |       1 |              31 |
|    1 | u        |       1 |              41 |
|    1 | u        |       1 |              51 |
|    1 | u        |       1 |              61 |
|    1 | u        |       1 |              71 |
|    2 | d        |       2 |              82 |
|    2 | d        |       2 |              62 |
|    2 | d        |       2 |              42 |
|    3 | n        |       3 |               1 |
|    3 | n        |       3 |               5 |
|    3 | n        |       3 |               3 |
+------+----------+---------+-----------------+
13 rows in set (0.00 sec)

Variable ordering within a single result set! woo-hoo!

This javadoc issue occurred when there is a class that has no package line ( it is in the default package). Annoyingly enough it occurred when I was trying to create a test case for this javac bug. I was running maven 2.2.1 at the time.

java.lang.NullPointerException
       at com.sun.tools.doclets.formats.html.PackageUseWriter.generatePackageUse(PackageUseWriter.java:180)
       at com.sun.tools.doclets.formats.html.PackageUseWriter.generatePackageList(PackageUseWriter.java:124)
       at com.sun.tools.doclets.formats.html.PackageUseWriter.generatePackageUse(PackageUseWriter.java:110)
       at com.sun.tools.doclets.formats.html.PackageUseWriter.generatePackageUseFile(PackageUseWriter.java:99)
       at com.sun.tools.doclets.formats.html.PackageUseWriter.generate(PackageUseWriter.java:78)
       at com.sun.tools.doclets.formats.html.ClassUseWriter.generate(ClassUseWriter.java:116)
       at com.sun.tools.doclets.formats.html.HtmlDoclet.generateOtherFiles(HtmlDoclet.java:92)
       at com.sun.tools.doclets.internal.toolkit.AbstractDoclet.startGeneration(AbstractDoclet.java:122)
       at com.sun.tools.doclets.internal.toolkit.AbstractDoclet.start(AbstractDoclet.java:64)
       at com.sun.tools.doclets.formats.html.HtmlDoclet.start(HtmlDoclet.java:42)
       at com.sun.tools.doclets.standard.Standard.start(Standard.java:23)
       at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
       at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
       at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
       at java.lang.reflect.Method.invoke(Method.java:597)
       at com.sun.tools.javadoc.DocletInvoker.invoke(DocletInvoker.java:269)
       at com.sun.tools.javadoc.DocletInvoker.start(DocletInvoker.java:143)
       at com.sun.tools.javadoc.Start.parseAndExecute(Start.java:340)
       at com.sun.tools.javadoc.Start.begin(Start.java:128)
       at com.sun.tools.javadoc.Main.execute(Main.java:41)
       at com.sun.tools.javadoc.Main.main(Main.java:31)

Solution was to put the java code into a package.

An exception has occurred in the compiler (1.6.0_17). Please file a bug at the Java Developer Connection (http://java.sun.com/webapps/bugreport) after checking the Bug Parade for duplicates. Include your program and the following diagnostic in your report. Thank you.

java.lang.AssertionError: isSubtype 15 ( 15 = TypeTags.WILDCARD )
	at com.sun.tools.javac.code.Types$5.visitType(Types.java:347)
	at com.sun.tools.javac.code.Types$5.visitType(Types.java:328)
	at com.sun.tools.javac.code.Types$DefaultTypeVisitor.visitWildcardType(Types.java:3163)
	at com.sun.tools.javac.code.Type$WildcardType.accept(Type.java:416)
	at com.sun.tools.javac.code.Types$DefaultTypeVisitor.visit(Types.java:3161)
	at com.sun.tools.javac.code.Types.isSubtype(Types.java:324)
	at com.sun.tools.javac.code.Types.isSubtype(Types.java:308)
	at com.sun.tools.javac.code.Types.isSubtypeUnchecked(Types.java:288)
	at com.sun.tools.javac.code.Types.isSubtypeUnchecked(Types.java:460)
	at com.sun.tools.javac.comp.Infer.checkWithinBounds(Infer.java:388)
	at com.sun.tools.javac.comp.Infer.instantiateExpr(Infer.java:241)
	at com.sun.tools.javac.comp.Check.instantiatePoly(Check.java:356)
	at com.sun.tools.javac.comp.Check.checkType(Check.java:324)
	at com.sun.tools.javac.comp.Attr.check(Attr.java:160)
	at com.sun.tools.javac.comp.Attr.visitApply(Attr.java:1276)
	at com.sun.tools.javac.tree.JCTree$JCMethodInvocation.accept(JCTree.java:1210)
	at com.sun.tools.javac.comp.Attr.attribTree(Attr.java:360)
	at com.sun.tools.javac.comp.Attr.attribExpr(Attr.java:377)
	at com.sun.tools.javac.comp.Attr.visitAssign(Attr.java:1550)
	at com.sun.tools.javac.tree.JCTree$JCAssign.accept(JCTree.java:1342)
	at com.sun.tools.javac.comp.Attr.attribTree(Attr.java:360)
	at com.sun.tools.javac.comp.Attr.attribExpr(Attr.java:384)
	at com.sun.tools.javac.comp.Attr.visitExec(Attr.java:1017)
	at com.sun.tools.javac.tree.JCTree$JCExpressionStatement.accept(JCTree.java:1074)
	at com.sun.tools.javac.comp.Attr.attribTree(Attr.java:360)
	at com.sun.tools.javac.comp.Attr.attribStat(Attr.java:397)
	at com.sun.tools.javac.comp.Attr.attribStats(Attr.java:413)
	at com.sun.tools.javac.comp.Attr.visitBlock(Attr.java:715)
	at com.sun.tools.javac.tree.JCTree$JCBlock.accept(JCTree.java:739)
	at com.sun.tools.javac.comp.Attr.attribTree(Attr.java:360)
	at com.sun.tools.javac.comp.Attr.attribStat(Attr.java:397)
	at com.sun.tools.javac.comp.Attr.visitIf(Attr.java:1009)
	at com.sun.tools.javac.tree.JCTree$JCIf.accept(JCTree.java:1050)
	at com.sun.tools.javac.comp.Attr.attribTree(Attr.java:360)
	at com.sun.tools.javac.comp.Attr.attribStat(Attr.java:397)
	at com.sun.tools.javac.comp.Attr.attribStats(Attr.java:413)
	at com.sun.tools.javac.comp.Attr.visitBlock(Attr.java:715)
	at com.sun.tools.javac.tree.JCTree$JCBlock.accept(JCTree.java:739)
	at com.sun.tools.javac.comp.Attr.attribTree(Attr.java:360)
	at com.sun.tools.javac.comp.Attr.attribStat(Attr.java:397)
	at com.sun.tools.javac.comp.Attr.visitForLoop(Attr.java:740)
	at com.sun.tools.javac.tree.JCTree$JCForLoop.accept(JCTree.java:818)
	at com.sun.tools.javac.comp.Attr.attribTree(Attr.java:360)
	at com.sun.tools.javac.comp.Attr.attribStat(Attr.java:397)
	at com.sun.tools.javac.comp.Attr.attribStats(Attr.java:413)
	at com.sun.tools.javac.comp.Attr.visitBlock(Attr.java:715)
	at com.sun.tools.javac.tree.JCTree$JCBlock.accept(JCTree.java:739)
	at com.sun.tools.javac.comp.Attr.attribTree(Attr.java:360)
	at com.sun.tools.javac.comp.Attr.attribStat(Attr.java:397)
	at com.sun.tools.javac.comp.Attr.visitIf(Attr.java:1009)
	at com.sun.tools.javac.tree.JCTree$JCIf.accept(JCTree.java:1050)
	at com.sun.tools.javac.comp.Attr.attribTree(Attr.java:360)
	at com.sun.tools.javac.comp.Attr.attribStat(Attr.java:397)
	at com.sun.tools.javac.comp.Attr.attribStats(Attr.java:413)
	at com.sun.tools.javac.comp.Attr.visitBlock(Attr.java:715)
	at com.sun.tools.javac.tree.JCTree$JCBlock.accept(JCTree.java:739)
	at com.sun.tools.javac.comp.Attr.attribTree(Attr.java:360)
	at com.sun.tools.javac.comp.Attr.attribStat(Attr.java:397)
	at com.sun.tools.javac.comp.Attr.visitIf(Attr.java:1009)
	at com.sun.tools.javac.tree.JCTree$JCIf.accept(JCTree.java:1050)
	at com.sun.tools.javac.comp.Attr.attribTree(Attr.java:360)
	at com.sun.tools.javac.comp.Attr.attribStat(Attr.java:397)
	at com.sun.tools.javac.comp.Attr.attribStats(Attr.java:413)
	at com.sun.tools.javac.comp.Attr.visitBlock(Attr.java:715)
	at com.sun.tools.javac.tree.JCTree$JCBlock.accept(JCTree.java:739)
	at com.sun.tools.javac.comp.Attr.attribTree(Attr.java:360)
	at com.sun.tools.javac.comp.Attr.attribStat(Attr.java:397)
	at com.sun.tools.javac.comp.Attr.visitMethodDef(Attr.java:634)
	at com.sun.tools.javac.tree.JCTree$JCMethodDecl.accept(JCTree.java:639)
	at com.sun.tools.javac.comp.Attr.attribTree(Attr.java:360)
	at com.sun.tools.javac.comp.Attr.attribStat(Attr.java:397)
	at com.sun.tools.javac.comp.Attr.attribClassBody(Attr.java:2697)
	at com.sun.tools.javac.comp.Attr.attribClass(Attr.java:2628)
	at com.sun.tools.javac.comp.Attr.attribClass(Attr.java:2564)
	at com.sun.tools.javac.main.JavaCompiler.attribute(JavaCompiler.java:1036)
	at com.sun.tools.javac.main.JavaCompiler.compile2(JavaCompiler.java:765)
	at com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:730)
	at com.sun.tools.javac.main.Main.compile(Main.java:353)
	at com.sun.tools.javac.main.Main.compile(Main.java:279)
	at com.sun.tools.javac.main.Main.compile(Main.java:270)
	at com.sun.tools.javac.Main.compile(Main.java:69)
	at com.sun.tools.javac.Main.main(Main.java:54)

I was not successful at reducing this crash to a simple test case.

However, the line that triggered the crash was:

Some points:

• Once again (and again) the eclipse compiler is more robust than the sun javac
• ProxyMapperImplementor is defined as:
  
  

  interface ProxyMapperImplementor<I, O extends I>

• Removing the wildcards so the line looks like solved the problem:
  

  ProxyMapperImplementor childProxy = this;

  Update (email from sun):

  This issue is related to Bug ID: 6738538. You can review this bug at:

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

  This problem has been fixed in Java SE 7.0. Consider downloading a free copy at http://download.java.net/jdk7/binaries/ and checking if the problem persists. If the problem persists do let us know and we shall investigate this furthur.

  We greatly appreciate your efforts in identifying areas in the Java Standard Edition where we can improve upon and I would request you to continue doing so.

  ]]> http://sworddance.com/blog/2010/01/07/woot-i-crashed-the-javac/feed/ 2 http://sworddance.com/blog/2010/01/06/generic-annoyances-in-java/#utm_source=rss&utm_medium=rss&utm_campaign=generic-annoyances-in-java http://sworddance.com/blog/2010/01/06/generic-annoyances-in-java/#comments Thu, 07 Jan 2010 01:14:31 +0000 patrick http://www.sworddance.com/blog/?p=548 cannot flow through from an external caller through a callee to another called method. This compiles just fine in eclipse, but once again sun’s javac is temperamental. The three solutions seem to be: … Continue reading →]]> For some reason, the type variable <O> cannot flow through from an external caller through a callee to another called method.

  This compiles just fine in eclipse, but once again sun’s javac is temperamental.

  The three solutions seem to be:

  1. pass an object of type <O> to the subcallee method (m0(), p0() )
  2. use wildcard instead of <O> – which is o.k. if O is not needed in the body of the method
  3. assign to a variable with no generic information (universal backup solution to java generic wierdness)

  I filed a bug with Sun.

  (Technical details: javac 1.6.0_17 )

  public class Foo {
      public > I m(I i) {
  /*line3*/        R r = (R) p(i);
          return i;
      }
      public > R p(I i) {
          return null;
      }
  
      public > I m0(O o) {
          K r= (K) p0(o);
          return o;
      }
      public > K p0(O o) {
          return null;
      }
  
      public > I m1(I i) {
          K r= (K) p1(i);
          return i;
      }
      public > K p1(I i) {
          return null;
      }
  
      public > I m2(I i) {
  /*line 27*/        K r= (K) p2(i);
          return i;
      }
      public > K p2(I i) {
          return null;
      }
      interface FooInterface {
  
      }
  }
  

  Foo.java:3: incompatible types; inferred type argument(s) I,java.lang.Object do not conform to bounds of type variable(s) O,R
found : R
required: java.lang.Object
/*line3*/ R r = (R) p(i);
^
Foo.java:27: incompatible types; inferred type argument(s) I,java.lang.Object do not conform to bounds of type variable(s) O,K
found : K
required: java.lang.Object
K r= (K) p2(i);
^

  ]]> http://sworddance.com/blog/2010/01/06/generic-annoyances-in-java/feed/ 1 http://sworddance.com/blog/2009/01/15/macosx-and-hostname/#utm_source=rss&utm_medium=rss&utm_campaign=macosx-and-hostname http://sworddance.com/blog/2009/01/15/macosx-and-hostname/#comments Thu, 15 Jan 2009 19:37:47 +0000 patrick http://www.sworddance.com/blog/?p=295 Continue reading →]]> h/t Larry Gordon (copied because I want to make sure I always have it available):

  When I log into the network at my job my Mac’s hostname always turns to:

  larryx.na.corp.ipgnetwork.com

  I have my local hostname set to:

  larryx.local

  So What I would like to do is set my Mac’s hostname to my local hostname. You can do this all from Terminal in a single line.

  Run this command in Terminal:

  sudo scutil --set HostName larryx.local

  ]]> http://sworddance.com/blog/2009/01/15/macosx-and-hostname/feed/ 0 http://sworddance.com/blog/2008/05/09/website-performance-tips/#utm_source=rss&utm_medium=rss&utm_campaign=website-performance-tips http://sworddance.com/blog/2008/05/09/website-performance-tips/#comments Sat, 10 May 2008 07:29:21 +0000 patrick http://www.sworddance.com/blog/?p=142 Yahoo website performance tips
  ]]> http://sworddance.com/blog/2008/05/09/website-performance-tips/feed/ 0 http://sworddance.com/blog/2008/01/10/where-oh-where-is-the-list-of-all-those-magic-xx-java-parameters/#utm_source=rss&utm_medium=rss&utm_campaign=where-oh-where-is-the-list-of-all-those-magic-xx-java-parameters http://sworddance.com/blog/2008/01/10/where-oh-where-is-the-list-of-all-those-magic-xx-java-parameters/#comments Fri, 11 Jan 2008 01:18:27 +0000 patrick http://www.sworddance.com/blog/2008/01/10/where-oh-where-is-the-list-of-all-those-magic-xx-java-parameters/ Continue reading →]]> The master list is here.

  But just in case it goes away here is the list (pruned for java 6):

  Option and Default Value	Description
  -XX:-AllowUserSignalHandlers	Do not complain if the application installs signal handlers. (Relevant to Solaris and Linux only.)
  -XX:-DisableExplicitGC	Disable calls to System.gc(), JVM still performs garbage collection when necessary.
  -XX:+FailOverToOldVerifier	Fail over to old verifier when the new type checker fails. (Introduced in 6.)
  -XX:+HandlePromotionFailure	The youngest generation collection does not require a guarantee of full promotion of all live objects. (Introduced in 1.4.2 update 11) [5.0 and earlier: false.]
  -XX:+MaxFDLimit	Bump the number of file descriptors to max. (Relevant to Solaris only.)
  -XX:PreBlockSpin=10	Spin count variable for use with -XX:+UseSpinning. Controls the maximum spin iterations allowed before entering operating system thread synchronization code. (Introduced in 1.4.2.)
  -XX:-RelaxAccessControlCheck	Relax the access control checks in the verifier. (Introduced in 6.)
  -XX:+ScavengeBeforeFullGC	Do young generation GC prior to a full GC. (Introduced in 1.4.1.)
  -XX:+UseAltSigs	Use alternate signals instead of SIGUSR1 and SIGUSR2 for VM internal signals. (Introduced in 1.3.1 update 9, 1.4.1. Relevant to Solaris only.)
  -XX:+UseBoundThreads	Bind user level threads to kernel threads. (Relevant to Solaris only.)
  -XX:-UseConcMarkSweepGC	Use concurrent mark-sweep collection for the old generation. (Introduced in 1.4.1)
  -XX:+UseGCOverheadLimit	Use a policy that limits the proportion of the VM’s time that is spent in GC before an OutOfMemory error is thrown. (Introduced in 6.)
  -XX:+UseLWPSynchronization	Use LWP-based instead of thread based synchronization. (Introduced in 1.4.0. Relevant to Solaris only.)
  -XX:-UseParallelGC	Use parallel garbage collection for scavenges. (Introduced in 1.4.1)
  -XX:-UseParallelOldGC	Use parallel garbage collection for the full collections. Enabling this option automatically sets -XX:+UseParallelGC. (Introduced in 5.0 update 6.)
  -XX:-UseSerialGC	Use serial garbage collection. (Introduced in 5.0.)
  -XX:+UseTLAB	Use thread-local object allocation (Introduced in 1.4.0, known as UseTLE prior to that.) [1.4.2 and earlier, x86 or with -client: false]
  -XX:+UseSplitVerifier	Use the new type checker with StackMapTable attributes. (Introduced in 5.0.)[5.0: false]
  -XX:+UseThreadPriorities	Use native thread priorities.
  -XX:+UseVMInterruptibleIO	Thread interrupt before or with EINTR for I/O operations results in OS_INTRPT. (Introduced in 6. Relevant to Solaris only.)

  ---

  Performance Options

  Option and Default Value	Description
  -XX:+AggressiveOpts	Turn on point performance compiler optimizations that are expected to be default in upcoming releases. (Introduced in 5.0 update 6.)
  -XX:CompileThreshold=10000	Number of method invocations/branches before compiling [-client: 1,500]
  -XX:LargePageSizeInBytes=4m	Sets the large page size used for the Java heap. (Introduced in 1.4.0 update 1.) [amd64: 2m.]
  -XX:MaxHeapFreeRatio=70	Maximum percentage of heap free after GC to avoid shrinking.
  -XX:MaxNewSize=size	Maximum size of new generation (in bytes). Since 1.4, MaxNewSize is computed as a function of NewRatio. [1.3.1 Sparc: 32m; 1.3.1 x86:2.5m.]
  -XX:MaxPermSize=64m	Size of the Permanent Generation.  [5.0 and newer: 64 bit VMs are scaled 30% larger; 1.4 amd64: 96m; 1.3.1 -client: 32m.]
  -XX:MinHeapFreeRatio=40	Minimum percentage of heap free after GC to avoid expansion.
  -XX:NewRatio=2	Ratio of new/old generation sizes. [Sparc -client: 8; x86 -server: 8; x86-client: 12.]-client: 4 (1.3) 8 (1.3.1+), x86: 12]
  -XX:NewSize=2.125m	Default size of new generation (in bytes) [5.0 and newer: 64 bit VMs are scaled 30% larger; x86: 1m; x86, 5.0 and older: 640k]
  -XX:ReservedCodeCacheSize=32m	Reserved code cache size (in bytes) – maximum code cache size. [Solaris 64-bit, amd64, and -server x86: 48m; in 1.5.0_06 and earlier, Solaris 64-bit and and64: 1024m.]
  -XX:SurvivorRatio=8	Ratio of eden/survivor space size [Solaris amd64: 6; Sparc in 1.3.1: 25; other Solaris platforms in 5.0 and earlier: 32]
  -XX:TargetSurvivorRatio=50	Desired percentage of survivor space used after scavenge.
  -XX:ThreadStackSize=512	Thread Stack Size (in Kbytes). (0 means use default stack size) [Sparc: 512; Solaris x86: 320 (was 256 prior in 5.0 and earlier); Sparc 64 bit: 1024; Linux amd64: 1024 (was 0 in 5.0 and earlier); all others 0.]
  -XX:+UseBiasedLocking	Enable biased locking. For more details, see this tuning example. (Introduced in 5.0 update 6.) [5.0: false]
  -XX:+UseFastAccessorMethods	Use optimized versions of Get<Primitive>Field.
  -XX:-UseISM	Use Intimate Shared Memory. [Not accepted for non-Solaris platforms.] For details, see Intimate Shared Memory.
  -XX:+UseLargePages	Use large page memory. (Introduced in 5.0 update 5.) For details, see Java Support for Large Memory Pages.
  -XX:+UseMPSS	Use Multiple Page Size Support w/4mb pages for the heap. Do not use with ISM as this replaces the need for ISM. (Introduced in 1.4.0 update 1, Relevant to Solaris 9 and newer.) [1.4.1 and earlier: false]

  ---

  Debugging Options

  Option and Default Value	Description
  -XX:-CITime	Prints time spent in JIT Compiler. (Introduced in 1.4.0.)
  -XX:ErrorFile=./hs_err_pid<pid>.log	If an error occurs, save the error data to this file. (Introduced in 6.)
  -XX:-ExtendedDTraceProbes	Enable performance-impacting dtrace probes. (Introduced in 6. Relevant to Solaris only.)
  -XX:HeapDumpPath=./java_pid<pid>.hprof	Path to directory or filename for heap dump. Manageable. (Introduced in 1.4.2 update 12, 5.0 update 7.)
  -XX:-HeapDumpOnOutOfMemoryError	Dump heap to file when java.lang.OutOfMemoryError is thrown. Manageable. (Introduced in 1.4.2 update 12, 5.0 update 7.)
  -XX:OnError=”<cmd args>;<cmd args>”	Run user-defined commands on fatal error.
  -XX:OnOutOfMemoryError=”<cmd args>; <cmd args>”	Run user-defined commands when an OutOfMemoryError is first thrown.
  -XX:-PrintClassHistogram	Print a histogram of class instances on Ctrl-Break. Manageable. (Introduced in 1.4.2.) The jmap -histo command provides equivalent functionality.
  -XX:-PrintConcurrentLocks	Print java.util.concurrent locks in Ctrl-Break thread dump. Manageable. (Introduced in 6.) The jstack -l command provides equivalent functionality.
  -XX:-PrintCommandLineFlags	Print flags that appeared on the command line. (Introduced in 5.0.)
  -XX:-PrintCompilation	Print message when a method is compiled.
  -XX:-PrintGC	Print messages at garbage collection. Manageable.
  -XX:-PrintGCDetails	Print more details at garbage collection. Manageable.
  -XX:-PrintGCTimeStamps	Print timestamps at garbage collection. Manageable
  -XX:-PrintTenuringDistribution	Print tenuring age information.
  -XX:-TraceClassLoading	Trace loading of classes.
  -XX:-TraceClassLoadingPreorder	Trace all classes loaded in order referenced (not loaded).
  -XX:-TraceClassResolution	Trace constant pool resolutions. (Introduced in 1.4.2.)
  -XX:-TraceClassUnloading	Trace unloading of classes.
  -XX:-TraceLoaderConstraints	Trace recording of loader constraints. (Introduced in 6.)

  Advanced Hackery:

  Reading the JVM’s mind. First unlock the diagnostics with :
  -XX:+UnlockDiagnosticVMOptions

  -XX:LogFile=diagnostic_log_file	default: hotspot.log
  -XX:+LogCompilation	produces a low-level XML file about compiler and runtime decisions. (related tool)

  ]]> http://sworddance.com/blog/2008/01/10/where-oh-where-is-the-list-of-all-those-magic-xx-java-parameters/feed/ 0 http://sworddance.com/blog/2007/08/13/explain-this/#utm_source=rss&utm_medium=rss&utm_campaign=explain-this http://sworddance.com/blog/2007/08/13/explain-this/#comments Mon, 13 Aug 2007 16:48:31 +0000 patrick http://www.sworddance.com/blog/2007/08/13/explain-this/ Continue reading →]]>

  type parameters of T cannot be determined; no unique maximal instance exists for type variable T with upper bounds T,java.lang.Object

  In java 1.6u2 running in maven 2.0.7, we started getting this message but in eclipse 3.3.0 we were not. (and in idea we also were failing)

  First, what the hell does this message means? Second, why can eclipse handle the issue and not the regular jdk?

  Anyhow the problem was caused by this (our example was a little more complex than this):
  


  public <T> T getFoo() {
  T result;
  result = getBar();
  return result;
  }

  public <T> T getBar() {
  return (T) map.get("bar");
  }

  The workaround is casting the line:
  


  result = getBar();

  
  to:
  


  result = (T)getBar();

  ]]> http://sworddance.com/blog/2007/08/13/explain-this/feed/ 4 http://sworddance.com/blog/2007/05/29/apache-v-tomcat-mysteries/#utm_source=rss&utm_medium=rss&utm_campaign=apache-v-tomcat-mysteries http://sworddance.com/blog/2007/05/29/apache-v-tomcat-mysteries/#comments Tue, 29 May 2007 22:48:07 +0000 patrick http://www.sworddance.com/blog/2007/05/29/apache-v-tomcat-mysteries/ Continue reading →]]> So I struggled for hours trying to get apache to connect via the ajp13 worker to tomcat 5.5 We are using a Debian box on the production server. Could not make it happen…. until I set the worker to be ‘ajp13′.

  Don’t understand what wierdness is going on but… I do know this. if my /etc/libapache-mod-jk/workers.properties file looks like this (comments removed):

  workers.tomcat_home=/usr/share/tomcat5.5
  workers.java_home=/usr/local/java
  worker.list=ajp13
  worker.ajp13.port=8009
  worker.ajp13.host=localhost
  worker.ajp13.type=ajp13
  worker.ajp13.lbfactor=1
  worker.loadbalancer.type=lb
  worker.loadbalancer.balanced_workers=ajp13

  Apache 2 talks very nicely with Tomcat 5.5.20

  If it looks like this:

  workers.tomcat_home=/usr/share/tomcat5.5
  workers.java_home=/usr/local/java
  worker.list=amplafi_ajp13
  worker.amplafi_ajp13.port=8009
  worker.amplafi_ajp13.host=localhost
  worker.amplafi_ajp13.type=ajp13
  worker.amplafi_ajp13.lbfactor=1
  worker.loadbalancer.type=lb
  worker.loadbalancer.balanced_workers=amplafi_ajp13

  Everything is broken!

  Does anyone have a clue here on why?

  ]]> http://sworddance.com/blog/2007/05/29/apache-v-tomcat-mysteries/feed/ 2