What Happened To Java (Specifically The Language)? [closed]

Back in 2000 (when .NET was unleashed upon us IIRC) it was an innovative cutting edge language (last time I used it was 2003).

From what I read though, Sun has only evolved the language exceedingly slowly. I've even read that where the language has evolved, such as the addition of Generics, developers have complained about poor implementation.

Are these accurate perceptions, and if so, any thoughts on why, particularly with the seemingly obvious competition from C#?

Why does the Sun JVM continue to consume ever more RSS memory even when the heap, etc sizes are stable?

Over the past year I've made huge improvements in my application's Java heap usage--a solid 66% reduction. In pursuit of that, I've been monitoring various metrics, such as Java heap size, cpu, Java non-heap, etc. via SNMP.

Recently, I've been monitoring how much real memory (RSS, resident set) by the JVM and am somewhat surprised. The real memory consumed by the JVM seems totally independent of my applications heap size, non-heap, eden space, thread count, etc.

Heap Size as measured by Java SNMP

Real Memory in KB. (E.g.: 1 MB of KB = 1 GB)

(The three dips in the heap graph correspond to application updates/restarts.)

This is a problem for me because all that extra memory the JVM is consuming is 'stealing' memory that could be used by the OS for file caching. In fact, once the RSS value reaches ~2.5-3GB, I start to see slower response times and higher CPU utilization from my application, mostly do to IO wait. As some point paging to the swap partition kicks in. This is all very undesirable.

So, my questions:

• Why is this happening? What is going on "under the hood"?
• What can I do to keep the JVM's real memory consumption in check?

The gory details:

