NYX DS

Java初探

好幾年前就想要用Java,只是工作上一直沒機會用上.
最近想要用Java applet加強web server的功能就著手來study囉

1.Java 既是編譯也是直譯式語言

編譯式語言的優點 : 較有效率及執行速度快
直譯式語言的優點 : 跨平台的可移植性佳

Java Source Code -> [ Compile ] -> Java Instruction Binary
Java Instruction Binary -> [ Interpreter ] -> Running on Java Virtual Machine

2.Java沒有指標 (pointer)

Java使用參考(reference)來達到指標的功能.
參考的好處是有型別處理的能力,因此安全性增加許多

3.Java會紀錄run time type

有了 run time type, Java 可以安全的做多型及強制轉型

4.Java具有真正的資料安全措施

在C++可以透過private宣告保護data / function member.
但這種保護可以透過指標便可輕易的存取.常聽到的溢位攻擊大致上就是運用這種惡意指標的方式

Java 有三層安全性保護
Byte-code verifier, class loader, security manager

其中Byte-code verifier就能防止溢位存取的發生
Security manager能限制程式的執行,例如不允許程式網路連線.

5.Java不支援運算子overload

6.Java中的陣列是特殊的物件型態

宣告型別為String的陣列變數 String [] arrayStr;
arrayStr此時還沒有陣列實體

Alloc陣列實體 arrayStr = new String [10];
陣列中的元素是該陣列型別的reference,並非實體
因此陣列初始的元素都是null reference

anonymous array

Func( new String [] { "string 0", "string 1", "string 2"});

7.Java中local variable必須明確賦值初始化

VT300 Screen Shot

Graphic User Interface System Information

Resolution : 480 x 272 16bits
Low level engine : Nano-X
Font : FireFly (UTF-8)
Features :
  1.Window Manager
  2.Alpha Blending Window
  3.Break edge window
  4.Shadow Font
  5.Scale jpeg image
  6.Editor, Menu, Radio Button, Combo Box, Tab Window

轉載 max mp3 frame size

[mad-dev] max mp3 frame size?

Rob Leslie rob@mars.org
Thu, 17 Jan 2002 16:54:05 -0800

• Previous message: [mad-dev] max mp3 frame size?
• Next message: [mad-dev] max mp3 frame size?
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

---

Joshua Haberman wrote:
> Currently Audacity uses a 64k input buffer when reading mp3s with libmad.
> This has worked great for the most part, but I've received a report that
> one particular mp3 will put Audacity into an infinite loop upon import.
> Since a trace revealed that the input callback was looping endlessly, I
> suspected that the buffer wasn't big enough to hold an entire frame, and
> the input callback was sending libmad the same partial frame over and over.
> 
> I suggested that this user double the input buffer size, and that fixed
> the problem.
> 
> Earlier when I asked you about this issue, you said mp3 frames are
> relatively small (around 418 bytes) so I'm very surprised that 64k wasn't
> big enough to hold an entire frame. Can you think of any other reason why
> increasing the buffer size would solve this problem?

Sounds like it could be a bug in your input/streaming code, triggered by the
unlucky buffer size? Out of curiosity, what bitrate and sampling frequency was
the mp3 that caused problems?

> Is there a maximum size for mp3 frames that I could safely set as the
> buffer size, or would I have to dynamically size the buffer to be
> completely safe?

The absolute theoretical maximum frame size is 2881 bytes: MPEG 2.5 Layer II,
8000 Hz @ 160 kbps, with a padding slot. (Such a frame is unlikely, but it was
a useful exercise to compute all possible frame sizes.) Add to this an 8 byte
MAD_BUFFER_GUARD, and the minimum buffer size you should be streaming to
libmad in the general case is 2889 bytes.

Theoretical frame sizes for Layer III range from 24 to 1441 bytes, but there
is a "soft" limit imposed by the standard of 960 bytes. Nonetheless MAD can
decode frames of any size as long as they fit entirely in the buffer you pass,
not including the MAD_BUFFER_GUARD bytes.

A 64K buffer is surely large enough, which makes me think you have a different
kind of problem...

-- 
Rob Leslie
rob@mars.org