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.
I think this should be a community Wiki
But to the point, my view is that J2ME is going to die a horrible death and leave us with normal Java. The current Netbook trend combined with the more powerful smartphone trend means that your average cellphone today is much stronger than the machines that ran J2SE when it first came out.
Hence, we can do away with J2ME, which was designed for ancient Nokias, and enjoy the standard Java on a smart doorknob (or a smartphone).
The only problem that Java faces is that the biggest player in smartphone applications - Apple - isn't going to allow a JVM anytime in the foreseeable future.
Even if your monitor had an accelerometer in it, you probably wouldn't want to use it for an iPhone app - so I'd say there are limits to portability after all.
If "write once, run anywhere" is misleading, that's because it was conceived before cell phones became prevalent. As far as the API goes, I agree a common subset would be preferable, but once again, the entire J2ME niche is completely new. The JVM is still useful: a web browser can run on Windows, Linux, and OS X, and a game can run on both Nokia and Samsung phones.
Is the original Java ideal dead?
It still meets the original demands of portable code from workstation to workstation, so no. But it sounds like you've set an even higher bar for future platforms.
There are many things that a Virtual Machine might chose to abstract away.
The OS abstracts away some of the common hardware, by providing standard interfaces to them (block i/o, character i/o, etc).
The JVM set out to abstract out the processor and the OS itself, a mighty goal by itself (at that time)! However, abstracting the peripheral hardware was, and will remain, a difficult goal to achieve.
Perhaps, when we see more convergence of hand-helds/laptops/desktops/servers, the need to abstract out the hardware will diminish.
With newer platforms for mobile like Windows Mobile and Symbian which have captured the market share j2me etc have taken a backseat due to issue like not taking advantage of hardware etc..
J2ME is great. You can package and run J2ME applications with the lean and clean http://www.microemu.org/. Since I have been writing code for J2ME, I'm a better programmer. It forces you to be efficient on memory. I love the small clean API.In the future all my client application will be designed for J2ME and then ported to J2SE/Android/IPhone. The difficult thing is to build your in-house GUI framework flexible enough for the application to run smoothly on any screen size. That takes time.
Related
Now you can easily notice I am new on app development path when I am setting up Android studio for Android development I find that my pc need specific requirements (Hardware) to start
But I have desktop that
CPU : Core 2Duo
RAM : 4 GB
HDD : 500 GB
It's been week when I just run some basic apps but it's very headache to do it for basics app because my android studio every minute got hang and start lagging I can't open chrome there full of warehouse of my problems related to pc because of android studio
Anyone know any hacks or by tips for me you can feel free for it.
Putting it bluntly: those specs are simply not enough to do any serious modern development. If you could replacing the HDD with an SSD (even a small, cheap one) would be the highest priority and more memory is second. A better CPU would obviously help, but it's a luxury, the other two items are more important.
Assuming that's not an option, you can do either of those two things:
don't use an IDE (or at least a more light-weight one, such as VS Code) and build your software from the command line. This will be more painful (especially when you're just starting) and even then the resource requirements of the build will be non-trivial.
Make sure to do as little as possible on your local machine. If you have a decent internet connection, then you might be better off developing on a free remote cloud computer and use something like Projector to show the UI in the browser. I've found this repo with instructions on how to use it with Android Studio, which seems useful, but I've not verified that it works.
The only hacks I can think of are:
Make sure you are not using a remote mounted file system or "share" for either your Android Studio + Java installation or your AS workspace.
Shutoff (quit) all other applications that are using significant amounts of RAM; e.g. your web browsers, your email tool, Slack, Zoom, etc.
If you are using Windows, switch to Linux.
Better idea: get a better development machine. I think that the RAM is most important, because it sounds like your machine is thrashing.
It may seem unfair but Android Studio is not really suitable to run in a lower end device. It used to lag/hang in my device with Core i7 and 8GB Ram. The best thing you can do is to use an SSD instead of HDD. SSDs with smaller memory are often cheap and this alone can somewhat lessen your problems with Android Studio.
i think you should change your HDD to 240 GB SSD and it will works fine
I am trying to make a visual stimulus for an EEG study. The video is simply a flicker between a black frame and a white frame, and the alternation should occur at a range of rates: 12Hz, 24Hz, 48Hz, 72Hz.
Our monitors have a refresh rate of 144Hz and the computers are also fancy, and I am measuring the success of the videos with an oscilloscope to ensure accuracy. So, the hardware should not be an issue; theoretically, up to half the monitor's refresh rate should be possible. However, I have failed in both Java and MatLab.
I have tried using MatLab:
1) using imwrite() to make a gif
2) using the VideoWriter
3) using getframe() and movie2avi().
In all of these methods, the extra-high framerate is declared, and I can see in my command window that all the frames were inserted during the run. However, the final output file never exceeds 48Hz.
On top of that, the 48Hz as well as 24Hz and even 12Hz files also have serious timing issues with the frames.
I have also tried to make the files using Processing's MovieMaker: I set the framerate to 72Hz -- input a list of 72 .png files as frames -- and it should output a 1-second file that flickers at 72Hz.
However, the result only goes at 48Hz, and again the timing of the frames is not reliable.
I wouldn't be posting here if I hadn't exhausted my search; I'm really out of ideas. MatLab and Processing were both recommended ways of achieving this kind of high fps file, and both have big timing issues even with lower flicker frequencies. If anyone has any tips on increasing the temporal fidelity of the high-Hz flicker (graphics settings? codecs?), or of how to make it all the way to 72Hz, we'd greatly appreciate it!
As I said, I have only used Processing/Java and MatLab, so please feel free to recommend another platform.
THis is not an answer. It needs more than the comment-box, though, so please bear with me.
There are fundamental issues involved:
Simply drawing to whatever facility your OS/Graphics combo exposes, does not at all guarantee the drawed element to be present starting from the next frame (in all systems I know of).
This simply stems from the fact, that all these combos were explicitly NOT ment for an EEG Stimulus, but for consumption by visual understanding
Many combos offer lower-level facilities (e.g. OpenGL), that do carry such a promise, but come with other sets of problems, one of which is the less comfortable programming environment
With most OS/Harware combos, it might be less than trivial to sustain this stimulus - 144 Hz translates to less than 7ms - a time slot, that might be missed by a single bad scheduling decision of the OS or a need for a double-read even on a fast spinning disk. You would need to aim for some realtime-oriented OS dialect.
EDIT
After re-reading your question, I see you use Java. Forget it. a single GC break can easily be more than 7 ms.
There are a couple of free (as in beer and freedom) toolboxes for Matlab that wrap the low level openGL commands that you need in order to gain the type of control you want
MGL only runs on Mac but:
mgl is a set of matlab functions for displaying full screen visual stimuli from matlab. It is based on OpenGL functions, but abstracts these into more simple functions that can be used to code various kinds of visual stimuli.
Psychtoolbox runs on Mac, Windows, and Linux
The attraction of using computer displays for visual psychophysics is
that they allow software specification of the stimulus. Programs to
run experiments are often written in a low-level language (e.g. C or
Pascal) to achieve full control of the hardware for precise stimulus
display... The Psychophysics Toolbox is a software package that adds this capability to the Matlab and Octave application on Macintosh, Linux and Windows computers
It sounds like you are just starting out, in which case I would also suggest looking at the Python based PsychoPy
PsychoPy is an open-source package for running experiments in Python (a real and free alternative to Matlab). PsychoPy combines the graphical strengths of OpenGL with the easy
Python syntax to give scientists a free and simple stimulus
presentation and control package.
I have a hardware device with following specifications
RAM: ~200-250 MB
Speed: ~800 - 1000 MHz
Processor: cortex arm11
We have a C/C++ based SDK to develop applications for the device. Now we want to put JVM inside the device so that people can do java based development too. (Very similar to DVM inside Android OS)
I am a Java guy, but not proficient in C/C++ and Kernel level details.
Could anyone kindly suggest me how to start the whole process or any link where I can improve my knowledge in this direction.
Thanks in advance.
You can run Java applications on an ARMv6 device but the overall experience (performance and api coverage wise) won't be easily similar to a desktop one.
You can use Java SE Embedded to run headless (non gui) applications assuming your device a VFP unit. (ARMv6/7 Linux - Headless EABI, VFP, SoftFP ABI, Little Endian1)
You can also use a third party Java virtual machine like JamVM.
These are all easy if you already have a working arm device with a Linux kernel. In this case you can also port Android to your device easier and this will make it simpler to introduce your device to external developers, you can just say "it is an android 2.3 device". There are various pages (all somehow half baked) about porting Android and Google is your friend.
I assume the latest update version of java would provide better performance.
I am looking for a way to implement isolation of software components from endless loops or memory leaks. Android isolates each app in it's own process, Google Chrome isolates each tab in it's own process.
My primary drawback is that java takes so long to start and also I would like to reduce memory consumption.
Is there any alternate build or more controlled startup that will accomplish this?
If quick startup is your goal, Java on a PC may not be your best bet. It's going to take a few seconds because that's how long it takes to load the VM from disk.
If you want your app to start more quickly it's easy to get a splash screen up, just create a module that only loads your splash screen, waits for it to fully display then uses reflection to link to your "Real" main module.
(Use reflection because otherwise it will pull in your entire program through references before it starts the main one--at least that's how it used to work).
If you're talking about run-time performance, you won't get quicker by changing languages, Java's about as fast as you can get. You MIGHT be able to get a boost by converting to C/C++ and rewriting it to suit those platforms (Less OO, stack allocations instead of heap, etc), but otherwise none of the other languages in general usage are close to Java in speed.
If you really need the quick startup, depending on what you are doing there may be some tricks. I've seen projects that try to keep a Java VM running in your toolbar and allow you to make requests (tell it to start an app). This was faster but made additional requirements of the user (Loading this additional tool)
Another possibility--if you are constantly starting up/shutting down small tasks and that's the reason the startup bothers you then you can definitely speed it up by keeping it running invisibly. Just have your Java app open a socket and listen for commands then create a little .EXE or shell script that can start your program if it's not running or send commands to that socket if it is. This would completely eliminate startups after the first run.
In general, Java has a much longer startup time than other languages. If you are sticking with Java on a desktop app, a lot of stuff like startup time is determined by the JRE installed on the client's computer, which you can't control.
As to "endless memory leaks"... Java doesn't leak memory. If your program does, fix it.
This is a second answer because it's completely different and my other got too long :)
Try compiling it--I think GCC can compile it. This could almost completely eliminate your startup. I believe Jikes used to be a windows java compiler by IBM, but I don't know if it's still maintained.
Note that compiled code will probably run slower than JVM code for long-running apps.
Is Java a suitable alternative to C / C++ for realtime audio processing?
I am considering an app with ~100 (at max) tracks of audio with delay lines (30s # 48khz), filtering (512 point FIR?), and other DSP type operations occurring on each track simultaneously.
The operations would be converted and performed in floating point.
The system would probably be a quad core 3GHz with 4GB RAM, running Ubuntu.
I have seen articles about Java being much faster than it used to be, coming close to C / C++, and now having realtime extensions as well. Is this reality? Does it require hard core coding and tuning to achieve the %50-%100 performance of C some are spec'ing?
I am really looking for a sense if this is possible and a heads up for any gotchas.
For an audio application you often have only very small parts of code where most of the time is spent.
In Java, you can always use the JNI (Java Native interface) and move your computational heavy code into a C-module (or assembly using SSE if you really need the power). So I'd say use Java and get your code working. If it turns out that you don't meet your performance goal use JNI.
90% of the code will most likely be glue code and application stuff anyway. But keep in mind that you loose some of the cross platform features that way. If you can live with that JNI will always leave you the door open for native code performance.
Java is fine for many audio applications. Contrary to some of the other posters, I find Java audio a joy to work with. Compare the API and resources available to you to the horrendous, barely documented mindf*k that is CoreAudio and you'll be a believer. Java audio suffers from some latency issues, though for many apps this is irrelevant, and a lack of codecs. There are also plenty of people who've never bothered to take the time to write good audio playback engines(hint, never close a SourceDataLine, instead write zeros to it), and subsequently blame Java for their problems. From an API point of view, Java audio is very straightforward, very easy to use, and there is lots and lots of guidance over at jsresources.org.
Sure, why not?
The crucial questions (independent of language, this is from queueing theory) are:
what is the maximum throughput you need to handle (you've specified 100 x 48kHz, is that mono or stereo, how many bits equivalent at that frequency?)
can your Java routines keep up with this rate on the average?
what is the maximum permissible latency?
If your program can keep up with the throughput on the average, and you have enough room for latency, then you should be able to use queues for inputs and outputs, and the only parts of the program that are critical for timing are the pieces that put the data into the input queue and take it out of the output queue and send it to a DAC/speaker/whatever.
Delay lines have low computational load, you just need enough memory (+ memory bandwidth)... in fact you should probably just use the input/output queues for it, i.e. start putting data into the input queue immediately, and start taking data out of the output queue 30s later. If it's not there, your program is too slow...).
FIRs are more expensive, that's probably going to be the bottleneck (& what you'd want to optimize) unless you have some other ugly nasty operation in mind.
I think latency will be your major problem - it is quite hard to maintain latency already in C/C++ on modern OSes, and java surely adds to the problem (garbage collector). The general design for "real-time" audio processing is to have your processing threads running at real time scheduling (SCHED_FIFO on linux kernels, equivalent on other OSes), and those threads should never block. This means no system calls, no malloc, no IO of course, etc... Even paging is a problem (getting a page from disk to memory can easily take several ms), so you should lock some pages to be sure they are never swapped out.
You may be able to do those things in Java, but java makes it more complicated, not easier. I would look into a mixed design, where the core would be in C, and the rest (GUI, etc...) would be in java if you want.
One thing I didn't see in your question is whether you need to play out these processed samples or if you're doing something else with them (encoding them into a file, for example). I'd be more worried about the state of Java's sound engine than in how fast the JVM can crunch samples.
I pushed pretty hard on javax.sound.sampled a few years back and came away deeply unimpressed -- it doesn't compare with equivalent frameworks like OpenAL or Mac/iPhone's Core Audio (both of which I've used at a similar level of intensity). javax.sound.sampled requires you to push your samples into an opaque buffer of unknown duration, which makes synchronization nigh impossible. It's also poorly documented (very hard to find examples of streaming indeterminate-length audio over a Line as opposed to the trivial examples of in-memory Clips), has unimplemented methods (DataLine.getLevel()... whose non-implementation isn't even documented), and to top it off, I believe Sun laid off the last JavaSound engineer years ago.
If I had to use a Java engine for sound mixing and output, I'd probably try to use the JOAL bindings to OpenAL as a first choice, since I'd at least know the engine was currently supported and capable of very low-latency. Though I suspect in the long run that Nils is correct and you'll end up using JNI to call the native sound API.
Yes, Java is great for audio applications. You can use Java and access audio layers via Asio and have really low latency (64 samples latency which is next to nothing) on Windows platform. It means you will have lip-sync on video/movie. More latency on Mac as there is no Asio to "shortcut" the combination of OS X and "Java on top", but still OK. Linux also, but I am more ignorant. See soundpimp.com for a practical (and world first) example of Java and Asio working in perfect harmony. Also see the NRK Radio&tv Android app containing a sw mp3 decoder (from Java). You can do most audio things with Java, and then use a native layer if extra time critical.
Check out a library called Jsyn.
http://www.softsynth.com/jsyn/
Why not spend a day and write a simple java application that does minimal processing and validate whether the performance is adaquate.
From http://www.jsresources.org/faq_performance.html#java_slow
Let's collect some ethernal wisdom:
The earth is flat.
and, not to forget: Java is slow.
As several applications prove (see links section), Java is sufficient
to build audio editors, multitrack recording systems and MIDI
processing software. Try it out!