• RHEL4 64-bit (Linux - 2.6.9-78.0.5.ELsmp #1 SMP Wed Sep 24 ... 2008 x86_64 ... GNU/Linux)
• Java 6 (build 1.6.0_07-b06)
• Tomcat 6
• Application (on-demand HTTP video streaming)
  • High I/O via java.nio FileChannels
  • Hundreds to low thousands of threads
  • Low database use
  • Spring, Hibernate

Relevant JVM parameters:

-Xms128m  
-Xmx640m  
-XX:+UseConcMarkSweepGC  
-XX:+AlwaysActAsServerClassMachine  
-XX:+CMSIncrementalMode    

-XX:+PrintGCDetails 
-XX:+PrintGCTimeStamps  
-XX:+PrintGCApplicationStoppedTime  
-XX:+CMSLoopWarn  
-XX:+HeapDumpOnOutOfMemoryError

How I measure RSS:

ps x -o command,rss | grep java | grep latest | cut -b 17-

This goes into a text file and is read into an RRD database my the monitoring system on regular intervals. Note that ps outputs Kilo Bytes.

The Problem & Solution*s*:

While in the end it was ATorras's answer that proved ultimately correct, it kdgregory who guided me to the correct diagnostics path with the use of pmap. (Go vote up both their answers!) Here is what was happening:

Things I know for sure:

1. My application records and displays data with JRobin 1.4, something I coded into my app over three years ago.
2. The busiest instance of the application currently creates
   
   1. Over 1000 a few new JRobin database files (at about 1.3MB each) within an hour of starting up
   2. ~100+ each day after start-up
3. The app updates these JRobin data base objects once every 15s, if there is something to write.
4. In the default configuration JRobin:
   1. uses a java.nio-based file access back-end. This back-end maps MappedByteBuffers to the files themselves.
   2. once every five minutes a JRobin daemon thread calls MappedByteBuffer.force() on every JRobin underlying database MBB
5. pmap listed:
   1. 6500 mappings
   2. 5500 of which were 1.3MB JRobin database files, which works out to ~7.1GB

That last point was my "Eureka!" moment.

My corrective actions:

1. Consider updating to the latest JRobinLite 1.5.2 which is apparently better
2. Implement proper resource handling on JRobin databases. At the moment, once my application creates a database and then never dumps it after the database is no longer actively used.
3. Experiment with moving the MappedByteBuffer.force() to database update events, and not a periodic timer. Will the problem magically go away?
4. Immediately, change the JRobin back-end to the java.io implementation--a line line change. This will be slower, but it is possibly not an issue. Here is a graph showing the immediate impact of this change.

Questions that I may or may not have time to figure out:

• What is going on inside the JVM with MappedByteBuffer.force()? If nothing has changed, does it still write the entire file? Part of the file? Does it load it first?
• Is there a certain amount of the MBB always in RSS at all times? (RSS was roughly half the total allocated MBB sizes. Coincidence? I suspect not.)
• If I move the MappedByteBuffer.force() to database update events, and not a periodic timer, will the problem magically go away?
• Why was the RSS slope so regular? It does not correlate to any of the application load metrics.

Where can I find old versions of the JDK and JRE? [closed]

To test compatibility, I need to find old versions of the JRE and JDK. Where can I find download links to these files?

It is a bad practice to use Sun's proprietary Java classes?

The compiler display warnings if you use Sun's proprietary Java classes. I'm of the opinion that it's generally a bad idea to use these classes. I read this somewhere. However, aside from the warnings are there any fundamental reasons why you should not use them?

Difference com.sun.jersey and org.glassfish.jersey

What is the difference between com.sun.jersey and org.glassfish.jersey?

Currently I have my REST service working on com.sun.jersey and I want to write tests, but I can't find a good tutorial for this (nothing seems to work). However, I can find good documentation about the org.glassfish.jersey tests.

How can I suppress java compiler warnings about Sun proprietary API

I'm using the encode() method from the sun.misc.BASE64Encoder package. How do I suppress the compiler warnings that it generates?

sun.misc.BASE64Encoder is Sun proprietary API and may be removed in

And as a followup, why don't I see this warning in Eclipse?

Why are there many JRE implementations?

I was wondering..There is Sun's JRE, IBM's JRE, BEA's JRE, Oracle's JRE and some more less know JREs in the market. Why is there so many JRE implementations? Does the fact that Sun opened the Java platforms mean that there will be one open JRE / JDK? Or are we going towards what happened with Linux and its many distributions ?

Are invisible references still an issue in recent JVMs?

I was reading Java Platform Performance (sadly the link seems to have disappeared from the internet since I originally posed this question) and section A.3.3 worried me.

I had been working on the assumption that a variable that dropped out of scope would no longer be considered a GC root, but this paper appears to contradict that.

Do recent JVMs, in particular Sun's 1.6.0_07 version, still have this limitation? If so, then I have a lot of code to analyse...

I ask the question because the paper is from 1999 - sometimes things change, particularly in the world of GC.

As the paper is no longer available, I'd like to paraphrase the concern. The paper implied that variables that were defined inside a method would be considered a GC root until the method exited, and not until the code block ended. Therefore setting the variable to null was necessary to permit the Object referenced to be garbage collected.

This meant that a local variable defined in a conditional block in the main() method (or similar method that contained an infinite loop) would cause a one-off memory leak unless you nulled a variable just before it dropped out of scope.

The code from the chosen answer illustrates the issue well. On the version of the JVM referenced in the document, the foo object can not be garbage collected when it drops out of scope at the end of the try block. Instead, the JVM will hold open the reference until the end of the main() method, even though it is impossible for anything to use that reference.

This appears to be the origin of the idea that nulling a variable reference would help the garbage collector out, even if the variable was just about to drop out of scope.

Connect to Sun LDAP with ADO

I want to connect (and get user's group) to a Sun LDAP server with a Delphi program. I think ADSI works only with Microsoft LDAP. I try it with ADO, but I can't connect.

Can someone show some code how I would do this?

How can I tell whether Java is Sun / Oracle / OpenJDK? [duplicate]

Possible Duplicate:
Which JRE I am using

I'm trying to figure out whether the Java installation in my HPC environment is running the Sun JVM, or Oracle, or OpenJDK. Since I don't have administrator access and I didn't install Java, is there a quick way I can determine which JVM I have installed?

standage@login4:~$ which java
/usr/bin/java
standage@login4:~$ java -version
java version "1.6.0_03"
Java(TM) SE Runtime Environment (build 1.6.0_03-b05)
Java HotSpot(TM) Server VM (build 1.6.0_03-b05, mixed mode)
standage@login4:~$ uname
Linux

What impact, if any, does the -d64 switch have on Sun JVM resident memory usage?

I've got this webapp that needs some memory tuning. While I'm already profiling the application itself and trimming things down, the JVM itself seems overly bloated to me on our busiest instance. (The lower volume instances do not have this problem.) The details:

• Platform:
  • RHEL4 64-bit (Linux 2.6.9-78.0.5.ELsmp #1 SMP x86_64)
  • Sun Java 6 (Java HotSpot(TM) 64-Bit Server VM (build 10.0-b23, mixed mode))
  • Tomcat 6 with -d64 in startup.sh
• My webapp currently has some code that in production requires the benefits of running 64-bit.
• I've observed that after some time (a week) the JVMs resident memory size (as shown by top) is three times the size of my -Xmx setting.
• The non-heap memory size, etc are all relatively trivial, a mere single digit percentage of the heap size
• There is only one section of code that requires a 64-bit bit address space

If I could refactor out the need for a 64-bit JVM, and drop the -d64 switch, would that make the JVM's resident memory footprint smaller? In other words...

What impact, if any, does the -d64 switch have on the Sun JVM resident memory usage?

Alternative to sun.misc.Signal

I started research to find an alternative to the sun.misc.Signal class, because it could be unsupported in upcoming JDKs (we're currently working on 1.6). When I build the project I get:

warning: sun.misc.SignalHandler is Sun proprietary API and may be removed in a future release

I came across multiple solutions but they don't fit my project e.g. in this question.

This is unacceptable in my situation because:

• Signals are used not only for killing application
• The application is huge - every conceptual change of communication between modules/JVMs could take years to implement

Thus, the desirable solution is to find something like a new Oracle version of this class or something which works in the same way. Does such a solution exist?

Makefile error: Unexpected end of line seen

Trying to install Git, I ran configure and make, but got the following error message:

make: Fatal error in reader: Makefile, line 221: Unexpected end of line seen

The Makefile looks like:

218:    GIT-VERSION-FILE: FORCE
219:            @$(SHELL_PATH) ./GIT-VERSION-GEN
220:    -include GIT-VERSION-FILE
221:
222:    uname_S := $(shell sh -c 'uname -s 2>/dev/null øø echo not')

What's causing the error?

The following information may or may not be relevant:

• I tried to install Git 1.7.0.3 on SunOS 5.9 (Solaris 9) in a directory in my account.
• The gcc version is 3.4.2 (older then the version of 3.4.6 stated by sunfreeware.com).
• I don't have root privileges.

Is the original Java ideal dead?

I feel that while I love J2ME and Java it's hypocritical of them to have two APIs for Java. Java was designed with "One code, many platforms" in mind, and now it's more like "One API for every OS, and one API for everything smaller than a netbook." I see a lot of J2ME emulators and such being ported to things like the PSP, and other consoles for homebrew, and I wonder why no one is doing this with normal Java.

I'd love to write a game to play on my PC, than fire up a simple emulator and play the same game on the PSP, or the Dreamcast, but I can't. J2ME can't even run on a PC, you need an emulator for it, which reduces your market greatly. Plus most emulators are bulky, and not good.

With super-phones like the IPhone coming out people are going to want more than little J2ME games, so if Java can't port their standard JRE to it they might find themselves missing the boat like Microsoft did with the netbook boom.

It just feels like Sun needs to ether work on making the standard JRE smaller and more portable, or making J2ME available on the PC easily.

Position of the Sun (azimuth) in Lua

There is only one function in LUA I could find online, but it gives wrong values (measured with professional online tools).

It appears that from the sunrise till some time after the noon the math works, but after, the Sun's angle goes back to the sunrise position. Should be from 106° to 253°, currently it's from 106° to ~180° to 106°.

Function I'm using:

-- solar altitude, azimuth (degrees)
function sunposition(latitude, longitude, time)
    time = time or os.time()
    if type(time) == 'table' then time = os.time(time) end

    local date = os.date('*t', time)
    local timezone = (os.time(date) - os.time(os.date('!*t', time))) / 3600
    if date.isdst then timezone = timezone + 1 end

    local utcdate = os.date('*t', time - timezone * 3600)
    local latrad = math.rad(latitude)
    local fd = (utcdate.hour + utcdate.min / 60 + utcdate.sec / 3600) / 24
    local g = (2 * math.pi / 365.25) * (utcdate.yday + fd)
    local d = math.rad(0.396372 - 22.91327 * math.cos(g) + 4.02543 * math.sin(g) - 0.387205 * math.cos(2 * g)
      + 0.051967 * math.sin(2 * g) - 0.154527 * math.cos(3 * g) + 0.084798 * math.sin(3 * g))
    local t = math.rad(0.004297 + 0.107029 * math.cos(g) - 1.837877 * math.sin(g)
      - 0.837378 * math.cos(2 * g) - 2.340475 * math.sin(2 * g))
    local sha = 2 * math.pi * (fd - 0.5) + t + math.rad(longitude)

    local sza = math.acos(math.sin(latrad) * math.sin(d) + math.cos(latrad) * math.cos(d) * math.cos(sha))
    local saa = math.acos((math.sin(d) - math.sin(latrad) * math.cos(sza)) / (math.cos(latrad) * math.sin(sza)))

    return 90 - math.deg(sza), math.deg(saa)
end

Example request:

lat, long = 45.327063, 14.442176 -- Rijeka, Croatia
time = {year=2016, month=2, day=17, hour=17, min=30} -- end of the day
altitude, azimuth = sunposition(lat, long, time)

Result is:

• -0.1 degrees in altitude
• 106 degrees in azimuth.

Result should be:

• -0.1 degrees in altitude
• 253 degrees in azimuth.

I have found multiple solutions in other programming languages and even tried to rewrite in Lua but without any success. Too complex math behind the solution.

I'm using it for my Corona SDK app that will show position of the Sun relative to the device. The only solution that currently works is a PHP or Javascript script that my app can ask via API call over the Internet but I would really like to avoid that.

I'm extremely grateful for any help from the community. Thank you and love you folks! :)